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 elementa 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 RFC1155s 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 |