| Previous | Table of Contents | Next |
When these tree structures are combined, the result becomes:
sysDescr OBJECT IDENTIFIER ::= { 1.3.6.1.2.1.1.1 }
To the OID we need to add one last element—a suffix that identifies whether a particular variable occurs just once (a scalar) or whether the variable occurs multiple times (as in columnar entries).
Since sysDescr is a scalar, not columnar, object, there is only one instance of it. (In other words, you can have only one description of the system being managed.) Therefore, a .0 is added to the end of the OID:
{1.3.6.1.2.1.1.1.0.}
If the object was a columnar entry, which could have multiple instances, an index plus a nonzero suffix (.1, .2, an IP address, and so on) would identify the object within the table. Chapter 3 discusses tables in greater detail.
Experimental codes, with prefix {1.3.6.1.3}, have been assigned for many LAN and WAN objects and MIBs, such as ISO CLNS (Connectionless Network Service), the Synchronous Optical Network (SONET) objects, and Asynchronous Transfer Mode (ATM) objects, while the technologies and their MIBs were in the testing phase of development. Thus as the Internet Engineering Task Force (IETF) working groups develop MIBs, they define them under a branch in the experimental tree. Once these MIBs are published and put on the standards track, they move to a branch on the Internet subtree.
Vendor-specific MIBs use private enterprise codes with prefix {1.3.6.1.4.1}. This is an area of rapid growth, because numerous vendors are developing structures to support their Internetworking devices, servers, and so on. Examples include 3Com Corporation (Santa Clara, CA) with code {1.3.6.1.4.1.43}; FTP Software Inc. (North Andover, MA) with code {1.3.6.1.4.1.121}; and US West Advanced Technologies (Denver, CO) with code {1.3.6.1.4.1.312}. Appendix F includes a complete listing of the currently assigned private enterprise codes. Readers with Internet access may obtain this information from:
ftp://venera.isi.edu/mib/snmp-vendor-contacts
Perhaps the best way to summarize this chapter is to include a module entitled RFC1155-SMI from RFC 1155, shown in Definition 2-1. This module defines all of the constructs discussed in this chapter and puts them in a form that will be useful in Chapters 3, 4, and 5. Note that a revision in RFC 1212 [2-9] makes the OBJECT-TYPE macro originally given in RFC 1155 obsolete. In the interest of timeliness, the SMI definition includes the new OBJECT-TYPE macro. Comment lines enclosed within angle brackets (<…>) indicate the beginning and end of the revised section from RFC 1212.
Definition 2-1. Concise SMI Definition
RFC1155-SMI DEFINITIONS ::= BEGIN
EXPORTS — EVERYTHING
internet, directory, mgmt,
experimental, private, enterprises,
OBJECT-TYPE, ObjectName, ObjectSyntax,SimpleSyntax,
ApplicationSyntax, NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks, Opaque;
— the path to the root (from RFC 1155)
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
< definition of object types (taken from RFC 1212) >
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
— must conform to
— RFC1155’s ObjectSyntax
“SYNTAX” type(ObjectSyntax)
“ACCESS” Access
“STATUS” Status
DescrPart
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE ObjectName)
Access ::= “read-only”
| “read-write”
| “write-only”
| “not-accessible”
Status ::= “mandatory”
| “optional”
| “obsolete”
| “deprecated”
DescrPart ::=
“DESCRIPTION” value (description DisplayString)
| empty
ReferPart ::=
“REFERENCE” value (reference DisplayString)
| empty
IndexPart ::=
“INDEX” “{“ IndexTypes “}”
| empty
IndexTypes ::=
IndexType | IndexTypes “,” IndexType
IndexType ::=
— if indexobject, use the SYNTAX
— value of the correspondent
— OBJECT-TYPE invocation
value (indexobject ObjectName)
— otherwise use named SMI type
— must conform to IndexSyntax below
| type (indextype)
DefValPart ::=
“DEFVAL” “{“ value (defvalue ObjectSyntax) “}”
| empty
END
IndexSyntax ::=
CHOICE {
number
INTEGER (0..MAX),
string
OCTET STRING,
object
OBJECT IDENTIFIER,
address
NetworkAddress,
ipAddress
IpAddress
}
< names of objects in the MIB (taken from RFC 1155) >
ObjectName ::= OBJECT IDENTIFIER
— syntax of objects in the MIB
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
— note that simple SEQUENCEs are not directly
— mentioned here to keep things simple (i.e.,
— prevent mis-use). However, application-wide
— types which are IMPLICITly encoded simple
— SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}
ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary
Opaque
— other application-wide types, as they are
— defined, will be added here
}
— application-wide types
NetworkAddress ::=
CHOICE {
internet
IpAddress
}
IpAddress ::=
[APPLICATION 0] — in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
Opaque ::=
[APPLICATION 4] — arbitrary ASN.1 value,
IMPLICIT OCTET STRING — “double-wrapped”
END
This concludes the discussion of the SMI for SNMP version 1. Chapter 3 will study Management Information Bases (MIBs).
| Previous | Table of Contents | Next |