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.
Distribution of this memo is unlimited.
Satz [Page 1]
RFC 1162 CLNS MIB June 19902. Historical Perspective
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 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 intermediate or end system. Only intermediate systems will forward PDUs onward that are not addressed to them.
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.
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).
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 protocols supplied to CLNP for transmission requests. This counter does not include any PDUs counted in clnpForwPDUs.
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.
Definition:
The index value which uniquely identifies the interface 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.
-- 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.
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.
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.
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.
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 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 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 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, 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.
Greg Satz cisco Systems, Inc. 1350 Willow Road Menlo Park, CA 94025
Phone: (415) 326-1941
Email: Satz@CISCO.COM
Satz [Page 70]
Ad
Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.
