D. T. Perkins Internet Draft Riverstone Networks and Document: draft-perkins-smi-addition-00.txt SNMPinfo Expires: January 2002 July 2001 SMI Data Type Additions To Structure of Management Information Version 2 (SMIv2) And Structure of Management Information Version 1 (SMIv1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines new data types as additions to both version 1[1] and version 2[2] of SNMP's structure of management information(SMI). This document also defines the transport mapping so these new data types can be used in all versions the Simple Management Protocol (SNMP) without modification. That is, using the new data types does not break on-the-wire compatibility with existing SNMPv1[3], SNMPv2c, or SNMPv3 implementations. Table of Contents 1. Introduction .................................................2 2. New Data Types ...............................................3 3. Update for SMIv1 and SNMPv1 ..................................4 3.1 SMIv1 Types Update ...........................................4 3.2 Transport Mappings for SNMPv1 ................................7 4. Update for SMIv2, SNMPv2, and SNMPv3 .........................8 4.1 SMIv2 Types Update ...........................................8 4.2 Transport Mappings for SNMPv2c and SNMPv3 ...................11 4.3 Updates of the MIB module Language defined by SMIv2 .........12 4.4 Updates to Macros ...........................................13 David T. Perkins [Page 1]
SMI Data Type Additions July 2001 5. Discussion of Design Decisions ..............................13 6. Author's Address ............................................15 7. References ..................................................15 8. Full Copyright ..............................................16 1. Introduction SMIv1 specifies the following data types for objects to be used in the SNMPv1 protocol: * INTEGER - a 32-bit signed number * OBJECT IDENTIFIER - a sequence up to 128 in length of 32-bit unsigned numbers * OCTET STRING - a sequence of octets * NetworkAddress - a choice with only the choice of IpAddress * IpAddress - an IPv4 address * Counter - a 32-bit unsigned integer * Gauge - a 32-bit unsigned integer * TimeTicks - a 32-bit unsigned integer * Opaque - an OCTET STRING whose value must be a BER encoded ASN.1 value SMIv2 specifies the following data types for objects to be used in the SNMPv1, SNMPv2c, and SNMPv3 protocols: * INTEGER - a 32-bit signed numbers * OBJECT IDENTIFIER - a sequence up to 128 in length of 32-bit unsigned numbers * OCTET STRING - a sequence of octets * Integer32 - a 32-bit signed number (the same as INTEGER) * IpAddress - an IPv4 address * Counter32 - a 32-bit unsigned integer * TimeTicks - a 32-bit unsigned integer * Opaque - an OCTET STRING whose value must be a BER encoded ASN.1 value * Counter64 - a 64-bit unsigned integer (not usable in SNMPv1) * Unsigned32 - a 32-bit unsigned integer * BITS - a pseudo-type of a bit string encoded as an OCTET STRING In over ten years of usage, there have been few problems with this limited set of data types. However, as networking technology as advanced, the need for 64-bit signed and unsigned integers has become painfully obvious. Also, to support logs and operations of mid-level managers, there has been shown a need for a discriminated union type, and to a lesser degree for support for floating point. Adding support for new types is technically trivial. However, operationally adding new types can affect tools that process MIB modules (MIB parsers), and the implementation of SNMP protocol stacks. Since the need for un-interrupted operation is much greater than the need for the new data types, no action has been taken to date in the standards arena to address this problem. However, proto-typing work has taken place with the NET-SNMP code base (see http://www.netsnmp.org/) that has demonstrated that the approach contained in this document does allow new data types to be Expires - January 2002 [Page 2]
SMI Data Type Additions July 2001 introduced without disruption of current interoperation of old and new SNMP agents and managers. In the past, there have been proposals to add new data types, but to have them only available in newer versions of SNMP. SMIv2 added one new data type to those found in SMIv1 and no transport mapping was defined so that this data type could be used in SNMPv1. This has resulted in several different workarounds in MIB modules so that SNMPv1 agents and managers could access 64-bit counter attributes on managed systems. Also, this resulted in the non-interoperation of 64-bit counters between SNMPv1 and SNMPv3 proxies. Due to this experience, the approach taken by this document is to describe a non-disruptive transport mapping so that 64-bit counters can be used in SNMPv1, and so all new data types can be used in any version of SNMP. The SNMP message formats including the protocol operations have been specified using the 1987/8 version of ASN.1[4], and have used the basic encoding rules (BER)[5] to encode them. These definitions have been mostly correct ASN.1. The format of MIB modules and the data types for SNMP have been specified in the SMI using ASN.1. However, the ASN.1 is not correct. There has been "interpretations" in the SMI that describe how to use the specifications in ASN.1. This document continues the tradition of specifying not quite correct ASN.1 for the additions and supplying interpretations for readers. 2. New Data Types The new data types are Integer64, Unsigned64, Float, Double, and DiscUnion (discriminated union). The data type for a union without a discriminator is not included, nor a sequence or an array (sequence of). The types are: * Integer64 - a signed 64-bit integer. It can have a range specified, and, thus, current MIB parsers must be extended to parse integers from -2^63 to 2^63 -1. * Unsigned64 - an unsigned 64-bit integer. It can have a range specified, and, thus, current MIB parsers must be extended to parse integers that can be as large as 2^64 -1. * Float - 32-bit floating point number in IEEE "single precision" format[6]. No range may be specified on this data type. This limits the impact caused by this addition to MIB parsers and other tools. Note that all of the special values such as "not-a-number", "plus- infinity", and "minus-infinity" that are part of the IEEE definition are supported by this type. Note that the ASN.1 type "real" is not used. * Double - 64-bit floating point number in IEEE "double precision" format. No range may be specified on this data type. This limits the impact caused by this addition to MIB parsers and other tools. Note that all of the special values such as "not-a-number", "plus- Expires - January 2002 [Page 3]
SMI Data Type Additions July 2001 infinity", and "minus-infinity" that are part of the IEEE definition are supported by this type. Note that the ASN.1 type "real" is not used. * DiscUnion - this is a sequence of an integer and a choice of all other unique data types other than a DiscUnion. Adding this type requires that the format of the SYNTAX clause be extended to support specifying a list of discriminator and data type pairs. Specifying the format is not easy in ASN.1, and requires modification to all macros that include the SYNTAX (or WRITE-SYNTAX) clauses. Plus it requires a little interpretation of ASN.1, just like was done for the BITS pseudo-type. 3. Update for SMIv1 and SNMPv1 The text below is the update for section 6 of RFC 1155. This update and the "transport mappings" allow unmodified operation of SNMPv1. However, no update is provided to the portion of the SMI found in RFC 1213 that describes how to specify these new types in SMIv1 format MIB modules. This is not done because SMIv1 format MIB modules have been obsoleted by the SMIv2 format for MIB modules. 3.1 SMIv1 Types Update ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that SEQUENCEs for conceptual tables and -- rows are not mentioned here... application-wide ApplicationSyntax } SimpleSyntax ::= CHOICE { number INTEGER, string OCTET STRING, object OBJECT IDENTIFIER, empty NULL -- note: this is used only as a placeholder in -- PDUs and not as a data type for objects } Expires - January 2002 [Page 4]
SMI Data Type Additions July 2001 ApplicationSyntax ::= CHOICE { address NetworkAddress, counter Counter, gauge Gauge, ticks TimeTicks, arbitrary Opaque, counter64 -- addition Counter64, -- addition integer64 -- addition Integer64, -- addition unsigned64 -- addition Unsigned64, -- addition float -- addition Float, -- addition double -- addition Double, -- addition discUnion -- addition DiscUnion -- addition -- other application-wide types, as they are -- defined, will be added here } -- application-wide types NetworkAddress ::= -- this is indistinguishable from CHOICE { -- IpAddress except when used for the Internet -- data type of an index object IpAddress } IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) Counter ::= Expires - January 2002 [Page 5]
SMI Data Type Additions July 2001 [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] -- value is arbitrary ASN.1 value, IMPLICIT OCTET STRING -- encoded in BER ("double-wrapped") -- Additions -- note: tag [APPLICATION 5] was used in RFC 1442 (don't reuse) Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) -- note: tag [APPLICATION 7] was used in RFC 1442 (don't reuse) Float ::= [APPLICATION 8] IMPLICIT OCTET STRING(SIZE(4)) -- values are in IEEE format Double ::= [APPLICATION 9] IMPLICIT OCTET STRING(SIZE(8)) -- values are in IEEE format Integer64 ::= [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) Unsigned64 ::= [APPLICATION 11] IMPLICIT INTEGER (0..18446744073709551615) DiscUnion ::= -- only unique base types are included in the choice [APPLICATION 12] IMPLICIT SEQUENCE { discriminator INTEGER(1..2147483647), union-value CHOICE { int32Val INTEGER (-2147483648.. 2147483647), stringVal OCTET STRING (SIZE(0..65535)), oidVal OBJECT IDENTIFIER, uint32Val [APPLICATION 2] IMPLICIT INTEGER (0..4294967295), floatVal [APPLICATION 8] IMPLICIT OCTET STRING (SIZE(4)), doubleVal [ APPLICATION 9] IMPLICIT Expires - January 2002 [Page 6]
SMI Data Type Additions July 2001 OCTET STRING (SIZE(8)), int64Val [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808.. 9223372036854775807), uint64Val [APPLICATION 11] IMPLICIT INTEGER (0.. 18446744073709551615) } } 3.2 Transport Mappings for SNMPv1 How SNMPv1 messages and the elements of these messages including the values of objects are encoded is specified in RFC 1157. Section 3.2.2 specifies that only a subset of BER be used, specifically: * all encodings must use the definite-length form * whenever permissible, non-constructor encodings are used rather than constructor encodings Section 4 gives further guidance on how messages are encoded. The implicit instructions are that values of objects are encoded using BER with the restrictions specified in section 3.2.2. To support un-interrupted interoperation of SNMP agents and managers that have implementations conformant to RFC 1155 and RFC 1157 with SNMP agents and managers using the new data types, the values for the new data types cannot be encoded directly using BER. If values for the new data types are encoded using BER, then a conforming agent or manager would reject messages with values of the new data types due to a perceived encoding error of the sender. The only possible approach to support un-interrupted interoperation is to use an encoding for values of the new data type that are supportable by conforming agents and managers. The best such approach is to encode values of the new types using BER, and then to encode that sequence of octets as an Opaque type. This results in the value being so called "double wrapped". On receiving such values, an agent or manager that has not been updated will only unwrap the value once, and an updated agent or manager will unwrap the value twice. With this addition in place, an agent that hasn't been updated may receive SET requests with a value of a new data type from an updated manager. Since there are no existing objects that such an agent supports, the agent will return the error code of "noSuchName", which is the required result. Also, a manager that hasn't been updated may receive GET-RESPONSE and TRAP messages from an agent that has been updated containing encoded values for the new data types. These values will appear to the manager as data of type Opaque. This will not adversely affect a conforming manager. On the other hand, for updated agents and managers, values with a type of Opaque must be examined to determine if their content is the encoding of a new value using BER. If so, the updated agent or manager must decode the value a second time, thus, double unwrapping the value. On success, the data type and value returned by the Expires - January 2002 [Page 7]
SMI Data Type Additions July 2001 decoding is that recovered. If the second decoding cannot be successfully done, then the value returned would be of data type Opaque. When updated agents and managers are to encode a message before sending it, for the new data types, they must encode the value using BER. The encoded result (which is a string of octets) must then be encoded as the value of data type Opaque. This results in a double wrapping of the original value. 4. Update for SMIv2, SNMPv2, and SNMPv3 The text below is the update for section 2 of RFC 2578. This update and an update to "transport mappings" found in RFC 1906 allow unmodified operation of SNMPv2c and SNMPv3. Also provided are updates to the OBJECT-TYPE macro found in RFC 2578, to the TEXTUAL-CONVENTION macro found in RFC 2579, and from RFC 2580 the MODULE-COMPLIANCE macro and AGENT-CAPABILITIES macro. These updates are needed to enhance the SYNTAX (and WRITE-SYNTAX) clauses to specify a discriminated union. 4.1 SMIv2 Types Update -- The data types for objects, which is specified -- in the SYNTAX clause of their definition, -- the SYNTAX clause of textual conventions, and -- the SYNTAX and WRITE-SYNTAX clause of MODULE-COMPLIANCE -- and AGENT-CAPABILITIES constructs. -- The "base types" defined here are: -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 13 application-defined types: Integer32, IpAddress, Counter32, -- Gauge32, Unsigned32, TimeTicks, Opaque, Counter64, -- Integer64, Unsigned64, Float, Double, and DiscUnion. ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that SEQUENCEs for conceptual tables and -- rows are not mentioned here... application-wide ApplicationSyntax } -- built-in ASN.1 types SimpleSyntax ::= CHOICE { -- INTEGERs with a more restrictive range Expires - January 2002 [Page 8]
SMI Data Type Additions July 2001 -- may also be used -- includes Integer32 integer-value INTEGER (-2147483648..2147483647), -- OCTET STRINGs with a more restrictive size -- may also be used string-value OCTET STRING (SIZE (0..65535)), -- value limited to 128 sub-identifiers, with -- the maximum value for any as 4294967295. -- note that there are additional restrictions -- imposed by ASN.1 on the values of the first -- two sub-identifiers. objectID-value OBJECT IDENTIFIER } -- indistinguishable from INTEGER, but never needs more than -- 32-bits for a two's complement representation Integer32 ::= INTEGER (-2147483648..2147483647) -- application-wide types ApplicationSyntax ::= CHOICE { ipAddress-value IpAddress, counter-value Counter32, timeticks-value TimeTicks, arbitrary-value Opaque, -- ASN.1 value encoded using BER big-counter-value Counter64, unsigned-integer-value Unsigned32 -- includes Gauge32 } -- in network-byte order -- (this is a tagged type for historical reasons) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) -- this wraps Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) -- this doesn't wrap Gauge32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) -- an unsigned 32-bit quantity -- indistinguishable from Gauge32 Unsigned32 ::= [APPLICATION 2] Expires - January 2002 [Page 9]
SMI Data Type Additions July 2001 IMPLICIT INTEGER (0..4294967295) -- hundredths of seconds since an epoch TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) -- for backward-compatibility only -- the value is the encoded value of an ASN.1 value -- using BER. The original value is said to be -- "double wrapped". Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING -- note: tag [APPLICATION 5] was used in RFC 1442 (don't reuse) -- for counters that wrap in less than one hour with only 32 bits Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) -- note: tag [APPLICATION 7] was used in RFC 1442 (don't reuse) -- Additions Float ::= [APPLICATION 8] IMPLICIT OCTET STRING(SIZE(4)) -- values are in IEEE format Double ::= [APPLICATION 9] IMPLICIT OCTET STRING(SIZE(8)) -- values are in IEEE format Integer64 ::= [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) Unsigned64 ::= [APPLICATION 11] IMPLICIT INTEGER (0..18446744073709551615) DiscUnion ::= [APPLICATION 12] IMPLICIT SEQUENCE { discriminator INTEGER(1..2147483647), union-value CHOICE { int32Val INTEGER (-2147483648.. 2147483647), stringVal OCTET STRING (SIZE(0..65535)), oidVal OBJECT IDENTIFIER, uint32Val [APPLICATION 2] IMPLICIT INTEGER (0..4294967295), floatVal [APPLICATION 8] IMPLICIT OCTET STRING (SIZE(4)), Expires - January 2002 [Page 10]
SMI Data Type Additions July 2001 doubleVal [ APPLICATION 9] IMPLICIT OCTET STRING (SIZE(8)), int64Val [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808.. 9223372036854775807), uint64Val [APPLICATION 11] IMPLICIT INTEGER (0.. 18446744073709551615) } } 4.2 Transport Mappings for SNMPv2c and SNMPv3 How SNMPv2c and SNMPv3 messages and the elements of these messages including the values of objects are encoded is specified in RFC 1906[7]. Section 8 specifies how values are encoded using BER. To support un-interrupted interoperation of SNMP agents and managers that have implementations conformant to protocol operations specified in RFC 1905, and agents and managers using the new data types, the values for the new data types cannot be encoded directly using BER. If values for the new data types are encoded using BER, then a conforming agent or manager would reject messages with values of the new data types due to a perceived encoding error of the sender. The only possible approach to support un-interrupted interoperation is to use an encoding for values of the new data type that are supportable by conforming agents and managers. The best such approach is to encode values of the new types using BER, and then to encode that sequence of octets as an Opaque type. This results in the value being so called "double wrapped". On receiving such values, an agent or manager that has not been updated will only unwrap the value once, and updated agents and managers will upwrap the value once. With this addition in place, an agent that hasn't been updated may receive SET requests with such a value from an updated manager. Since there are no existing objects that such an agent supports, the agent will return the error code of "noAccess ", which is the required result. Also, a manager that hasn't been updated may receive RESPONSE, v2TRAP, and INFORM messages from an agent that has been updated containing encoded values for the new data types. These values will appear to the manager as data of type Opaque. This will not adversely affect a conforming manager. On the other hand, for updated agents and managers, values with a type of Opaque must be examined to determine if their content is the encoding of a new value using BER. If so, the updated agent or manager must decode the value a second time, thus, double unwrapping the value. On success, the data type and value returned by the decoding is that recovered. If the second decoding cannot be successfully done, then the value returned would be of data type Opaque. Expires - January 2002 [Page 11]
SMI Data Type Additions July 2001 When updated agents and managers are to encode a message before sending it, for the new data types, they must encode the value using BER. The encoded result (which is a string of octets) must then be encoded as the value of data type Opaque. This results in double wrapping the original value. 4.3 Updates of the MIB module Language defined by SMIv2 For any new type, typically a size or range may be specified to constrain its values. Also, a format must be defined for specifying values in the DEFVAL clause. Finally, rules must be given as to whether the data type can be used as an index, and when so, how the value is encoded in one or more sub-identifiers. For data types Integer64 and Unsigned64, the rules from ASN.1 can be used. For the other types, some interpretation of ASN.1 must be followed. The following text is an update to section 7.1 of RFC 2578 that describes the data types. * Integer64 and Unsigned64. The Integer64 data type represents integer-valued information between -2^63 and 2^63-1 inclusive. The Unsigned64 data type represents integer-valued information between 0 and 2^64-1 inclusive. These data types can have ranges specified. However ranges that constrain the values to the range of data types Integer32 and Unsigned32 are confusing to readers of MIB modules. MIB parsers should warn when this usage is specified, but allow it. A default value may be specified that is within the range. Objects of these data types cannot be used as index objects. Examples of usage are: SYNTAX Integer64 SYNTAX Integer64(-1..9223372036854775807) SYNTAX Unsigned(0..10000000000) DEFVAL { 5 } * Float and Double. The Float and Double data types represent floating-point values with the ranges and semantics as defined by IEEE for "single" and "double" floating point numbers. These data types may not have ranges specified. This is to reduce implementation costs. After some experience has been gained with these types, this document may be updated to allow ranges to be specified. To reduce implementation costs, no default value may be specified. After some experience has been gained with these types, this document may be updated to allow a default value to be specified. Note that objects with these data types may have any of the values specified in the IEEE specification, such as minus and plus infinity. Objects of these data types cannot be used as index objects. Examples of usage are: SYNTAX Float SYNTAX Double * DiscUnion The DiscUnion data type represents a value that can be specified in one of several enumerated forms. There is not an easy way to specify Expires - January 2002 [Page 12]
SMI Data Type Additions July 2001 how to write instances of this data type in ASN.1. The update solves this by extending the OBJECT-TYPE, TEXTUAL-CONVENTION, MODULE-COMPLIANCE, and AGENT-CAPABILTIES macros as was done to add the BITS pseudo-type. This data type may not have a default value specified. This is to reduce implementation costs. After some experience has been gained with this type, this document may be updated to allow a default value to be specified. An object of this data type cannot be used as index object. Examples of usage are: SYNTAX DiscUnion { -- a length of time up to 1 day long timeInSecs(1) Unsigned32(0..86400), timeInMins(2) Unsigned32(0..1440), timeInHours(3) Unsigned32(0..24) } SYNTAX DiscUnion { -- result value for a Calculator intVal(1) Integer64, uintVal(2) Unsigned64, floatVal(3) Float, doubleVal(4) Double } 4.4 Updates to Macros The updates to the macros will be provided here. 5. Discussion of Design Decisions Uninterrupted interoperation with the installed base of SNMP agents and managers is the primary rule which drove all decisions in this document. The small addition of the type Counter64 to SMIv2 and the interoperation problems were the shinning example. The second rule followed was to minimize the impact to updated agents, managers, and MIB tools. Some may argue against the encodings chosen for the new types. These arguments have typically been based on "purity", "efficiency", or "safety". In regards to purity, choosing a "pure approach" would require a new version of the SNMP PDUs. This effective means non-interoperable revisions of each version of SNMP. This is a nonstarter. In regards to efficiency, the approach of wrapping new data types as a value of data type Opaque does increase the size of the encoding by at least two octets. However, this is a small percentage of the total space required to transmit a value. There has been recent work to add new operations to SNMP to more efficiently transfer values. These new operations can encode the new data types directly, and not be burdened by the extra octets due to the double wrapping. In regards to safety, the new values have been demonstrated to be safe with the prototyping done in the NetSNMP code. Also, a through review of the SNMP specifications was done to make sure the approach did not break any of the rules. However, there may be some nonconforming implementations of SNMPv1, SNMPv2c, and SNMPv3 which may "crash and burn". So far, none have been reported. Expires - January 2002 [Page 13]
SMI Data Type Additions July 2001 Note that a union without a discriminator was not added. For all of the use cases that were considered, such a union provided no or little advantage over a discriminated union. Thus, to minimize the amount of work, a union without a discriminator is not included in this document. If experience shows differently, then one can be added. One use case that influenced the specification for the range of the discriminator was using a discriminated union in a log of varBinds (such as found in notifications). The troubling question was "how could a discriminated union be used to hold the value of another discriminated union?" This was difficult because a discriminated union does not allow a discriminated union as a type. The solution in this case was to realize that two objects were needed to implement the log. The first is a discriminated union with discriminator values identifying each base type, and an Integer32 object whose values when negative mean that the original value was a discriminator and when not negative mean the original value was not a discriminated union. The value for the discriminator are determined by taking the absolute values of the negative values. The ASN.1 tag of the data type is the positive value. An example is shown below: logXval OBJECT-TYPE SYNTAX DiscUnion { int32Val(1) Integer32, strVal(2) OCTET STRING(SIZE (0..65535)), oidVal(3) OBJECT IDENTIFIER, uint32Val(4) Unsigned32, floatVal(5) Float, doubleVal(6) Double, int64Val(7) Integer64, uint64(8) Unsigned64 } MAX-ACCESS read-only STATUS current DESCRIPTION "The value for a variable as a base type. 32-bit Counters, Gauges, and TimeTicks are stored as Unsigned32 values. 64-bit counters are stored as Unsigned32 values. IpAddress and Opaques are stored as OCTET STRINGs. DiscUnions have their value stored in this object and the negative value of the discriminator stored in object logXtype. For values other than DiscUnion, the value of the ASN.1 tag for the value is stored as the value for object logXtype." ::= { logXEntry y } logXtype OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifier the original type of the value Expires - January 2002 [Page 14]
SMI Data Type Additions July 2001 of object logXval. If the value of this object is negative, then the original type of the value for object logXval was DiscUnion, and the value is the negative of the discriminator value. If the value of this object is positive, then it is the ASN.1 tag value of the original object. The following are values for the ASN.1 tag for the data types: '02'x - INTEGER '04'x - OCTET STRING '06'x - OBJECT IDENTIFIER '40'x - IpAddress '41'x - Counter/Counter32 '42'x - Gauge/Gauge32/Unsigned32 '43'x - TimeTicks '44'x - Opaque '46'x - Counter64 '48'x - Float '49'x - Double '4a'x - Integer64 '4b'x - Unsigned64" ::= { logXEntry z } 6. Author's Address David T. Perkins Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054 Phone: 1 (408) 878-6682 Email: dperkins@riverstonenet.com and SNMPinfo 3763 Benton Street Santa Clara, CA 95051 Phone: 1 (408) 394-8702 Email: dperkins@snmpinfo.com 7. References [1] Rose, M. T., McCloghrie,K., "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin., "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Expires - January 2002 [Page 15]
SMI Data Type Additions July 2001 Standardization. International Standard 8825, (December, 1987). (Which is also ITU-T X.208:1988) [5] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). (which is also ITU-T X.209:1988) [6] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 8. Full Copyright Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires - January 2002 [Page 16]