--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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:
+
+
+
+SNMPv2 Working Group Standards Track [Page 11]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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.
+
+
+
+SNMPv2 Working Group Standards Track [Page 12]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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
+
+
+
+SNMPv2 Working Group Standards Track [Page 13]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 14]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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.
+
+ The values "current", and "obsolete" are self-explanatory. The
+ "deprecated" value indicates that the definition is obsolete, but
+ that an implementor may wish to support it to foster interoperability
+ with older 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 an object assignment defined in some other
+ information module.
+
+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 }
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 15]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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.
+
+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].
+
+ A extended subset of the full capabilities of ASN.1 sub-typing is
+ allowed, as appropriate to the underingly ASN.1 type. Any such
+ restriction on size, range, enumerations or repertoire 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 C 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 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.
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 16]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ Finally, a label for a named-number enumeration must consist of one
+ or more letters or digits (no hyphens), 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.)
+
+7.1.2. OCTET STRING
+
+ The OCTET STRING type represents arbitrary binary or textual data.
+ Although there is no SMI-specified size limitation for this type, MIB
+ designers should realize that there may be implementation and
+ interoperability limitations for sizes in excess of 255 octets.
+
+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 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.)
+
+ Although there is no SMI-specified limitation on the number of
+ enumerations (and therefore on the length of a value), 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 (no hyphens), 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.)
+
+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.
+
+ 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].
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 17]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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 a SYNTAX clause value of TimeStamp (a
+ textual convention defined in [3]) indicating the time of the last
+ discontinuity.
+
+ 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. The
+ maximum value can not be greater than 2^32-1 (4294967295 decimal).
+ The value of a Gauge has its maximum value whenever the information
+ being modeled is greater or equal to that maximum value; if the
+ information being modeled subsequently decreases below the maximum
+ value, the Gauge also decreases.
+
+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.
+
+
+
+SNMPv2 Working Group Standards Track [Page 18]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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 a SYNTAX clause value of TimeStamp (a
+ textual convention defined in [3]) indicating the time of the last
+ discontinuity.
+
+ 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.
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 19]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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 <EntryType>
+
+ where <EntryType> refers to the SEQUENCE type of its subordinate
+ conceptual row. A conceptual row has SYNTAX of the form:
+
+ <EntryType>
+
+ where <EntryType> is a SEQUENCE type defined as follows:
+
+ <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
+
+ where there is one <type> for each subordinate object, and each
+ <type> is of the form:
+
+ <descriptor> <syntax>
+
+ where <descriptor> is the descriptor naming a subordinate object, and
+ <syntax> has the value of that subordinate object's SYNTAX clause,
+ normally omitting the sub-typing information. Further, these ASN.1
+ types are always present (the 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.
+
+
+
+SNMPv2 Working Group Standards Track [Page 20]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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".)
+
+7.4. Mapping of the STATUS clause
+
+ The STATUS clause, which must be present, indicates whether this
+ definition is current or historic.
+
+ The values "current", and "obsolete" are self-explanatory. The
+ "deprecated" value indicates that the definition is obsolete, but
+ that an implementor may wish to support that object to foster
+ interoperability with older 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.
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 21]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+7.6. Mapping of the REFERENCE clause
+
+ The REFERENCE clause, which need not be present, contains a textual
+ cross-reference to an object defined in some other information
+ module. This is useful when de-osifying a MIB module produced by
+ some other organization.
+
+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 syntax of those
+ objects indicate how to form the instance-identifier:
+
+(1) integer-valued: a single sub-identifier taking the integer value
+ (this works only for non-negative integers);
+
+(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
+
+
+
+SNMPv2 Working Group Standards Track [Page 22]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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.
+
+ 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:
+
+(1) within a MIB module originally written to conform to the SNMPv1
+ framework, and later converted to conform to the SNMPv2 framework;
+ 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
+
+
+
+SNMPv2 Working Group Standards Track [Page 23]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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 1573's ifTable
+ and the many media-specific MIBs which extend it for specific media
+ (e.g., the dot3Table in RFC 1650), 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 1573's ifTable and a
+ media-specific MIB which extends the ifTable for a specific media
+ (e.g., the dot3Table in RFC 1650), 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 a SNMPv2 entity
+ acting in an agent role when an object instance is created.
+
+
+
+SNMPv2 Working Group Standards Track [Page 24]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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 a SNMPv2 entity
+ acting in an agent role might use.
+
+ 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 a SNMPv2 entity acting in an agent
+ role 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 }
+ OBJECT IDENTIFIER DEFVAL { sysDescr }
+ BITS DEFVAL { { primary, secondary } }
+ -- enumerated values that are set
+ IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21
+
+ 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
+ "1" to the administratively assigned name for the conceptual table.
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 25]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+(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.
+
+ Further note that although conceptual tables and rows are given
+ administratively assigned names, these conceptual objects may not be
+ manipulated in aggregate form by the management protocol.
+
+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 INTEGER
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The index number of the first unassigned entry in the
+ evaluation table.
+
+ 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
+
+
+
+SNMPv2 Working Group Standards Track [Page 26]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ "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
+ 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 executed."
+ DEFVAL { 0 }
+ ::= { evalEntry 3 }
+
+evalStatus OBJECT-TYPE
+ SYNTAX RowStatus
+
+
+
+SNMPv2 Working Group Standards Track [Page 27]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ 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 the ordered
+ sequence of MIB object types which are contained within every
+ instance of the notification. An object type specified in this
+ clause may not have an MAX-ACCESS clause of "not-accessible".
+
+8.2. Mapping of the STATUS clause
+
+ The STATUS clause, which must be present, indicates whether this
+ definition is current or historic.
+
+ The values "current", and "obsolete" are self-explanatory. The
+ "deprecated" value indicates that the definition is obsolete, but
+ that an implementor may wish to support the notification to foster
+ interoperability with older 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.
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 28]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+8.4. Mapping of the REFERENCE clause
+
+ The REFERENCE clause, which need not be present, contains a textual
+ cross-reference to a notification defined in some other information
+ module. This is useful when de-osifying a MIB module produced by
+ some other organization.
+
+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 the procedures employed by proxy agents (see Section 3.1.2 of
+ [7]), 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 linkUp trap might be described:
+
+linkUp NOTIFICATION-TYPE
+ OBJECTS { ifIndex }
+ STATUS current
+ DESCRIPTION
+ "A linkUp trap signifies that the SNMPv2 entity, acting in
+ an agent role, recognizes that one of the communication
+ links represented in its configuration has come up."
+ ::= { snmpTraps 4 }
+
+According to this invocation, the trap authoritatively identified as
+
+ { snmpTraps 4 }
+
+is used to report a link coming up.
+
+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.
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 29]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ Further, the following restrictions apply:
+
+ Restrictions to Refinement on
+ object syntax range enumeration size repertoire
+ ----------------- ----- ----------- ---- ----------
+ INTEGER (1) (2) - -
+ Integer32 (1) - - -
+ Unsigned32 (1) - - -
+ OCTET STRING - - (3) (4)
+ OBJECT IDENTIFIER - - - -
+ BITS - (2) - -
+ IpAddress - - - -
+ Counter32 - - - -
+ Counter64 - - - -
+ Gauge32 (1) - - -
+ TimeTicks - - - -
+
+where:
+
+(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);
+
+(3) the size in characters of the value may be refined by raising the
+ lower-bounds, by reducing the upper-bounds, and/or by reducing the
+ alternative size choices; or,
+
+(4) the repertoire of characters in the value may be reduced by further
+ sub-typing.
+
+ Otherwise no refinements are possible. Further details on sub-typing
+ are provided in Appendix C.
+
+10. Extending an Information Module
+
+ As experience is gained with a published information module, it may
+ be desirable to revise that information module.
+
+ To begin, the invocation of the MODULE-IDENTITY macro should be
+ updated to include information about the revision. Usually, this
+ consists of updating the LAST-UPDATED clause and adding a pair of
+ REVISION and DESCRIPTION clauses. However, other existing clauses in
+ the invocation may be updated.
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 30]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ Note that the module's label (e.g., "FIZBIN-MIB" from the example in
+ Section 5.8), is not changed when the information module is revised.
+
+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.
+
+(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".
+
+(3) A DEFVAL clause may be added or updated.
+
+(4) A REFERENCE clause may be added or updated.
+
+(5) A UNITS clause may be added.
+
+(6) A conceptual row may be augmented by adding new columnar objects at
+ the end of the row.
+
+(7) 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
+ those specifically allowed above), then the OBJECT IDENTIFIER value
+ associated with that object must also be changed.
+
+ 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.
+
+ Finally, note that if an object has the value of its STATUS clause
+ changed, then the value of its DESCRIPTION clause should be updated
+ accordingly.
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 31]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+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.
+
+ 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.
+
+ Finally, note that if an object has the value of its STATUS clause
+ changed, then the value of its DESCRIPTION clause should be updated
+ accordingly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 32]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+11. Appendix A: de-OSIfying a MIB module
+
+ There has been an increasing amount of work recently on taking MIBs
+ defined by other organizations (e.g., the IEEE) and de-osifying them
+ for use with the Internet-standard network management framework. The
+ steps to achieve this are straight-forward, though tedious. Of
+ course, it is helpful to already be experienced in writing MIB
+ modules for use with the Internet-standard network management
+ framework.
+
+ The first step is to construct a skeletal MIB module, as shown
+ earlier in Section 5.8. The next step is to categorize the objects
+ into groups. Optional objects are not permitted. Thus, when a MIB
+ module is created, optional objects must be placed in a additional
+ groups, which, if implemented, all objects in the group must be
+ implemented. For the first pass, it is wisest to simply ignore any
+ optional objects in the original MIB: experience shows it is better
+ to define a core MIB module first, containing only essential objects;
+ later, if experience demands, other objects can be added.
+
+11.1. Managed Object Mapping
+
+ Next for each managed object class, determine whether there can exist
+ multiple instances of that managed object class. If not, then for
+ each of its attributes, use the OBJECT-TYPE macro to make an
+ equivalent definition.
+
+ Otherwise, if multiple instances of the managed object class can
+ exist, then define a conceptual table having conceptual rows each
+ containing a columnar object for each of the managed object class's
+ attributes. If the managed object class is contained within the
+ containment tree of another managed object class, then the assignment
+ of an object is normally required for each of the "distinguished
+ attributes" of the containing managed object class. If they do not
+ already exist within the MIB module, then they can be added via the
+ definition of additional columnar objects in the conceptual row
+ corresponding to the contained managed object class.
+
+ In defining a conceptual row, it is useful to consider the
+ optimization of network management operations which will act upon its
+ columnar objects. In particular, it is wisest to avoid defining more
+ columnar objects within a conceptual row, than can fit in a single
+ PDU. As a rule of thumb, a conceptual row should contain no more
+ than approximately 20 objects. Similarly, or as a way to abide by
+ the "20 object guideline", columnar objects should be grouped into
+ tables according to the expected grouping of network management
+ operations upon them. As such, the content of conceptual rows should
+ reflect typical access scenarios, e.g., they should be organized
+
+
+
+SNMPv2 Working Group Standards Track [Page 33]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ along functional lines such as one row for statistics and another row
+ for parameters, or along usage lines such as commonly-needed objects
+ versus rarely-needed objects.
+
+ On the other hand, the definition of conceptual rows where the number
+ of columnar objects used as indexes outnumbers the number used to
+ hold information, should also be avoided. In particular, the
+ splitting of a managed object class's attributes into many conceptual
+ tables should not be used as a way to obtain the same degree of
+ flexibility/complexity as is often found in MIBs with a myriad of
+ optionals.
+
+11.1.1. Mapping to the SYNTAX clause
+
+ When mapping to the SYNTAX clause of the OBJECT-TYPE macro:
+
+(1) An object with BOOLEAN syntax becomes a TruthValue [3].
+
+(2) An object with INTEGER syntax becomes an Integer32.
+
+(3) An object with ENUMERATED syntax becomes an INTEGER with
+ enumerations, taking any of the values given which can be
+ represented with an Integer32.
+
+(4) An object with BIT STRING syntax having enumerations becomes a BITS
+ construct.
+
+(5) An object with BIT STRING syntax but no enumerations becomes an
+ OCTET STRING.
+
+(6) An object with a character string syntax becomes either an OCTET
+ STRING, or a DisplayString [3], depending on the repertoire of the
+ character string.
+
+(7) A non-tabular object with a complex syntax, such as REAL or
+ EXTERNAL, must be decomposed, usually into an OCTET STRING (if
+ sensible). As a rule, any object with a complicated syntax should
+ be avoided.
+
+(8) Tabular objects must be decomposed into rows of columnar objects.
+
+11.1.2. Mapping to the UNITS clause
+
+ If the description of this managed object defines a unit-basis, then
+ mapping to this clause is straight-forward.
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 34]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+11.1.3. Mapping to the MAX-ACCESS clause
+
+ This is straight-forward.
+
+11.1.4. Mapping to the STATUS clause
+
+ This is straight-forward.
+
+11.1.5. Mapping to the DESCRIPTION clause
+
+ This is straight-forward: simply copy the text, making sure that any
+ embedded double quotation marks are sanitized (i.e., replaced with
+ single-quotes or removed).
+
+11.1.6. Mapping to the REFERENCE clause
+
+ This is straight-forward: simply include a textual reference to the
+ object being mapped, the document which defines the object, and
+ perhaps a page number in the document.
+
+11.1.7. Mapping to the INDEX clause
+
+ If necessary, decide how instance-identifiers for columnar objects
+ are to be formed and define this clause accordingly.
+
+11.1.8. Mapping to the DEFVAL clause
+
+ Decide if a meaningful default value can be assigned to the object
+ being mapped, and if so, define the DEFVAL clause accordingly.
+
+11.2. Action Mapping
+
+ Actions are modeled as read-write objects, in which writing a
+ particular value results in a state change. (Usually, as a part of
+ this state change, some action might take place.)
+
+11.2.1. Mapping to the SYNTAX clause
+
+ Usually the Integer32 syntax is used with a distinguished value
+ provided for each action that the object provides access to. In
+ addition, there is usually one other distinguished value, which is
+ the one returned when the object is read.
+
+11.2.2. Mapping to the MAX-ACCESS clause
+
+ Always use read-write or read-create.
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 35]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+11.2.3. Mapping to the STATUS clause
+
+ This is straight-forward.
+
+11.2.4. Mapping to the DESCRIPTION clause
+
+ This is straight-forward: simply copy the text, making sure that any
+ embedded double quotation marks are sanitized (i.e., replaced with
+ single-quotes or removed).
+
+11.2.5. Mapping to the REFERENCE clause
+
+ This is straight-forward: simply include a textual reference to the
+ action being mapped, the document which defines the action, and
+ perhaps a page number in the document.
+
+11.3. Event Mapping
+
+ Events are modeled as SNMPv2 notifications using NOTIFICATION-TYPE
+ macro. However, recall that SNMPv2 emphasizes trap-directed polling.
+ As such, few, and usually no, notifications, need be defined for any
+ MIB module.
+
+11.3.1. Mapping to the STATUS clause
+
+ This is straight-forward.
+
+11.3.2. Mapping to the DESCRIPTION clause
+
+ This is straight-forward: simply copy the text, making sure that any
+ embedded double quotation marks are sanitized (i.e., replaced with
+ single-quotes or removed).
+
+11.3.3. Mapping to the REFERENCE clause
+
+ This is straight-forward: simply include a textual reference to the
+ notification being mapped, the document which defines the
+ notification, and perhaps a page number in the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 36]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+12. Appendix B: UTC Time Format
+
+ Several clauses defined in this document use the UTC Time format:
+
+ YYMMDDHHMMZ
+
+ where: YY - last two digits of year
+ MM - month (01 through 12)
+ DD - day of month (01 through 31)
+ HH - hours (00 through 23)
+ MM - minutes (00 through 59)
+ Z - the character "Z" denotes Greenwich Mean Time (GMT).
+
+ For example, "9502192015Z" represents 8:15pm GMT on 19 February 1995.
+
+13. Appendix C: Detailed Sub-typing Rules
+
+13.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.
+
+ <integerSubType>
+ ::= <empty>
+ | "(" <range> ["|" <range>]... ")"
+
+ <octetStringSubType>
+ ::= <empty>
+ | "(" "SIZE" "(" <range> ["|" <range>]... ")" ")"
+
+ <range>
+ ::= <value>
+ | <value> ".." <value>
+
+ <value>
+ ::= "-" <number>
+ | <number>
+ | <hexString>
+ | <binString>
+
+ where:
+ <empty> is the empty string
+ <number> is a non-negative integer
+ <hexString> is a hexadecimal string (i.e. 'xxxx'H)
+ <binString> is a binary string (i.e. 'xxxx'B)
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 37]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ <range> is further restricted as follows:
+ - any <value> 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.
+
+13.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))
+
+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
+
+13.3. Rules for Textual Conventions
+
+ Sub-typing of Textual Conventions (see [3]) is allowed but must be
+ valid. In particular, each range specified for the textual
+ convention must be a subset of a range specified for the base type.
+ For example,
+
+ Tc1 ::= INTEGER (1..10 | 11..20)
+ Tc2 ::= Tc1 (2..10 | 12..15) -- is valid
+ Tc3 ::= Tc1 (4..8) -- is valid
+ Tc4 ::= Tc1 (8..12) -- is invalid
+
+14. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 38]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+15. Editor's Address
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ US
+
+ Phone: +1 408 526 5260
+ EMail: kzm@cisco.com
+
+16. Acknowledgements
+
+ This document is the result of significant work by the four major
+ contributors:
+
+ Jeffrey D. Case (SNMP Research, case@snmp.com)
+ Keith McCloghrie (Cisco Systems, kzm@cisco.com)
+ Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
+ Steven Waldbusser (International Network Services, stevew@uni.ins.com)
+
+ In addition, the contributions of the SNMPv2 Working Group are
+ acknowledged. In particular, a special thanks is extended for the
+ contributions of:
+
+ Alexander I. Alten (Novell)
+ Dave Arneson (Cabletron)
+ Uri Blumenthal (IBM)
+ Doug Book (Chipcom)
+ Kim Curran (Bell-Northern Research)
+ Jim Galvin (Trusted Information Systems)
+ Maria Greene (Ascom Timeplex)
+ Iain Hanson (Digital)
+ Dave Harrington (Cabletron)
+ Nguyen Hien (IBM)
+ Jeff Johnson (Cisco Systems)
+ Michael Kornegay (Object Quest)
+ Deirdre Kostick (AT&T Bell Labs)
+ David Levi (SNMP Research)
+ Daniel Mahoney (Cabletron)
+ Bob Natale (ACE*COMM)
+ Brian O'Keefe (Hewlett Packard)
+ Andrew Pearson (SNMP Research)
+ Dave Perkins (Peer Networks)
+ Randy Presuhn (Peer Networks)
+ Aleksey Romanov (Quality Quorum)
+ Shawn Routhier (Epilogue)
+ Jon Saperia (BGS Systems)
+
+
+
+SNMPv2 Working Group Standards Track [Page 39]
+\f
+RFC 1902 SMI for SNMPv2 January 1996
+
+
+ Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
+ Kaj Tesink (Bellcore)
+ Glenn Waters (Bell-Northern Research)
+ Bert Wijnen (IBM)
+
+17. 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, "Conformance Statements for Version 2 of the Simple
+ Network Management Protocol (SNMPv2)", RFC 1904, 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] 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] 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, "Protocol Operations for Version 2 of the Simple
+ Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+[7] 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 40]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group SNMPv2 Working Group
+Request for Comments: 1905 J. Case
+Obsoletes: 1448 SNMP Research, Inc.
+Category: Standards Track K. McCloghrie
+ Cisco Systems, Inc.
+ M. Rose
+ Dover Beach Consulting, Inc.
+ S. Waldbusser
+ International Network Services
+ January 1996
+
+
+ Protocol Operations
+ 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 a subset of OSI's
+ Abstract Syntax Notation One (ASN.1) [1], termed the Structure of
+ Management Information (SMI) [2].
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 1]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ The management protocol, version 2 of the Simple Network Management
+ Protocol, provides for the exchange of messages which convey
+ management information between the agents and the management
+ stations. The form of these messages is a message "wrapper" which
+ encapsulates a Protocol Data Unit (PDU). The form and meaning of the
+ "wrapper" is determined by an administrative framework which defines
+ both authentication and authorization policies.
+
+ It is the purpose of this document, Protocol Operations for SNMPv2,
+ to define the operations of the protocol with respect to the sending
+ and receiving of the PDUs.
+
+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. Overview
+
+2.1. Roles of Protocol Entities
+
+ A SNMPv2 entity may operate in a manager role or an agent role.
+
+ A SNMPv2 entity acts in an agent role when it performs SNMPv2
+ management operations in response to received SNMPv2 protocol
+ messages (other than an inform notification) or when it sends trap
+ notifications.
+
+ A SNMPv2 entity acts in a manager role when it initiates SNMPv2
+ management operations by the generation of SNMPv2 protocol messages
+ or when it performs SNMPv2 management operations in response to
+ received trap or inform notifications.
+
+ A SNMPv2 entity may support either or both roles, as dictated by its
+ implementation and configuration. Further, a SNMPv2 entity can also
+ act in the role of a proxy agent, in which it appears to be acting in
+ an agent role, but satisfies management requests by acting in a
+ manager role with a remote entity.
+
+2.2. 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 [2] or
+ the textual conventions based on the SMI [3]. The term, variable
+ binding, normally refers to the pairing of the name of a variable and
+
+
+
+SNMPv2 Working Group Standards Track [Page 2]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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.3. Access to Management Information
+
+ Three types of access to management information are provided by the
+ protocol. One type is a request-response interaction, in which a
+ SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
+ entity, acting in an agent role, and the latter SNMPv2 entity then
+ responds to the request. This type is used to retrieve or modify
+ management information associated with the managed device.
+
+ A second type is also a request-response interaction, in which a
+ SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
+ entity, also acting in a manager role, and the latter SNMPv2 entity
+ then responds to the request. This type is used to notify a SNMPv2
+ entity, acting in a manager role, of management information
+ associated with another SNMPv2 entity, also acting in a manager role.
+
+ The third type of access is an unconfirmed interaction, in which a
+ SNMPv2 entity, acting in an agent role, sends a unsolicited message,
+ termed a trap, to a SNMPv2 entity, acting in a manager role, and no
+ response is returned. This type is used to notify a SNMPv2 entity,
+ acting in a manager role, of an exceptional situation, which has
+ resulted in changes to management information associated with the
+ managed device.
+
+2.4. 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.
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 3]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+2.5. Message Sizes
+
+ The maximum size of a SNMPv2 message is limited to the minimum of:
+
+(1) the maximum message size which the destination SNMPv2 entity can
+ accept; and,
+
+(2) the maximum message size which the source SNMPv2 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 SNMPv2 indicates the minimum message
+ size which a SNMPv2 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 SNMPv2 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 a SNMPv2 entity acting in a manager role 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 SNMPv2 entity acting in an agent role can generate, and the
+ SNMPv2 entity acting in a manager role 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
+ [4], since among other problems, it leads to a decrease in the
+ reliability of the transfer of the messages. Thus, a SNMPv2 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.6. Transport Mappings
+
+ It is important to note that the exchange of SNMPv2 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 [5]. However, the preferred mapping is the use of the User
+
+
+
+SNMPv2 Working Group Standards Track [Page 4]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ Datagram Protocol [6].
+
+3. Definitions
+
+ SNMPv2-PDU DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ ObjectName, ObjectSyntax, Integer32
+ FROM SNMPv2-SMI;
+
+
+ -- 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 ::=
+
+
+
+SNMPv2 Working Group Standards Track [Page 5]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ [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 presently
+ -- defined. Any SNMP administrative framework making use of
+ -- this PDU must define its usage and semantics.
+ Report-PDU ::=
+ [8]
+ IMPLICIT PDU
+
+ max-bindings
+ INTEGER ::= 2147483647
+
+ PDU ::=
+ SEQUENCE {
+ request-id
+ Integer32,
+
+ 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),
+
+
+
+SNMPv2 Working Group Standards Track [Page 6]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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
+ Integer32,
+
+ non-repeaters
+ INTEGER (0..max-bindings),
+
+ max-repetitions
+ INTEGER (0..max-bindings),
+
+ variable-bindings -- values are ignored
+ VarBindList
+ }
+
+
+ -- variable binding
+
+ VarBind ::=
+ SEQUENCE {
+ name
+ ObjectName,
+
+ CHOICE {
+ value
+
+
+
+SNMPv2 Working Group Standards Track [Page 7]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ ObjectSyntax,
+
+ unSpecified -- in retrieval requests
+ NULL,
+
+ -- 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, a SNMPv2 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 SNMPv2 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.
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 8]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ A non-zero value of the error-status field in a Response-PDU is used
+ to indicate that an exception 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 exception. 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.
+
+ SNMPv2 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
+
+ It is mandatory that all SNMPv2 entities acting in an agent role be
+ able to generate the following PDU types: Response-PDU and SNMPv2-
+ Trap-PDU; further, all such implementations must be able to receive
+ the following PDU types: GetRequest-PDU, GetNextRequest-PDU,
+ GetBulkRequest-PDU, and SetRequest-PDU.
+
+ It is mandatory that all SNMPv2 entities acting in a manager role be
+ able to generate the following PDU types: GetRequest-PDU,
+ GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
+ InformRequest-PDU, and Response-PDU; further, all such
+ implementations must be able to receive the following PDU types:
+ Response-PDU, SNMPv2-Trap-PDU,
+
+ InformRequest-PDU;
+
+ In the elements of procedure below, any field of a PDU which is not
+ referenced by the relevant procedure is ignored by the receiving
+ SNMPv2 entity. However, all components of a PDU, including those
+ whose values are ignored by the receiving SNMPv2 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 SNMPv2 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 is followed. While
+ the definition of "max-bindings" does impose an upper-bound on the
+ number of variable bindings, in practice, the size of a message is
+ limited only by constraints on the maximum message size -- it is not
+ limited by the number of variable bindings.
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 9]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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 a
+ SNMPv2 application.
+
+ Upon receipt of a GetRequest-PDU, the receiving SNMPv2 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.
+
+(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
+
+
+
+SNMPv2 Working Group Standards Track [Page 10]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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
+ [9] 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 a
+ SNMPv2 application.
+
+ Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 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 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.
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 11]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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 [9] 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.
+
+ In the protocol exchange sketched below, a SNMPv2 application
+ retrieves the media-dependent physical address and the address-
+ mapping type for each entry in the IP net-to-media Address
+ Translation Table [7] of a particular network element. It also
+ retrieves the value of sysUpTime [9], at which the mappings existed.
+ Suppose that the agent'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 SNMPv2 entity acting in a manager role begins by sending a
+ GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values
+ as the requested variable names:
+
+ GetNextRequest ( sysUpTime,
+ ipNetToMediaPhysAddress,
+ ipNetToMediaType )
+
+ The SNMPv2 entity acting in an agent role responds with a Response-
+ PDU:
+
+ Response (( sysUpTime.0 = "123456" ),
+ ( ipNetToMediaPhysAddress.1.9.2.3.4 =
+ "000010543210" ),
+ ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))
+
+
+
+SNMPv2 Working Group Standards Track [Page 12]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ The SNMPv2 entity acting in a manager role continues with:
+
+ GetNextRequest ( sysUpTime,
+ ipNetToMediaPhysAddress.1.9.2.3.4,
+ ipNetToMediaType.1.9.2.3.4 )
+
+ The SNMPv2 entity acting in an agent role responds with:
+
+ Response (( sysUpTime.0 = "123461" ),
+ ( ipNetToMediaPhysAddress.1.10.0.0.51 =
+ "000010012345" ),
+ ( ipNetToMediaType.1.10.0.0.51 = "static" ))
+
+ The SNMPv2 entity acting in a manager role continues with:
+
+ GetNextRequest ( sysUpTime,
+ ipNetToMediaPhysAddress.1.10.0.0.51,
+ ipNetToMediaType.1.10.0.0.51 )
+
+ The SNMPv2 entity acting in an agent role responds with:
+
+ Response (( sysUpTime.0 = "123466" ),
+ ( ipNetToMediaPhysAddress.2.10.0.0.15 =
+ "000010987654" ),
+ ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))
+
+ The SNMPv2 entity acting in a manager role 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 SNMPv2 entity
+ acting in an agent role 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" ))
+
+ This response signals the end of the table to the SNMPv2 entity
+ acting in a manager role.
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 13]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+4.2.3. The GetBulkRequest-PDU
+
+ A GetBulkRequest-PDU is generated and transmitted at the request of a
+ SNMPv2 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 SNMPv2 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. Processing begins by examining the values
+ in the non-repeaters and max-repetitions fields. If the value in the
+ non-repeaters field is less than zero, then the value of the field is
+ set to zero. Similarly, if the value in the max-repetitions field is
+ less than zero, then the value of the field is set to zero.
+
+ 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-
+ 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 SNMPv2 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
+
+
+
+SNMPv2 Working Group Standards Track [Page 14]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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:
+
+(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.
+
+
+
+SNMPv2 Working Group Standards Track [Page 15]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+(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 the `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 an agent may terminate the request with less
+ than the full number of repetitions, providing at least one
+ repetition is completed.
+
+ 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 [9] 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 SNMPv2 entity acting in a manager role 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 )
+
+
+
+SNMPv2 Working Group Standards Track [Page 16]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ The SNMPv2 entity acting in an agent role 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" ))
+
+ The SNMPv2 entity acting in a manager role continues with:
+
+ GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
+ ( sysUpTime,
+ ipNetToMediaPhysAddress.1.10.0.0.51,
+ ipNetToMediaType.1.10.0.0.51 )
+
+ The SNMPv2 entity acting in an agent role 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" ))
+
+ This response signals the end of the table to the SNMPv2 entity
+ acting in a manager role.
+
+4.2.4. The Response-PDU
+
+ The Response-PDU is generated by a SNMPv2 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.
+
+
+
+SNMPv2 Working Group Standards Track [Page 17]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ A compliant SNMPv2 entity acting in a manager role must be able to
+ properly receive and handle a Response-PDU with an error-status field
+ equal to `noSuchName', `badValue', or `readOnly'. (See Section 3.1.2
+ of [8].)
+
+ Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents
+ its contents to the SNMPv2 application which generated the request
+ with the same request-id value.
+
+4.2.5. The SetRequest-PDU
+
+ A SetRequest-PDU is generated and transmitted at the request of a
+ SNMPv2 application.
+
+ Upon receipt of a SetRequest-PDU, the receiving SNMPv2 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 [9] counter is incremented and the resultant message
+ is discarded. Regardless, processing of the SetRequest-PDU
+ terminates.
+
+ Otherwise, the receiving SNMPv2 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.
+
+
+
+SNMPv2 Working Group Standards Track [Page 18]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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.
+
+(7) Otherwise, if the variable binding's name specifies a variable
+ which does not exist and could not ever be created (even though
+
+
+
+SNMPv2 Working Group Standards Track [Page 19]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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.
+
+ 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
+
+
+
+SNMPv2 Working Group Standards Track [Page 20]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ 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
+
+ A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity
+ acting in an agent role when an exceptional situation occurs.
+
+ The destination(s) to which a SNMPv2-Trap-PDU is sent is determined
+ in an implementation-dependent fashion by the SNMPv2 entity. The
+ first two variable bindings in the variable binding list of an
+ SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9]
+ 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 SNMPv2 entity), then
+ each is copied to the variable-bindings field.
+
+4.2.7. The InformRequest-PDU
+
+ An InformRequest-PDU is generated and transmitted at the request of
+ an application in a SNMPv2 entity acting in a manager role, that
+ wishes to notify another application (in a SNMPv2 entity also acting
+ in a manager role) of information in a MIB view which is remote to
+ the receiving application.
+
+ The destination(s) to which an InformRequest-PDU is sent is specified
+ by the requesting application. The first two variable bindings in
+
+
+
+SNMPv2 Working Group Standards Track [Page 21]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ the variable binding list of an InformRequest-PDU are sysUpTime.0 [9]
+ and snmpTrapOID.0 [9] 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.
+
+ Upon receipt of an InformRequest-PDU, the receiving SNMPv2 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 [9] counter is
+ incremented and the resultant message is discarded. Regardless,
+ processing of the InformRequest-PDU terminates.
+
+ Otherwise, the receiving SNMPv2 entity:
+
+(1) presents its contents to the appropriate SNMPv2 application;
+
+(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 is set to `noError' and the
+ value of its error-index field is zero; and
+
+(3) transmits the generated Response-PDU to the originator of the
+ InformRequest-PDU.
+
+5. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 22]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+6. Editor's Address
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ US
+
+ Phone: +1 408 526 5260
+ EMail: kzm@cisco.com
+
+7. Acknowledgements
+
+ This document is the result of significant work by the four major
+ contributors:
+
+ Jeffrey D. Case (SNMP Research, case@snmp.com)
+ Keith McCloghrie (Cisco Systems, kzm@cisco.com)
+ Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
+ Steven Waldbusser (International Network Services, stevew@uni.ins.com)
+
+ In addition, the contributions of the SNMPv2 Working Group are
+ acknowledged. In particular, a special thanks is extended for the
+ contributions of:
+
+ Alexander I. Alten (Novell)
+ Dave Arneson (Cabletron)
+ Uri Blumenthal (IBM)
+ Doug Book (Chipcom)
+ Kim Curran (Bell-Northern Research)
+ Jim Galvin (Trusted Information Systems)
+ Maria Greene (Ascom Timeplex)
+ Iain Hanson (Digital)
+ Dave Harrington (Cabletron)
+ Nguyen Hien (IBM)
+ Jeff Johnson (Cisco Systems)
+ Michael Kornegay (Object Quest)
+ Deirdre Kostick (AT&T Bell Labs)
+ David Levi (SNMP Research)
+ Daniel Mahoney (Cabletron)
+ Bob Natale (ACE*COMM)
+ Brian O'Keefe (Hewlett Packard)
+ Andrew Pearson (SNMP Research)
+ Dave Perkins (Peer Networks)
+ Randy Presuhn (Peer Networks)
+ Aleksey Romanov (Quality Quorum)
+ Shawn Routhier (Epilogue)
+ Jon Saperia (BGS Systems)
+
+
+
+SNMPv2 Working Group Standards Track [Page 23]
+\f
+RFC 1905 Protocol Operations for SNMPv2 January 1996
+
+
+ Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
+ Kaj Tesink (Bellcore)
+ Glenn Waters (Bell-Northern Research)
+ Bert Wijnen (IBM)
+
+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] 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] Kent, C., and J. Mogul, Fragmentation Considered Harmful,
+ Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
+
+[5] 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.
+
+[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ USC/Information Sciences Institute, August 1980.
+
+[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] 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] 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.
+
+
+
+
+
+
+
+SNMPv2 Working Group Standards Track [Page 24]
+\f
projects / thirdparty / squid.git / commitdiff
