Request for Comments: 3781 TU Braunschweig
Category: Experimental J. Schoenwaelder
International University Bremen
May 2004
Next Generation Structure of Management Information (SMIng)
Mappings to the Simple Network Management Protocol (SNMP)
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
SMIng (Structure of Management Information, Next Generation)
(RFC3780), is a protocol-independent data definition language for
management information. This memo defines an SMIng language
extension that specifies the mapping of SMIng definitions of
identities, classes, and their attributes and events to dedicated
definitions of nodes, scalar objects, tables and columnar objects,
and notifications, for application to the SNMP management framework.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SNMP Based Internet Management . . . . . . . . . . . . . . . . 3
2.1. Kinds of Nodes. . . . . . . . . . . . . . . . . . . . . 4
2.2. Scalar and Columnar Object Instances. . . . . . . . . . 5
2.3. Object Identifier Hierarchy . . . . . . . . . . . . . . 7
3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . . . 8
3.1. ASN.1 Definitions . . . . . . . . . . . . . . . . . . . 9
4. The snmp Extension Statement . . . . . . . . . . . . . . . . . 10
4.1. The oid Statement . . . . . . . . . . . . . . . . . . . 10
4.2. The node Statement. . . . . . . . . . . . . . . . . . . 10
4.2.1. The node’s oid Statement . . . . . . . . . . . . 10
4.2.2. The node’s represents Statement. . . . . . . . . 10
4.2.3. The node’s status Statement. . . . . . . . . . . 11
4.2.4. The node’s description Statement . . . . . . . . 11
4.2.5. The node’s reference Statement . . . . . . . . . 11
4.2.6. Usage Examples . . . . . . . . . . . . . . . . . 11
4.3. The scalars Statement . . . . . . . . . . . . . . . . . 11
4.3.1. The scalars’ oid Statement . . . . . . . . . . . 12
4.3.2. The scalars’ object Statement . . . . . . . . . 12
4.3.3. The scalars’ status Statement . . . . . . . . . 13
4.3.4. The scalars’ description Statement . . . . . . . 14
4.3.5. The scalars’ reference Statement . . . . . . . . 14
4.3.6. Usage Example. . . . . . . . . . . . . . . . . . 14
4.4. The table Statement . . . . . . . . . . . . . . . . . . 14
4.4.1. The table’s oid Statement. . . . . . . . . . . . 15
4.4.2. Table Indexing Statements. . . . . . . . . . . . 15
4.4.3. The table’s create Statement . . . . . . . . . . 17
4.4.4. The table’s object Statement . . . . . . . . . . 17
4.4.5. The table’s status Statement . . . . . . . . . . 19
4.4.6. The table’s description Statement . . . . . . . 19
4.4.7. The table’s reference Statement . . . . . . . . 19
4.4.8. Usage Example . . . . . . . . . . . . . . . . . 19
4.5. The notification Statement . . . . . . . . . . . . . . 20
4.5.1. The notification’s oid Statement . . . . . . . . 20
4.5.2. The notification’s signals Statement . . . . . . 20
4.5.3. The notification’s status Statement . . . . . . 20
4.5.4. The notification’s description Statement . . . . 21
4.5.5. The notification’s reference Statement . . . . . 21
4.5.6. Usage Example. . . . . . . . . . . . . . . . . . 21
4.6. The group Statement . . . . . . . . . . . . . . . . . . 21
4.6.1. The group’s oid Statement . . . . . . . . . . . 22
4.6.2. The group’s members Statement . . . . . . . . . 22
4.6.3. The group’s status Statement . . . . . . . . . . 22
4.6.4. The group’s description Statement . . . . . . . 22
4.6.5. The group’s reference Statement . . . . . . . . 22
4.6.6. Usage Example . . . . . . . . . . . . . . . . . 22
4.7. The compliance Statement. . . . . . . . . . . . . . . . 23
4.7.1. The compliance’s oid Statement . . . . . . . . . 23
4.7.2. The compliance’s status Statement . . . . . . . 23
4.7.3. The compliance’s description Statement . . . . . 23
4.7.4. The compliance’s reference Statement . . . . . . 23
4.7.5. The compliance’s mandatory Statement . . . . . . 24
4.7.6. The compliance’s optional Statement. . . . . . . 24
4.7.7. The compliance’s refine Statement . . . . . . . 24
4.7.8. Usage Example . . . . . . . . . . . . . . . . . 26
5. NMRG-SMING-SNMP-EXT . . . . . . . . . . . . . . . . . . . . . 26
6. NMRG-SMING-SNMP . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Normative References. . . . . . . . . . . . . . . . . . 47
9.2. Informative References. . . . . . . . . . . . . . . . . 47
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
SMIng (Structure of Management Information, Next Generation)
[RFC3780] is a protocol-independent data definition language for
management information. This memo defines an SMIng language
extension that specifies the mapping of SMIng definitions of
identities, classes, and their attributes and events to dedicated
definitions of nodes, scalar objects, tables and columnar objects,
and notifications for application in the SNMP management framework.
Section 2 introduces basics of the SNMP management framework.
Section 3 defines how SMIng data types are mapped to the data types
supported by the SNMP protocol. It introduces some new ASN.1 [ASN1]
definitions which are used to represent new SMIng base types such as
floats in the SNMP protocol.
Section 4 describes the semantics of the SNMP mapping extensions for
SMIng. The formal SMIng specification of the extension is provided
in Section 5.
Section 6 contains an SMIng module which defines derived types (such
as RowStatus) that are specific to the SNMP mapping.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. SNMP-Based Internet Management
The SNMP network management framework [RFC3410] is based on the
concept of "managed objects". Managed objects represent real or
synthesized variables of systems that are to be managed. Note that
in spite of these terms this model is not object-oriented. For
naming purposes, the managed objects are organized hierarchically in
an "object identifier tree", where only leaf nodes may represent
objects.
Nodes in the object identifier tree may also identify conceptual
tables, rows of conceptual tables, notifications, groups of objects
and/or notifications, compliance statements, modules or other
information. Each node is identified by an unique "object
identifier" value which is a sequence of non-negative numbers, named
"sub-identifiers", where the left-most sub-identifier refers to the
node next to the root of the tree and the right-most sub-identifier
refers to the node that is identified by the complete object
identifier value. Each sub-identifier has a value between 0 and
2^32-1 (4294967295).
The SMIng extensions described in this document are used to map SMIng
data definitions to SNMP compliant managed objects. This mapping is
designed to be readable to computer programs, named MIB compilers, as
well as to human readers.
2.1. Kinds of Nodes
Each node in the object identifier tree is of a certain kind and may
represent management information or not:
o Simple nodes, that do not represent management information, but
may be used for grouping nodes in a subtree. Those nodes are
defined by the `node’ statement. This statement can also be used
to map an SMIng `identity’ to a node.
o Nodes representing the identity of a module to allow references to
a module in other objects of type `ObjectIdentifier’. Those nodes
are defined by the `snmp’ statement,
o Scalar objects, which have exactly one object instance and no
child nodes. See Section 2.2 for scalar objects’ instances. A
set of scalar objects is mapped from one or more SMIng classes
using the `scalars’ statement. The statement block of the
`scalars’ statement contains one `implements’ statement for each
class. The associated statement blocks in turn contain `object’
statements that specify the mapping of attributes to scalar
objects. Scalar objects MUST not have any child node.
o Tables, which represent the root node of a collection of
information structured in table rows. Table nodes are defined by
the `table’ statement. A table object identifier SHOULD not have
any other child node than the implicitly defined row node (see
below).
o Rows, which belong to a table (that is, row’s object identifier
consists of the table’s full object identifier plus a single `1’
sub-identifier) and represent a sequence of one or more columnar
objects. A row node is implicitly defined for each table node.
o Columnar objects, which belong to a row (that is, the columnar
objects’ object identifier consists of the row’s full object
identifier plus a single column-identifying sub-identifier) and
have zero or more object instances and no child nodes. They are
defined as follows: The classes that are implemented by a `table’
statement are identified by `implements’ statements. The
statement block of each `implements’ statement contains `object’
statements that specify the mapping of attributes to columnar
objects of this table. Columnar objects MUST not have any child
node.
o Notifications, which represent information that is sent by agents
within unsolicited transmissions. The `notification’ statement is
used to map an SMIng event to a notification. A notification’s
object identifier SHOULD not have any child node.
o Groups of objects and notifications, which may be used for
compliance statements. They are defined using the `group’
statement.
o Compliance statements which define requirements for MIB module
implementations. They are defined using the `compliance’
statement.
2.2. Scalar and Columnar Object Instances
Instances of managed objects are identified by appending an
instance-identifier to the object’s object identifier. Scalar
objects and columnar objects use different ways to construct the
instance-identifier.
Scalar objects have exactly one object instance. It is identified by
appending a single `0’ sub-identifier to the object identifier of the
scalar object.
Within tables, different instances of the same columnar object are
identified by appending a sequence of one or more sub-identifiers to
the object identifier of the columnar object which consists of the
values of object instances that unambiguously distinguish a table
row. These indexing objects can be columnar objects of the same
and/or another table, but MUST NOT be scalar objects. Multiple
applications of the same object in a single table indexing
specification are strongly discouraged.
The base types of the indexing objects indicate how to form the
instance-identifier:
o integer-valued or enumeration-valued: a single sub-identifier
taking the integer value (this works only for non-negative
integers and integers of a size of up to 32 bits),
o string-valued, fixed-length strings (or variable-length with
compact encoding): `n’ sub-identifiers, where `n’ is the length of
the string (each octet of the string is encoded in a separate
sub-identifier),
o string-valued, variable-length strings or bits-valued: `n+1’ sub-
identifiers, where `n’ is the length of the string or bits
encoding (the first sub-identifier is `n’ itself, following this,
each octet of the string or bits is encoded in a separate sub-
identifier),
o object identifier-valued (with compact encoding): `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),
o object identifier-valued: `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),
Note that compact encoding can only be applied to an object having a
variable-length syntax (e.g., variable-length strings, bits objects
or object identifier-valued objects). Further, compact encoding can
only be associated with the last object in a list of indexing
objects. Finally, compact encoding MUST 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 or enumeration-valued
objects are RECOMMENDED to be numbered starting from one (i.e., not
from zero). Integer objects that allow negative values, Unsigned64
objects, Integer64 objects and floating point objects MUST NOT be
used for table indexing.
Objects which are both specified for indexing in a row and also
columnar objects of the same row are termed auxiliary objects.
Auxiliary objects SHOULD be non-accessible, except in the following
circumstances:
o within a module originally written to conform to SMIv1, or
o a row must contain at least one columnar object which is not an
auxiliary object. In the event that all of a row’s columnar
objects are also specified to be indexing objects then one of them
MUST be accessible.
2.3. Object Identifier Hierarchy
The layers of the object identifier tree near the root are well
defined and organized by standardization bodies. The first level
next to the root has three nodes:
0: ccitt
1: iso
2: joint-iso-ccitt
Note that the renaming of the Commite Consultatif International de
Telegraphique et Telephonique (CCITT) to International
Telecommunications Union (ITU) had no consequence on the names used
in the object identifier tree.
The root of the subtree administered by the Internet Assigned Numbers
Authority (IANA) for the Internet is `1.3.6.1’ which is assigned with
the identifier `internet’. 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:
The `mgmt’ (internet.2) subtree is used to identify "standard"
definitions. An information module produced by an IETF working group
becomes a "standard" information module when the document is first
approved by the IESG and enters the Internet standards track.
The `experimental’ (internet.3) subtree is used to identify
experimental definitions being designed by working groups of the IETF
or IRTF. If an information module produced by a working group
becomes a "standard" module, then at the very beginning of its entry
onto the Internet standards track, the definitions are moved under
the mgmt subtree.
The `private’ (internet.4) subtree is used to identify definitions
defined unilaterally. The `enterprises’ (private.1) subtree beneath
private is used, among other things, to permit providers of
networking subsystems to register information modules of their
products.
These and some other nodes are defined in the SMIng module NMRG-
SMING-SNMP-EXT (Section 5).
3. SMIng Data Type Mappings
SMIng [RFC3780] supports the following set of base types:
OctetString, Pointer, Integer32, Integer64, Unsigned32, Unsigned64,
Float32, Float64, Float128, Enumeration, Bits, and ObjectIdentifier.
The SMIng core module NMRG-SMING ([RFC3780], Appendix A) defines
additional derived types, among them Counter32 (derived from
Unsigned32), Counter64 (derived from Unsigned64), TimeTicks32 and
TimeTicks64 (derived from Unsigned32 and Unsigned64), IpAddress
(derived from OctetString), and Opaque (derived from OctetString).
The version 2 of the protocol operations for SNMP document [RFC3416]
defines the following 9 data types which are distinguished by the
protocol: INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress,
Counter32, TimeTicks, Opaque, Counter64, and Unsigned32.
The SMIng base types and their derived types are mapped to SNMP data
types according to the following table:
SMIng Data Type SNMP Data Type Comment
--------------- ------------------- -------
OctetString OCTET STRING (1)
Pointer OBJECT IDENTIFIER
Integer32 INTEGER
Integer64 Opaque (Integer64) (2)
Unsigned32 Unsigned32 (3)
Unsigned64 Opaque (Unsigned64) (2) (4)
Float32 Opaque (Float32) (2)
Float64 Opaque (Float64) (2)
Float128 Opaque (Float128) (2)
Enumeration INTEGER
Bits OCTET STRING
ObjectIdentifier OBJECT IDENTIFIER
Counter32 Counter32
Counter64 Counter64
TimeTicks32 TimeTicks
TimeTicks64 Opaque (Unsigned64) (2)
IpAddress IpAddress
Opaque Opaque
(1) This mapping includes all types derived from the OctetString
type except those types derived from the IpAddress and Opaque
SMIng types defined in the module NMRG-SMING.
(2) This type is encoded according to the ASN.1 type with the same
name defined in Section 3.1. The resulting BER encoded value
is then wrapped in an Opaque value.
(3) This mapping includes all types derived from the Unsigned32
type except those types derived from the Counter32 and
TimeTicks32 SMIng types defined in the module NMRG-SMING.
(4) This mapping includes all types derived from the Unsigned64
type except those types derived from the Counter64 SMIng type
defined in the module NMRG-SMING.
3.1. ASN.1 Definitions
The ASN.1 [ASN1] type definitions below introduce data types which
are used to map the new SMIng base types into the set of ASN.1 types
supported by the second version of SNMP protocol operations
[RFC3416].
NMRG-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN
Integer64 ::=
[APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64
[APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615)
Float32
[APPLICATION 12]
IMPLICIT OCTET STRING (SIZE (4))
Float64
[APPLICATION 13]
IMPLICIT OCTET STRING (SIZE (8))
Float128
[APPLICATION 14]
IMPLICIT OCTET STRING (SIZE (16))
END
The definitions of Integer64 and Unsigned64 are consistent with the
same definitions in the SPPI [RFC3159]. The floating point types
Float32, Float64 and Float128 support single, double and quadruple
IEEE floating point values. The encoding of the values follows the
"IEEE Standard for Binary Floating-Point Arithmetic" as defined in
ANSI/IEEE Standard 754-1985 [IEEE754].
4. The snmp Extension Statement
The `snmp’ statement is the main statement of the SNMP mapping
specification. It gets one or two arguments: an optional lower-case
identifier that specifies a node that represents the module’s
identity, and a mandatory statement block that contains all details
of the SNMP mapping. All information of an SNMP mapping are mapped
to an SNMP conformant module of the same name as the containing SMIng
module. A single SMIng module must not contain more than one `snmp’
statement.
4.1. The oid Statement
The snmp’s `oid’ statement, which must be present, if the snmp
statement contains a module identifier and must be absent otherwise,
gets one argument which specifies the object identifier value that is
assigned to this module’s identity node.
4.2. The node Statement
The `node’ statement is used to name and describe a node in the