[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
Obsoleted by: 2578 DRAFT STANDARD
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:
<descriptor> <macro> <clauses> ::= <value>
where <descriptor> corresponds to an ASN.1 identifier, <macro> names
the macro being invoked, and <clauses> and <value> 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 of these clauses must be enclosed in double
quotation marks, and therefore cannot itself contain double quotation
SNMPv2 Working Group Standards Track [Page 10]
RFC 1902 SMI for SNMPv2 January 1996
marks, although the value may be multi-line.