📄 rfc1902.txt
字号:
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]
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]
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]
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]
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]
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]
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:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -