Request for Comments: 3780 TU Braunschweig
Category: Experimental J. Schoenwaelder
International University Bremen
May 2004
SMIng - Next Generation Structure of Management Information
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
This memo defines the base SMIng (Structure of Management
Information, Next Generation) language. SMIng is a data definition
language that provides a protocol-independent representation for
management information. Separate RFCs define mappings of SMIng to
specific management protocols, including SNMP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The History of SMIng . . . . . . . . . . . . . . . . . . 4
1.2. Terms of Requirement Levels. . . . . . . . . . . . . . . 5
2. SMIng Data Modeling. . . . . . . . . . . . . . . . . . . . . . 5
2.1. Identifiers. . . . . . . . . . . . . . . . . . . . . . . 6
3. Base Types and Derived Types . . . . . . . . . . . . . . . . . 7
3.1. OctetString. . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Pointer. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . 9
3.4. Integer32. . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Integer64. . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 13
3.8. Float32. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9. Float64. . . . . . . . . . . . . . . . . . . . . . . . . 14
3.10. Float128 . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11. Enumeration. . . . . . . . . . . . . . . . . . . . . . . 17
3.12. Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.13. Display Formats. . . . . . . . . . . . . . . . . . . . . 18
4. The SMIng File Structure . . . . . . . . . . . . . . . . . . . 20
4.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Textual Data . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Statements and Arguments . . . . . . . . . . . . . . . . 21
5. The module Statement . . . . . . . . . . . . . . . . . . . . . 21
5.1. The module’s import Statement. . . . . . . . . . . . . . 22
5.2. The module’s organization Statement. . . . . . . . . . . 23
5.3. The module’s contact Statement . . . . . . . . . . . . . 23
5.4. The module’s description Statement . . . . . . . . . . . 23
5.5. The module’s reference Statement . . . . . . . . . . . . 23
5.6. The module’s revision Statement. . . . . . . . . . . . . 23
5.6.1. The revision’s date Statement . . . . . . . . . . 24
5.6.2. The revision’s description Statement. . . . . . . 24
5.7. Usage Example. . . . . . . . . . . . . . . . . . . . . . 24
6. The extension Statement. . . . . . . . . . . . . . . . . . . . 25
6.1. The extension’s status Statement . . . . . . . . . . . . 25
6.2. The extension’s description Statement. . . . . . . . . . 26
6.3. The extension’s reference Statement. . . . . . . . . . . 26
6.4. The extension’s abnf Statement . . . . . . . . . . . . . 26
6.5. Usage Example. . . . . . . . . . . . . . . . . . . . . . 26
7. The typedef Statement. . . . . . . . . . . . . . . . . . . . . 27
7.1. The typedef’s type Statement . . . . . . . . . . . . . . 27
7.2. The typedef’s default Statement. . . . . . . . . . . . . 27
7.3. The typedef’s format Statement . . . . . . . . . . . . . 27
7.4. The typedef’s units Statement. . . . . . . . . . . . . . 28
7.5. The typedef’s status Statement . . . . . . . . . . . . . 28
7.6. The typedef’s description Statement. . . . . . . . . . . 29
7.7. The typedef’s reference Statement. . . . . . . . . . . . 29
7.8. Usage Examples . . . . . . . . . . . . . . . . . . . . . 29
8. The identity Statement . . . . . . . . . . . . . . . . . . . . 30
8.1. The identity’s parent Statement. . . . . . . . . . . . . 30
8.2. The identity’s status Statement. . . . . . . . . . . . . 30
8.3. The identity’ description Statement. . . . . . . . . . . 31
8.4. The identity’s reference Statement . . . . . . . . . . . 31
8.5. Usage Examples . . . . . . . . . . . . . . . . . . . . . 31
9. The class Statement. . . . . . . . . . . . . . . . . . . . . . 32
9.1. The class’ extends Statement . . . . . . . . . . . . . . 32
9.2. The class’ attribute Statement . . . . . . . . . . . . . 32
9.2.1. The attribute’s type Statement. . . . . . . . . . 32
9.2.2. The attribute’s access Statement. . . . . . . . . 32
9.2.3. The attribute’s default Statement . . . . . . . . 33
9.2.4. The attribute’s format Statement. . . . . . . . . 33
9.2.5. The attribute’s units Statement . . . . . . . . . 33
9.2.6. The attribute’s status Statement. . . . . . . . . 34
9.2.7. The attribute’s description Statement . . . . . . 34
9.2.8. The attribute’s reference Statement . . . . . . . 34
9.3. The class’ unique Statement. . . . . . . . . . . . . . . 35
9.4. The class’ event Statement . . . . . . . . . . . . . . . 35
9.4.1. The event’s status Statement. . . . . . . . . . . 35
9.4.2. The event’s description Statement . . . . . . . . 35
9.4.3. The event’s reference Statement . . . . . . . . . 36
9.5. The class’ status Statement. . . . . . . . . . . . . . . 36
9.6. The class’ description Statement . . . . . . . . . . . . 36
9.7. The class’ reference Statement . . . . . . . . . . . . . 37
9.8. Usage Example. . . . . . . . . . . . . . . . . . . . . . 37
10. Extending a Module . . . . . . . . . . . . . . . . . . . . . . 38
11. SMIng Language Extensibility . . . . . . . . . . . . . . . . . 39
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. NMRG-SMING Module . . . . . . . . . . . . . . . . . . 44
Appendix B. SMIng ABNF Grammar. . . . . . . . . . . . . . . . . . 53
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction
In traditional management systems, 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 in conformance with a specification language, the Structure
of Management Information (SMI). There are different versions of the
SMI. The SMI version 1 (SMIv1) is defined in [RFC1155], [RFC1212],
[RFC1215], and the SMI version 2 (SMIv2) in [RFC2578], [RFC2579], and
[RFC2580]. Both are based on adapted subsets of OSI’s Abstract
Syntax Notation One, ASN.1 [ASN1].
In a similar fashion, policy provisioning information is viewed as a
collection of Provisioning Classes (PRCs) and Provisioning Instances
(PRIs) residing in a virtual information store, termed the Policy
Information Base (PIB). Collections of related Provisioning Classes
are defined in PIB modules. PIB modules are written using the
Structure of Policy Provisioning Information (SPPI) [RFC3159] which
is an adapted subset of SMIv2.
The SMIv1 and the SMIv2 are bound to the Simple Network Management
Protocol (SNMP) [RFC3411], while the SPPI is bound to the Common Open
Policy Service Provisioning (COPS-PR) Protocol [RFC3084]. Even
though the languages have common rules, it is hard to use common data
definitions with both protocols. It is the purpose of this document
to define a common data definition language, named SMIng, that can
formally specify data models independent of specific protocols and
applications. The appendix of this document defines a core module
that supplies common SMIng definitions.
A companion document contains an SMIng language extension to define
SNMP specific mappings of SMIng definitions in compatibility with
SMIv2 MIB modules [RFC3781]. Additional language extensions may be
added in the future, e.g., to define COPS-PR specific mappings of
SMIng definitions in a way that is compatible with SPPI PIBs.
Section 2 gives an overview of the basic concepts of data modeling
using SMIng, while the subsequent sections present the concepts of
the SMIng language in detail: the base types, the SMIng file
structure, and all SMIng core statements.
The remainder of the document describes extensibility features of the
language and rules to follow when changes are applied to a module.
Appendix B contains the grammar of SMIng in ABNF [RFC2234] notation.
1.1. The History of SMIng
SMIng started in 1999 as a research project to address some drawbacks
of SMIv2, the current data modeling language for management
information bases. Primarily, its partial dependence on ASN.1 and a
number of exception rules turned out to be problematic. In 2000, the
work was handed over to the IRTF Network Management Research Group
where it was significantly detailed. Since the work of the RAP
Working Group on COPS-PR and SPPI emerged in 1999/2000, SMIng was
split into two parts: a core data definition language (defined in
this document) and protocol mappings to allow the application of core
definitions through (potentially) multiple management protocols. The
replacement of SMIv2 and SPPI by a single merged data definition
language was also a primary goal of the IETF SMING Working Group that
was chartered at the end of 2000.
The requirements for a new data definition language were discussed
several times within the IETF SMING Working Group and changed
significantly over time [RFC3216], so that another proposal (in
addition to SMIng), named SMI Data Structures (SMI-DS), was presented
to the Working Group. In the end, neither of the two proposals found
enough consensus and support, and the attempt to merge the existing
concepts did not succeed, resulting in the Working Group being closed
down in April 2003.
In order to record the work of the NMRG (Network Management Research
Group) on SMIng, this memo and the accompanying memo on the SNMP
protocol mapping [RFC3781] have been published for informational
purposes.
Note that throughout these documents, the term "SMIng" refers to the
specific data modeling language that is specified in this document,
whereas the term "SMING" refers to the general effort within the IETF
Working Group to define a new management data definition language as
an SMIv2 successor and probably an SPPI merger, for which "SMIng" and
"SMI-DS" were two specific proposals.
1.2. Terms of Requirement Levels
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. SMIng Data Modeling
SMIng is a language designed to specify management information in a
structured way readable to computer programs, e.g., MIB compilers, as
well as to human readers.
Management information is modeled in classes. Classes can be defined
from scratch or by derivation from a parent class. Derivation from
multiple parent classes is not possible. The concept of classes is
described in Section 9.
Each class has a number of attributes. Each attribute represents an
atomic piece of information of a base type, a sub-type of a base
type, or another class. The concept of attributes is described in
Section 9.2.
The base types of SMIng include signed and unsigned integers, octet
strings, enumeration types, bitset types, and pointers. Pointers are
references to class instances, attributes of class instances, or
arbitrary identities. The SMIng type system is described in Section
3.
Related class and type definitions are defined in modules. A module
may refer to definitions from other modules by importing identifiers
from those modules. Each module may serve one or multiple purposes:
o the definition of management classes,
o the definition of events,
o the definition of derived types,
o the definition of arbitrary untyped identities serving as values
of pointers,
o the definition of SMIng extensions allowing the local module or
other modules to specify information beyond the scope of the base
SMIng in a machine readable notation. Some extensions for the
application of SMIng in the SNMP framework are defined in
[RFC3781],
o the definition of information beyond the scope of the base SMIng
statements, based on locally defined or imported SMIng extensions.
Each module is identified by an upper-case identifier. The names of
all standard modules must be unique (but different versions of the
same module should have the same name). Developers of enterprise
modules are encouraged to choose names for their modules that will
have a low probability of colliding with standard or other enterprise
modules, e.g., by using the enterprise or organization name as a
prefix.
2.1. Identifiers
Identifiers are used to identify different kinds of SMIng items by
name. Each identifier is valid in a namespace which depends on the
type of the SMIng item being defined:
o The global namespace contains all module identifiers.
o Each module defines a new namespace. A module’s namespace may
contain definitions of extension identifiers, derived type
identifiers, identity identifiers, and class identifiers.
Furthermore, a module may import identifiers of these kinds from
other modules. All these identifiers are also visible within all
inner namespaces of the module.
o Each class within a module defines a new namespace. A class’
namespace may contain definitions of attribute identifiers and
event identifiers.
o Each enumeration type and bitset type defines a new namespace of
its named numbers. These named numbers are visible in each
expression of a corresponding value, e.g., default values and
sub-typing restrictions.
o Extensions may define additional namespaces and have additional
rules of other namespaces’ visibility.
Within every namespace each identifier MUST be unique.
Each identifier starts with an upper-case or lower-case character,
dependent on the kind of SMIng item, followed by zero or more
letters, digits, and hyphens.
All identifiers defined in a namespace MUST be unique and SHOULD NOT
only differ in case. Identifiers MUST NOT exceed 64 characters in
length. Furthermore, the set of all identifiers defined in all
modules of a single standardization body or organization SHOULD be
unique and mnemonic. This promotes a common language for humans to
use when discussing a module.
To reference an item that is defined in the local module, its
definition MUST sequentially precede the reference. Thus, there MUST
NOT be any forward references.
To reference an item that is defined in an external module it MUST be
imported (Section 5.1). Identifiers that are neither defined nor
imported MUST NOT be visible in the local module.
When identifiers from external modules are referenced, there is the
possibility of name collisions. As such, if different items with the
same identifier are imported or if imported identifiers collide with
identifiers of locally defined items, then this ambiguity is resolved
by prefixing those identifiers with the names of their modules and
the namespace operator `::’, i.e., `Module::item’. Of course, this
notation can be used to refer to identifiers even when there is no
name collision.
Note that SMIng core language keywords MUST NOT be imported. See the
`...Keyword’ rules of the SMIng ABNF grammar in Appendix B for a list
of those keywords.
3. Base Types and Derived Types
SMIng has a set of base types, similar to those of many programming
languages, but with some differences due to special requirements from
the management information model.
Additional types may be defined, derived from those base types or
from other derived types. Derived types may use subtyping to
formally restrict the set of possible values. An initial set of
commonly used derived types is defined in the SMIng standard module
NMRG-SMING [RFC3781].
The different base types and their derived types allow different
kinds of subtyping, namely size restrictions of octet strings
(Section 3.1), range restrictions of numeric types (Section 3.4
through Section 3.10), restricted pointer types (Section 3.2), and
restrictions on the sets of named numbers for enumeration types
(Section 3.11) and bit sets (Section 3.12).
3.1. OctetString
The OctetString base type represents arbitrary binary or textual
data. Although SMIng has a theoretical size limitation of 2^16-1
(65535) octets for this base type, module designers should realize
that there may be implementation and interoperability limitations for
sizes in excess of 255 octets.
Values of octet strings may be denoted as textual data enclosed in
double quotes or as arbitrary binary data denoted as a `0x’-prefixed
hexadecimal value of an even number of at least two hexadecimal
digits, where each pair of hexadecimal digits represents a single
octet. Letters in hexadecimal values MAY be upper-case, but lower-
case characters are RECOMMENDED. Textual data may contain any number
(possibly zero) of any 7-bit displayable ASCII characters, including
tab characters, spaces, and line terminator characters (nl or cr &
nl). Some characters require a special encoding (see Section 4.2).
Textual data may span multiple lines, where each subsequent line
prefix containing only white space up to the column where the first
line’s data starts SHOULD be skipped by parsers for a better text
formatting.
When defining a type derived (directly or indirectly) from the
OctetString base type, the size in octets may be restricted by
appending a list of size ranges or explicit size values, separated by
pipe `|’ characters, with the whole list enclosed in parenthesis. A
size range consists of a lower bound, two consecutive dots `..’, and
an upper bound. Each value can be given in decimal or `0x’-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. Size restricting values MUST NOT be
negative. If multiple values or ranges are given, they all MUST be
disjoint and MUST be in ascending order. If a size restriction is
applied to an already size restricted octet string, the new
restriction MUST be equal or more limiting, that is, raising the
lower bounds, reducing the upper bounds, removing explicit size
values or ranges, or splitting ranges into multiple ranges with
intermediate gaps.
Value Examples:
"This is a multiline
textual data example." // legal
"This is "illegally" quoted." // illegal quotes
"This is \"legally\" quoted." // legally encoded quotes
"But this is ’ok’, as well." // legal apostrophe quoting
"" // legal zero length
0x123 // illegal odd hex length
0x534d496e670a // legal octet string
Restriction Examples:
OctetString (0 | 4..255) // legal size spec
OctetString (4) // legal exact size
OctetString (-1 | 1) // illegal negative size
OctetString (5 | 0) // illegal ordering
OctetString (1 | 1..10) // illegal overlapping
3.2. Pointer
The Pointer base type represents values that reference class
instances, attributes of class instances, or arbitrary identities.
The only values of the Pointer type that can be present in a module
can refer to identities. They are denoted as identifiers of the
concerned identities.
When defining a type derived (directly or indirectly) from the
Pointer base type, the values may be restricted to a specific class,
attribute or identity, and all (directly or indirectly) derived items
thereof by appending the identifier of the appropriate construct