Internet draft Interface MIB Extensions October 1990 Extensions to the Generic-Interface MIB 15 October 1990 Keith McCloghrie Hughes LAN Systems, Inc. kzm@hls.com 1. Status of this Memo This draft document will be submitted to the RFC editor as an experimental extension to the SNMP MIB. Distribution of this memo is unlimited. Please send comments to the author. 2. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines managed object types as experimental extensions to the generic interfaces structure of MIB-II. 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 incorporated into the Internet-standard MIB. McCloghrie [Page 1]
Internet draft Interface MIB Extensions October 1990 3. 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 [6]. 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 McCloghrie [Page 2]
Internet draft Interface MIB Extensions October 1990 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. This memo defines extensions to the MIB using the second method. It contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. 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. McCloghrie [Page 3]
Internet draft Interface MIB Extensions October 1990 4. Objects 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. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions The next section contains the specification of all object types specified in this section of the MIB. The object types are defined using the conventions specified in the SMI, as amended by the extensions specified in [10]. McCloghrie [Page 4]
Internet draft Interface MIB Extensions October 1990 5. Overview The Internet Standard MIB [4,6] contains a group of management objects pertaining to a network device's generic network interface(s). These objects are generic in the sense that they apply to all network interfaces, irrespective of the type of communication media and protocols used on such interfaces. This has proved to be necessary but not sufficient; there are efforts underway to define additional MIB objects which are specific to particular media and lower-level (subnetwork-layer and below) protocol stacks. However, some of these efforts have identified objects which are required (or at least useful), but are not specific to the interface-type on which the effort is focusing. In order to avoid redundancy, it is better that such objects be defined as extensions to the generic interface group, rather than defined in multiple specific-interface-type MIBs. This memo defines the resultant extensions to the generic interface group. These extensions are spread over three tables: the generic Interface Extension table, the generic Interface Test table, and the generic Receive Address table. 5.1. Generic Interface Extension Table This table consists of new objects applicable to all types of subnetwork interface. 5.2. Generic Interface Test Table This section defines objects which allow a network manager to instruct an agent to test an interface for various faults. A few common types of tests are defined in this document but most will be defined elsewhere dependent on the particular type of interface. After invoking a test, the object ifExtnsTestResult can be read to determine the outcome. If an agent can not perform the test, ifExtnsTestResult is set to so indicate. The object ifExtnsTestCode can be used to provide further test-specific or interface-specific (or even enterprise-specific) information concerning the outcome of the test. Only one test can be in progress on each interface at any one time. If one test is in progress when another test is McCloghrie [Page 5]
Internet draft Interface MIB Extensions October 1990 invoked, the second test is rejected. Some agents may reject a test when a prior test is active on another interface. When a test is invoked, the authentication service user identity (as defined in [9]) originating the request is saved by the agent, in the objects ifExtnsTestUser and ifExtnsTestCommunity. These values remain set until the next test is invoked. In the (rare) event that the invocation of tests by two network managers were to overlap, then there is a possibility that the first test's results might be overwritten by the second test's results prior to the first results being read. This unlikely circumstance can be detected by a network manager retrieving the test-invoking authentication service user identity at the same time as the test results are retrieved, and ensuring that the results are for the desired user identity. In general, a Management station must not retransmit a request to invoke a test for which it does not receive a response; instead, it properly inspects an agent's MIB to determine if the invocation was successful. Only if the invocation was unsuccessful, is the invocation request retransmitted. Some tests may require the interface to be taken off-line in order to execute them, or may even require the agent to reboot after completion of the test. In these circumstances, communication with the management station invoking the test may be lost until after completion of the test. The agent should make every effort to transmit a response to the request which invoked the test prior to losing communication. When the agent is restored to normal service, the results of the test are properly made available in the appropriate objects. An agent which cannot, perhaps due to resource constraints, retain even the minimum amount of information in these situations, must reject any test which can cause one of these situations to occur. 5.3. Generic Receive Address Table This table of objects contains objects relating to an interface's support for receiving packets/frames at more than one address on the same interface. McCloghrie [Page 6]
Internet draft Interface MIB Extensions October 1990 6. Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN -- Extensions to MIB-II's Generic Interface Table IMPORTS experimental, Counter FROM RFC1155-SMI DisplayString FROM RFC1158-MIB PhysAddress FROM RFC-mmmm-MIB-II OBJECT-TYPE FROM RFC-oooo; -- This MIB Module uses the extended OBJECT-TYPE macro as -- defined in [10] ifExtensions OBJECT IDENTIFIER ::= { experimental 6 } -- Generic Interface Extension Table -- -- This group of objects is mandatory for all types of -- subnetwork interface. ifExtnsTable OBJECT-TYPE SYNTAX SEQUENCE OF IfExtnsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of interfaces extension entries. The number of entries is given by the value of ifNumber, defined in [4,6]." ::= { ifExtensions 1 } ifExtnsEntry OBJECT-TYPE SYNTAX IfExtnsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An extension to the interfaces entry, defined in [4,6], containing additional McCloghrie [Page 7]
Internet draft Interface MIB Extensions October 1990 objects at the subnetwork layer and below for a particular interface." INDEX { ifExtnsIfIndex } ::= { ifExtnsTable 1 } IfExtnsEntry ::= SEQUENCE { ifExtnsIfIndex INTEGER, ifExtnsChipSet OBJECT IDENTIFIER, ifExtnsRevWare DisplayString, ifExtnsMulticastsTransmittedOks Counter, ifExtnsBroadcastsTransmittedOks Counter, ifExtnsMulticastsReceivedOks Counter, ifExtnsBroadcastsReceivedOks Counter, ifExtnsPromiscuous INTEGER } ifExtnsIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the interface for which this entry contains extended management information. The value of this object for a particular interface has the same value as the ifIndex object, defined in [4,6], for the same interface." ::= { ifExtnsEntry 1 } ifExtnsChipSet OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "This object identifies the hardware chip set being used in the interface. The assignment of OBJECT IDENTIFIERs to various McCloghrie [Page 8]
Internet draft Interface MIB Extensions October 1990 types of hardware chip sets is defined elsewhere. This document assigns only the value: unknownChipSet for use if the chip set in use is unknown. Note that unknownChipSet is a syntactically valid object identifier, and any conformant implementation of ASN.1 and the BER must be able to generate and recognize this value." ::= { ifExtnsEntry 2 } -- for unknown hardware chip set unknownChipSet OBJECT IDENTIFIER ::= { 0 0 } ifExtnsRevWare OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "An arbitrary octet string that describes the firmware version of this interface. It is intended that this should be human readable. It must only contain ASCII printable characters. Typically this will be the firmware version of the main interface software." ::= { ifExtnsEntry 3 } ifExtnsMulticastsTransmittedOks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of frames successfully transmitted to a subnetwork or link-layer multicast destination address other than a broadcast address. For a MAC layer protocol, this includes both Group and Functional addresses." ::= { ifExtnsEntry 4 } ifExtnsBroadcastsTransmittedOks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory McCloghrie [Page 9]
Internet draft Interface MIB Extensions October 1990 DESCRIPTION "The count of frames successfully transmitted to a subnetwork or link-layer broadcast addresses. It does not include frames sent to a multicast address." ::= { ifExtnsEntry 5 } ifExtnsMulticastsReceivedOks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of frames successfully received that are directed to an active subnetwork or link-layer multicast address (for a MAC layer protocol, this includes both Group and Functional addresses). This does not include frames directed to a broadcast address, nor frames received with errors." ::= { ifExtnsEntry 6 } ifExtnsBroadcastsReceivedOks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of frames successfully received that are directed to a subnetwork or link-layer broadcast address." ::= { ifExtnsEntry 7 } ifExtnsPromiscuous OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only -- Note: agent implementors are -- encouraged to extend this -- access to read-write if that -- makes sense in their agent. STATUS mandatory DESCRIPTION "This object has a value of false(2) if this interface only accepts packets/frames that are addressed to this station. This McCloghrie [Page 10]
Internet draft Interface MIB Extensions October 1990 object has a value of true(1) when the station accepts all packets/frames transmitted on the media. The value true(1) is only legal on certain types of media. If legal, setting this object to a value of true(1) may require the interface to be reset before becoming effective." ::= { ifExtnsEntry 8 } -- -- Generic Interface Test Table -- -- This group of objects is optional, but if the table is -- implemented, all objects in the table must be implemented. ifExtnsTestTable OBJECT-TYPE SYNTAX SEQUENCE OF IfExtnsTestEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains one entry per interface." ::= { ifExtensions 2 } ifExtnsTestEntry OBJECT-TYPE SYNTAX IfExtnsTestEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry containing objects for invoking tests on an interface." INDEX { ifExtnsTestIfIndex } ::= { ifExtnsTestTable 1 } IfExtnsTestEntry ::= SEQUENCE { ifExtnsTestIfIndex INTEGER, ifExtnsTestUser OCTET STRING, ifExtnsTestCommunity OCTET STRING, ifExtnsTestType OBJECT IDENTIFIER, ifExtnsTestResult INTEGER, McCloghrie [Page 11]
Internet draft Interface MIB Extensions October 1990 ifExtnsTestCode OBJECT IDENTIFIER } ifExtnsTestUser OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "This object contains the name of the authentication service user [9] who originated the SNMP Message which invoked the current or most recent test on this interface. If the authentication service user is unknown or undefined, this value contains the zero-length string." ::= { ifExtnsTestEntry 1 } ifExtnsTestCommunity OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "This object contains the name of the SNMP authentication community [9] which was used to authenticate the SNMP Message which invoked the current or most recent test on this interface. If the authentication community is unknown or undefined, this value contains the zero-length string." ::= { ifExtnsTestEntry 2 } ifExtnsTestIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the interface for which this entry contains information on interface tests. The value of this object for a particular interface has the same value as the ifIndex object, defined in [4,6], for the same interface." ::= { ifExtnsTestEntry 3 } McCloghrie [Page 12]
Internet draft Interface MIB Extensions October 1990 ifExtnsTestType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "A control variable used to start and stop operator-initiated interface tests. If the value noTest is written, then this aborts any test in progress, or if no test is in progress, acts as a no-operation. If any other value is used, writing to this object is only valid when no test is currently in progress, in which case the indicated test is initiated. Most OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in associ- ation with specific types of interface. However, this document does assign a value for a full-duplex loopback test. Also, the subject identifier, noTest, is defined here. Note that noTest is a syntactically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value. When read, this object always returns the most recent value that ifExtnsTestType was set to. If it has not been set since the last initialization of the network management subsystem on the node, it returns a value of noTest." ::= { ifExtnsTestEntry 4 } -- abort Test in progress/ no Test in progress noTest OBJECT IDENTIFIER ::= { 0 0 } wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 } -- full-duplex loopback test testFullDuplexLoopBack OBJECT IDENTIFIER ::= { wellKnownTests 1 } ifExtnsTestResult OBJECT-TYPE SYNTAX INTEGER { none(1), -- no test yet requested McCloghrie [Page 13]
Internet draft Interface MIB Extensions October 1990 success(2), inProgress(3), notSupported(4), unAbleToRun(5), -- due to state of system aborted(6), failed(7) } ACCESS read-only STATUS mandatory DESCRIPTION "This object contains the result of the most recently requested test, or the value none(1) if no tests have been requested since the last reset. Note that this facility provides no provision for saving the results of one test when starting another, as could be required if used by multiple managers concurrently." ::= { ifExtnsTestEntry 5 } ifExtnsTestCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test. Error codes and other values this object may take are specific to the type of interface and/or test. However, one subject identifier, testCodeUnknown, is defined here for use if no additional result code is available. Note that testCodeUnknown is a syntactically valid object identifier, and any conformant implementation of ASN.1 and the BER must be able to generate and recognize this value." ::= { ifExtnsTestEntry 6 } -- no additional result code available testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } McCloghrie [Page 14]
Internet draft Interface MIB Extensions October 1990 -- Generic Receive Address Table -- -- This group of objects is mandatory for all types of -- interfaces which can receive packets/frames addressed to -- more than one address. ifExtnsRcvAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains an entry for each address (broadcast, multicast, or uni-cast) for which the system will receive packets/ frames on a particular interface. When an interface is operating in promiscuous mode, entries are only required for those addresses for which the system would receive frames were it not operating in promiscuous mode." ::= { ifExtensions 3 } ifExtnsRcvAddrEntry OBJECT-TYPE SYNTAX IfExtnsRcvAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of objects identifying an address for which the system will accept packets/ frames on a particular interface." INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress } ::= { ifExtnsRcvAddrTable 1 } IfExtnsRcvAddrEntry ::= SEQUENCE { ifExtnsRcvAddrIfIndex INTEGER, ifExtnsRcvAddress PhysAddress, ifExtnsRcvAddrStatus INTEGER } ifExtnsRcvAddrIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only McCloghrie [Page 15]
Internet draft Interface MIB Extensions October 1990 STATUS mandatory DESCRIPTION "The value of ifIndex, defined in [4,6], of an interface which recognizes this entry's address." ::= { ifExtnsRcvAddrEntry 1 } ifExtnsRcvAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-only STATUS mandatory DESCRIPTION "An address for which the system will accept packets/frames on this entry's interface." ::= { ifExtnsRcvAddrEntry 2 } ifExtnsRcvAddrStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), volatile(3), nonVolatile(4) } ACCESS read-write STATUS mandatory DESCRIPTION "This object has the value nonVolatile(4) for those entries in the table which are valid and will not be deleted by the next restart of the managed system. Entries having the value volatile(3) are valid and exist, but have not been saved, so that will not exist after the next restart of the managed system. Entries having the value other(1) are valid and exist but are not classified as to whether they will continue to exist after the next restart. Entries having the value invalid(2) are invalid and do not represent an address for which an interface accepts frames. Setting an object instance to one of the values other(1), volatile(3), or nonVolatile(4) causes the corresponding entry to exist or continue to exist, and McCloghrie [Page 16]
Internet draft Interface MIB Extensions October 1990 to take on the respective status as regards the next restart of the managed system. Setting an object instance to the value invalid(2) causes the corresponding entry to become invalid or cease to exist. 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 ifExtnsRcvAddrStatus object instance." DEFVAL { volatile } ::= { ifExtnsRcvAddrEntry 3 } END McCloghrie [Page 17]
Internet draft Interface MIB Extensions October 1990 7. Acknowledgements Most of the MIB objects defined in this document were originally proposed as a part of the IEEE 802.5 MIB, as prepared by: Eric B. Decker, cisco Systems, Inc., and Richard Fox, Synoptics Inc. In addition, the comments of the following individuals are acknowledged: James R. Davin, MIT-LCS, Stan Froyd, ACC, Frank Kastenholz, Racal Interlan Marshall T. Rose, PSI, Bob Stewart, Xyplex, David Waitzman, BBN, Wengyik Yeong, PSI, McCloghrie [Page 18]
Internet draft Interface MIB Extensions October 1990 8. References [1] V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working Group Request for Comments 1052. Network Information Center, SRI International, Menlo Park, California, (April, 1988). [2] V. Cerf, Report of the Second Ad Hoc Network Management Review Group, Internet Working Group Request for Comments 1109. Network Information Center, SRI International, Menlo Park, California, (August, 1989). [3] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [6] M.T. Rose (editor), Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1158. Network Information Center, SRI International, Menlo Park, California, (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 McCloghrie [Page 19]
Internet draft Interface MIB Extensions October 1990 Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [9] J.M. Galvin, K. McCloghrie, J.R. Davin, Authentication and Privacy in the SNMP, Internet Working Group, Request for Comments (in preparation), Network Information Center, SRI International, Menlo Park, California, (September, 1990). [10] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB Definitions, Internet Draft, Internet Engineering Task Force, (September, 1990). McCloghrie [Page 20]
Internet draft Interface MIB Extensions October 1990 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Historical Perspective ................................ 2 4 Objects ............................................... 4 4.1 Format of Definitions ............................... 4 5 Overview .............................................. 5 5.1 Generic Interface Extension Table ................... 5 5.2 Generic Interface Test Table ........................ 5 5.3 Generic Receive Address Table ....................... 6 6 Definitions ........................................... 7 7 Acknowledgements ...................................... 18 8 References ............................................ 19 McCloghrie [Page 21]
------- End of Forwarded Message