This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.
This memo does not specify a standard for the Internet community. However, after experimentation, if sufficient consensus is reached in the Internet community, then a subsequent revision of this document may be placed in the Internet-standard MIB.
As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework.
This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion.
As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to new operational needs in the Internet community by producing MIB-II.
In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet- standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and, the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects.
Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined in the Internet-standard MIB was derived by taking only those elements which are considered essential. However, the SMI defined three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non-standard objects through the experimental subtree; and three, the addition of private objects through the
Satz [Page 2]
RFC 1162 CLNS MIB June 1990
enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential.
Since the publication of the Internet-standard MIB, experience has lead to a new document, termed MIB-II [6], being defined.
This memo defines extensions to the MIB using the second method. It contains definitions of managed objects used for experimentation. After experimentation, if sufficient consensus is reached in the Internet community, then a subsequent revision of this memo may be placed in the Internet-standard MIB.
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network.
This SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP.
The next section contains the specification of all object types contained in the MIB. Following the conventions of the companion memo, the object types are defined using the following fields:
Satz [Page 3]
RFC 1162 CLNS MIB June 1990
OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER.
Syntax: The abstract syntax for the object type, presented using ASN.1. This must resolve to an instance of the ASN.1 type ObjectSyntax defined in the SMI.
Definition: A textual description of the semantics of the object type. Implementations should ensure that their interpretation of the object type fulfills this definition since this MIB is intended for use in multi- vendor environments. As such it is vital that object types have consistent meaning across all machines.
Access: A keyword, one of read-only, read-write, write-only, or not-accessible. Note that this designation specifies the minimum level of support required. As a local matter, implementations may support other access types (e.g., an implementation may elect to permitting writing a variable marked herein as read-only). Further, protocol-specific "views" (e.g., those implied by an SNMP community) may make further restrictions on access to a variable.
Status: A keyword, one of mandatory, optional, obsolete, or deprecated. Use of deprecated implies mandatory status.
These objects can be used when the ISO Connectionless-mode Network Protocol [9] and End System to Intermediate System [10] protocols are present. No assumptions are made as to what underlying protocol is being used to carry the SNMP.
This memo uses the string encoding of [11] to textually describe OSI addresses.
The ASN.1 type ClnpAddress is used to denote an OSI address. This consists of a string of octets. The first octet of the string contains a binary value in the range of 0..20, and indicates the the length in octets of the NSAP. Following the first octet, is the NSAP, expressed in concrete binary notation, starting with the most significant octet. A zero- length NSAP is used as a "special" address meaning "the default NSAP" (analogous to the IP address of 0.0.0.0). Such an NSAP is encoded as a single octet, containing the value 0.
Implementation is experimental and is recommended for all systems that support a CLNP.
OBJECT: ------- clnpForwarding { clnp 1 }
Syntax: INTEGER { is(1), -- entity is an intermediate system es(2), -- entity is an end system and does not forward PDUs }
Definition: The indication of whether this entity is active as an
Satz [Page 5]
RFC 1162 CLNS MIB June 1990
intermediate or end system. Only intermediate systems will forward PDUs onward that are not addressed to them.
Access: read-write.
Status: mandatory.
OBJECT: ------- clnpDefaultLifeTime { clnp 2 }
Syntax: INTEGER
Definition: The default value inserted into the Lifetime field of the CLNP PDU header of PDUs sourced by this entity.
Access: read-write.
Status: mandatory.
OBJECT: ------- clnpInReceives { clnp 3 }
Syntax: Counter
Definition: The total number of input PDUs received from all connected network interfaces running CLNP, including errors.
Access: read-only.
Status: mandatory.
Satz [Page 6]
RFC 1162 CLNS MIB June 1990
OBJECT: ------- clnpInHdrErrors { clnp 4 }
Syntax: Counter
Definition: The number of input PDUs discarded due to errors in the CLNP header, including bad checksums, version mismatch, lifetime exceeded, errors discovered in processing options, etc.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpInAddrErrors { clnp 5 }
Syntax: Counter
Definition: The number of input PDUs discarded because the NSAP address in the CLNP header's destination field was not a valid NSAP to be received at this entity. This count includes addresses not understood. For end systems, this is a count of PDUs which arrived with a destination NSAP which was not local.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpForwPDUs { clnp 6 }
Syntax: Counter
Satz [Page 7]
RFC 1162 CLNS MIB June 1990
Definition: The number of input PDUs for which this entity was not the final destination and which an attempt was made to forward them onward.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpInUnknownNLPs { clnp 7 }
Syntax: Counter
Definition: The number of locally-addressed PDUs successfully received but discarded because the network layer protocol was unknown or unsupported (e.g., not CLNP or ES-IS).
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpInUnknownULPs { clnp 8 }
Syntax: Counter
Definition: The number of locally-addressed PDUs successfully received but discarded because the upper layer protocol was unknown or unsupported (e.g., not TP4).
Access: read-only.
Status: mandatory.
Satz [Page 8]
RFC 1162 CLNS MIB June 1990
OBJECT: ------- clnpInDiscards { clnp 9 }
Syntax: Counter
Definition: The number of input CLNP PDUs for which no problems were encountered to prevent their continued processing, but were discarded (e.g., for lack of buffer space). Note that this counter does not include any PDUs discarded while awaiting re-assembly.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpInDelivers { clnp 10 }
Syntax: Counter
Definition: The total number of input PDUs successfully delivered to the CLNS transport user.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpOutRequests { clnp 11 }
Syntax: Counter
Definition: The total number of CLNP PDUs which local CLNS user
Satz [Page 9]
RFC 1162 CLNS MIB June 1990
protocols supplied to CLNP for transmission requests. This counter does not include any PDUs counted in clnpForwPDUs.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpOutDiscards { clnp 12 }
Syntax: Counter
Definition: The number of output CLNP PDUs for which no other problem was encountered to prevent their transmission but were discarded (e.g., for lack of buffer space). Note this counter includes PDUs counted in clnpForwPDUs.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpOutNoRoutes { clnp 13 }
Syntax: Counter
Definition: The number of CLNP PDUs discarded because no route could be found to transmit them to their destination. This counter includes any PDUs counted in clnpForwPDUs.
Access: read-only.
Status: mandatory.
Satz [Page 10]
RFC 1162 CLNS MIB June 1990
OBJECT: ------- clnpReasmTimeout { clnp 14 }
Syntax: INTEGER
Definition: The maximum number of seconds which received segments are held while they are awaiting reassembly at this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpReasmReqds { clnp 15 }
Syntax: Counter
Definition: The number of CLNP segments received which needed to be reassembled at this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpReasmOKs { clnp 16 }
Syntax: Counter
Definition: The number of CLNP PDUs successfully re-assembled at this entity.
Satz [Page 11]
RFC 1162 CLNS MIB June 1990
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpReasmFails { clnp 17 }
Syntax: Counter
Definition: The number of failures detected by the CLNP reassembly algorithm (for any reason: timed out, buffer size, etc).
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpSegOKs { clnp 18 }
Syntax: Counter
Definition: The number of CLNP PDUs that have been successfully segmented at this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpSegFails { clnp 19 }
Satz [Page 12]
RFC 1162 CLNS MIB June 1990
Syntax: Counter
Definition: The number of CLNP PDUs that have been discarded because they needed to be fragmented at this entity but could not.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpSegCreates { clnp 20 }
Syntax: Counter
Definition: The number of CLNP PDU segments that have been generated as a result of segmentation at this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- clnpInOpts { clnp 25 }
Syntax: Counter
Definition: The number of CLNP PDU segments that have been input with options at this entity.
Access: read-only.
Satz [Page 13]
RFC 1162 CLNS MIB June 1990
Status: mandatory.
OBJECT: ------- clnpOutOpts { clnp 26 }
Syntax: Counter
Definition: The number of CLNP PDU segments that have been generated with options by this entity.
Definition: The index value which uniquely identifies the interface
Satz [Page 15]
RFC 1162 CLNS MIB June 1990
to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.
Definition: The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same as identified by the same value of ifIndex.
Definition: The primary routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1.
Definition: An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1.
Definition: An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1.
Definition: An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1.
Syntax: INTEGER { other(1), -- none of the following
invalid(2), -- an invalidated route
Satz [Page 20]
RFC 1162 CLNS MIB June 1990
-- route to directly direct(3), -- connected (sub-)network
-- route to a non-local remote(4) -- host/network/sub-network }
Definition: The type of route.
Setting this object to the value invalid(2) has the effect of invaliding the corresponding entry in the clnpRoutingTable. That is, it effectively dissasociates the destination identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant clnpRouteType object.
Syntax: INTEGER { other(1), -- none of the following
-- non-protocol information -- e.g., manually local(2), -- configured entries
-- set via a network netmgmt(3), -- management protocol
-- similar to ipRouteProto -- but omits several IP-specific -- protocols
is-is(9),
Satz [Page 21]
RFC 1162 CLNS MIB June 1990
ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14) }
Definition: The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols.
Definition: The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of "too old" can be implied except through knowledge of the routing protocol by which the route was learned.
The Address Translation tables contain the CLNP address to physical address equivalences. Some interfaces do not use translation tables for determining address equivalences; if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries.
Satz [Page 22]
RFC 1162 CLNS MIB June 1990
OBJECT: ------- clnpNetToMediaTable { clnp 23 }
Syntax: SEQUENCE OF ClnpNetToMediaEntry
Definition: The CLNP Address Translation table used for mapping from CLNP addresses to physical addresses.
Definition: The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.
Syntax: INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) }
Definition: The type of mapping.
Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the clnpNetToMediaTable. That is, it effectively dissassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant clnpNetToMediaType object.
Definition: The number of seconds since this entry was last updated or otherwise determined to be correct. Note that no semantics of "too old" can be implied except through knowledge of the type of entry.
Definition: The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.
Syntax: INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3),
Satz [Page 28]
RFC 1162 CLNS MIB June 1990
static(4) }
Definition: The type of mapping.
Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the clnpMediaToNetTable. That is, it effectively dissassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant clnpMediaToNetType object.
Definition: The number of seconds since this entry was last updated or otherwise determined to be correct. Note that no semantics of "too old" can be implied except through knowledge of the type of entry.
The ESIS group contains information about the End System Intermediate System protocol used to maintain neighbor reachibility information. Both ESs and ISs are expected to implement this group if they running a CLNP.
OBJECT: ------- esisESHin { es-is 1 }
Syntax: Counter
Definition: The number of ESH PDUs received by this entity.
Satz [Page 47]
RFC 1162 CLNS MIB June 1990
Access: read-only.
Status: mandatory.
OBJECT: ------- esisESHout { es-is 2 }
Syntax: Counter
Definition: The number of ESH PDUs sent by this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- esisISHin { es-is 3 }
Syntax: Counter
Definition: The number of ISH PDUs received by this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- esisISHout { es-is 4 }
Syntax: Counter
Satz [Page 48]
RFC 1162 CLNS MIB June 1990
Definition: The number of ISH PDUs sent by this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- esisRDUin { es-is 5 }
Syntax: Counter
Definition: The number of RDU PDUs received by this entity.
Access: read-only.
Status: mandatory.
OBJECT: ------- esisRDUout { es-is 6 }
Syntax: Counter
Definition: The number of RDU PDUs sent by this entity.
clnpForwarding OBJECT-TYPE SYNTAX INTEGER { is(1), -- entity is an -- intermediate system es(2) -- entity is an end system -- and does not forward pdus } ACCESS read-write STATUS mandatory ::= { clnp 1 }
6. Identification of OBJECT instances for use with the SNMP
The names for all object types in the MIB are defined explicitly either in the Internet-standard MIB or in other documents which conform to the naming conventions of the SMI. The SMI requires that conformant management protocols define mechanisms for identifying individual instances of those object types for a particular network element.
Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." In
Satz [Page 66]
RFC 1162 CLNS MIB June 1990
general, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way specific to the named object type, identifies the desired instance.
This naming strategy admits the fullest exploitation of the semantics of the powerful SNMP get-next operator, because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB.
The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type to which none of the following naming conventions are applicable are named by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition.
For example, suppose one wanted to identify an instance of the variable sysDescr in the Internet-standard MIB. The object class for sysDescr is:
iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1
Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0 identifies the one and only instance of sysDescr.
The name of an CLNP-addressable network element, x, is the OBJECT IDENTIFIER of the form z such that z is the value (in which each octet of the ClnpAddress type is expressed as a sub-identifier of the OBJECT IDENTIFIER) of that instance of the clnpAdEntAddr object type associated with x.
For each object type, t, for which the defined name, n, has a prefix of clnpAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the CLNP- addressable network element about which i represents information.
For example, suppose one wanted to find the maximum reassembly size of an entry in the CLNP interface table associated with an CLNP address of NS+0504030201. Accordingly, clnpAdEntNetMask.5.5.4.3.2.1 would identify the desired instance.
The name of an CLNP route, x, is the OBJECT IDENTIFIER of the form z
Satz [Page 67]
RFC 1162 CLNS MIB June 1990
such that z is the value (in which each octet of the ClnpAddress type is expressed as a sub-identifier of the OBJECT IDENTIFIER) of that instance of the clnpRouteDest object type associated with x.
For each object type, t, for which the defined name, n, has a prefix of clnpRoutingEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the CLNP route about which i represents information.
For example, suppose one wanted to find the next hop of an entry in the CLNP routing table associated with the destination of NS+0504030201. Accordingly, clnpRouteNextHop.5.5.4.3.2.1 would identify the desired instance.
At the option of the agent, multiple routes to the same destination may be visible. To realize this, the agent, while required to return a single entry for an CLNP route, x, of the form n.y, may also return information about other routes to the same destination using the form n.y.v, where v is a implementation-dependent small, non-negative integer.
The name of a cached CLNP address, x, is an OBJECT IDENTIFIER of the form s.z, such that s is the value of that instance of the clnpNetToMediaIfIndex object type associated with the entry and z is the value of the CLNP address of the clnpNetToMediaNetAddress object type associated with x, in which each octet of the ClnpAddress type is expressed as a sub-identifier of the OBJECT IDENTIFIER.
For each object type, t, for which the defined name, n, has a prefix of clnpNetToMediaEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the cached CLNP address about which i represents information.
For example, suppose one wanted to find the media address of an entry in the address translation table associated with a CLNP address of NS+0504030201 and interface 3. Accordingly, clnpNetToMediaPhysAddress.3.5.5.4.3.2.1 would identify the desired instance.
The name of a cached media address, x, is an OBJECT IDENTIFIER of the form s.z, such that s is the value of that instance of the clnpMediaToNetIfIndex object type associated with the entry and z is the value of the media address of the clnpMediaToNetMediaAddress object type associated with x, in which each octet of the media
Satz [Page 68]
RFC 1162 CLNS MIB June 1990
address is expressed as a sub- identifier of the OBJECT IDENTIFIER.
For each object type, t, for which the defined name, n, has a prefix of clnpMediaToNetEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the cached media address about which i represents information.
For example, suppose one wanted to find the CLNP address of an entry in the address translation table associated with a media address of 08:00:20:00:38:ba and interface 3. Accordingly, clnpMediaToNetNetAddress.3.8.0.32.0.56.186 would identify the desired instance.
[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989.
[3] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.
[4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.
[5] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, and the MIT Laboratory for Computer Science, May 1990.
[6] Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1158, Performance Systems International, May 1990.
[7] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.
[8] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization,
Satz [Page 69]
RFC 1162 CLNS MIB June 1990
International Standard 8825, December 1987.
[9] Information processing systems - Data Communications - "Protocol for providing the Connectionless-mode Network Service and Provision of Underlying Service", International Organization for Standardization", International Standard 8473, May 1987.
[10] "End System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473)", International Draft Proposal 9542.
[11] Kille, S., "A String Encoding of Presentation Address", Research Note RN/89/14, Department of Computer Science, University College London, February 1989.