Network Working Group SNMPv2 Working Group Request for Comments: 1902 J. Case Obsoletes: 1442 SNMP Research, Inc. Category: Standards Track K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services January 1996 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) 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. 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. 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) [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. SNMPv2 Working Group Standards Track [Page 1] RFC 1902 SMI for SNMPv2 January 1996 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. 1.1. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). 2. Definitions SNMPv2-SMI DEFINITIONS ::= BEGIN -- the path to the root org OBJECT IDENTIFIER ::= { iso 3 } 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 Working Group Standards Track [Page 2] RFC 1902 SMI for SNMPv2 January 1996 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 } -- definitions for information modules MODULE-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= "LAST-UPDATED" value(Update UTCTime) "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 UTCTime) "DESCRIPTION" Text -- uses the NVT ASCII character set Text ::= """" string """" END OBJECT-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart SNMPv2 Working Group Standards Track [Page 3] RFC 1902 SMI for SNMPv2 January 1996 VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= """" string """" END -- names of objects ObjectName ::= OBJECT IDENTIFIER NotificationName ::= OBJECT IDENTIFIER -- syntax of objects ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that SEQUENCEs for conceptual tables and -- rows are not mentioned here... application-wide ApplicationSyntax } -- built-in ASN.1 types SimpleSyntax ::= CHOICE { -- INTEGERs with a more restrictive range -- may also be used integer-value -- includes Integer32 INTEGER (-2147483648..2147483647), SNMPv2 Working Group Standards Track [Page 4] RFC 1902 SMI for SNMPv2 January 1996 -- 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 ::= [UNIVERSAL 2] IMPLICIT 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 -- (this is a tagged type for historical reasons) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) -- this wraps Counter32 ::= SNMPv2 Working Group Standards Track [Page 5] RFC 1902 SMI for SNMPv2 January 1996 [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 IndexPart DefValPart VALUE NOTATION ::= value(VALUE ObjectName) Syntax ::= SNMPv2 Working Group Standards Track [Page 6] RFC 1902 SMI for SNMPv2 January 1996 type(ObjectSyntax) | "BITS" "{" Kibbles "}" Kibbles ::= Kibble | Kibbles "," Kibble Kibble ::= identifier "(" nonNegativeNumber ")" 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 Index ::= -- use the SYNTAX value of the -- correspondent OBJECT-TYPE invocation value(Indexobject ObjectName) Entry ::= -- use the INDEX value of the -- correspondent OBJECT-TYPE invocation value(Entryobject ObjectName) DefValPart ::= SNMPv2 Working Group Standards Track [Page 7] RFC 1902 SMI for SNMPv2 January 1996 "DEFVAL" "{" value(Defval Syntax) "}" | empty -- uses the NVT ASCII character set Text ::= """" string """" 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 | Objects "," Object Object ::= value(Name ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- uses the NVT ASCII character set Text ::= """" string """" END -- definitions of administrative identifiers zeroDotZero OBJECT-IDENTITY STATUS current DESCRIPTION SNMPv2 Working Group Standards Track [Page 8] RFC 1902 SMI for SNMPv2 January 1996 "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 a subset of ASN.1 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]. 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 SNMPv2 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 SNMPv2, and instances of ASN.1 macros defined in this document and in other documents [2, 3] of the SNMPv2 framework. Additional ASN.1 macros may not be defined in SNMPv2 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 SNMPv2 Working Group Standards Track [Page 9] RFC 1902 SMI for SNMPv2 January 1996 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. 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].) 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, even though hyphen is allowed by [1]. This restriction enables arithmetic expressions in languages which use the minus sign to reference these descriptors without ambiguity.) 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 Clauses Some clauses in a macro invocation may take a textual value (e.g., the DESCRIPTION clause). Note that, in order to conform to the ASN.1 syntax, the entire value