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.

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 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

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),

-- 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 ::=

[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 ::=

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 ::=

"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

"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, a  "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

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.1syntax, the entire value of these clauses must be enclosed in double quotation marks, and therefore cannot itself contain double quotation marks, although the value may be multi-line.

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 even when there is no collision when IMPORTing symbols.

Finally, the IMPORTS statement may not be used to import an ASN.1 named type which corresponds to either the SEQUENCE or SEQUENCE OF type.

3.3. Exporting Symbols

The ASN.1 EXPORTS statement is not allowed in SNMPv2 information modules. All items defined in an information module are automatically exported.

3.4. ASN.1 Comments

Comments in ASN.1 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.

3.5. OBJECT IDENTIFIER values

An OBJECT IDENTIFIER value is an ordered list of non-negative numbers. For the SNMPv2 framework, 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

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:

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 SNMPv2 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. The date and time are represented in UTC Time format (see Appendix B).

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.

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. The date and time are represented in UTC Time format(see Appendix B).

5.5.1. Mapping of the DESCRIPTION sub-clause

The DESCRIPTION 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.

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
FROM SNMPv2-SMI;

fizbin MODULE-IDENTITY
LAST-UPDATED "9505241811Z"
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."
-- contact IANA for actual number
::= { experimental xx }

END