INTERNET-DRAFT System/Interface Test MIB June 1997 Definitions of Managed Objects for System and Interface Testing June, 1997 Maria Greene Ascom Nexion greene@nexen.com Keith McCloghrie Cisco Systems kzm@cisco.com Kaj Tesink Bell Communications Research kaj@cc.bellcore.com Status of this Memo This document is an Internet-Draft. 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 a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires December 1997 [Page 1] INTERNET-DRAFT System/Interface Test MIB June 1997 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for testing systems and interfaces. This memo replaces the objects originally defined in the ifTestGroup of RFC1573, the IF-MIB [6], which have been deprecated. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions 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) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. 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 descriptor, to also refer to the object type. Expires December 1997 [Page 2] INTERNET-DRAFT System/Interface Test MIB June 1997 2. Experience with the Interfaces Test Group The ifTestGroup of objects defined in RFC1573 has not been used widely. Some cited problems were: o Few standard tests had been defined to date. o Some well known tests had already been written on a media- specific basis, e.g., DS1 loopback. o The ifTestGroup allowed for interface testing only. o A logging capability was missing. As a result, the ifTestGroup and associated ifTestTable have been deprecated. However, since renewed interest was expressed in a generic testing capability, specifically in the development of MIBs for managing Asynchronous Transfer Mode interfaces, a set of requirements have been defined that form the basis for the design of the generic Test MIB defined in this memo. 3. Requirements for a Generic Test MIB This section describes the requirements that have been identified for a generic test MIB. 3.1. Test Identification The system defined in RFC1573 to identify tests relies on OBJECT IDENTIFIERs. This system is flexible in that it allows additional tests to be defined over time and autonomously by vendors, removing the need to register test types in a single place. This mechanism for test identification has been retained. Expires December 1997 [Page 3] INTERNET-DRAFT System/Interface Test MIB June 1997 3.2. Test Targets With the advent of an increasing number of non-interface related MIB modules it is desirable to define a test capability that allows testing of interfaces and non-interface physical entities. The following possibilities were considered: a) Separate test capabilities for interface tests and other tests. b) The use of a single test capability where the test target would be defined within the test table. This memo uses the latter approach and uses an object with the syntax RowPointer to identify test targets. (Initially, the use of the Entity MIB was considered for identification of test targets, but this was abandoned because this would require support of the Entity MIB for testing purposes.) Tests are listed in the testTable. The entries in the testTable are distinguished through the value of a simple integer called testIndex. Expires December 1997 [Page 4] INTERNET-DRAFT System/Interface Test MIB June 1997 3.3. Logging Results A logging capability of test results serves to store the test results for some period of time. Two mechanisms were considered: 1) Separate the test capability and the log. 2) Combine the test capability and the log in a single table. Note that searching criteria on the log relate to this choice as well. The log length is necessarily limited. The following choices were considered: 1) Age the entries. 2) Limit by the number of entries. 3) A system that allows either 1) or 2). This MIB module chooses a system where the test and logging capability have been combined in a single table (testTable). The log length is limited by a read-write object (testTableMaxSize). This MIB module also defines a notification, testComplete, which contains the same information as the log entry. Therefore, an agent with limited resources can limit the maximum size of the log to a very few number of entries and rely on a management application to receive and log the testComplete notifications. 3.4. Log Searching Efficient searching in a log is a key to its effectiveness. The following possibilities were considered: a) Sort on age of the entries. b) Sort on test type. c) Sort on combinations of the above. Expires December 1997 [Page 5] INTERNET-DRAFT System/Interface Test MIB June 1997 This MIB module chooses for the index testIndex, which is an integer identifier for an invocation of a test. To obtain a new testIndex a manager retrieves the value of testIndexNext. Each time this object is read the next lower available value is provided. This addresses the requests that are expected to be most common: o What is the result of test (testIndex)? o What are the results of the last n tests? Since the testIndex has been defined as decreasing, this approach will order log entries by time, newest to oldest. The possibility of testId wrapping is minimized by having it restart at its maximum value and when the agent restarts. When a manager is interested in a specific test, a specific get-request may be issued. When a manager is interested in the latest n tests for the system, getnext/bulk starting from (testIndex) provides the approximate answer. 3.5. Determining Agent Test Capabilities A testCapabilitiesTable has been defined to list the tests that can be performed through this agent. Expires December 1997 [Page 6] INTERNET-DRAFT System/Interface Test MIB June 1997 4. Definitions TEST-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, experimental, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI AutonomousType, RowPointer, TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF OwnerString FROM IF-MIB ; testMIB MODULE-IDENTITY LAST-UPDATED "9706031200Z" ORGANIZATION "IETF IFMIB Working Group" CONTACT-INFO "Keith McCloghrie Postal: Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Tel: +1 408 526 5260 E-mail: kzm@cisco.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 5254 E-mail: kaj@cc.bellcore.com Maria Greene Postal: Ascom Nexion 289 Great Road Acton, MA 01720 US Tel: +1 508 266 4570 E-mail: greene@nexen.com" DESCRIPTION "This MIB module provides a generic test capability." -- ******** NOTE TO THE RFC EDITOR ************** Expires December 1997 [Page 7] INTERNET-DRAFT System/Interface Test MIB June 1997 -- In case this module is put on the standards track -- replace the following: -- "::= {experimental XX}" with -- "::= { mib-2 YY }" ::= { experimental XX } testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } testIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for testIndex when creating entries in the testTable. The value 0 indicates that no unassigned entries are available. To obtain the testIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next lower unassigned index. If the agent is restarted this object shall be set to its highest value." ::= { testMIBObjects 1 } -- The Test Table testTable OBJECT-TYPE SYNTAX SEQUENCE OF TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to initiate tests. An entry in this table corresponds to an instance of a test. A test is invoked by creating a row with the appropriate test attributes and using testRowStatus to start a test. After invoking a test, the object testResult can be read to determine the outcome. If an agent can not perform the test, testResult is set accordingly. The testCode can be used to provide further test-specific or entity- specific (or even enterprise-specific) information Expires December 1997 [Page 8] INTERNET-DRAFT System/Interface Test MIB June 1997 concerning the outcome of the test. Only one test can be in progress on each entity at any one time. If one test is in progress when another test is invoked, the second test is rejected. Some agents may reject a test when a prior test is active on another entity. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the entity to be tested. This is accomplished by retrieving the value of testIndexNext. This value entitles the manager to create a row in the testTable with the value of testIndex being equal to the retrieved value of testIndexNext. Once ownership is obtained, the test parameters can be setup, and then the test is initiated by activating the row through testRowStatus. The agent sets the value of testResult to 'inProgress'. On completion of the test, the agent sets testResult and testCode in accordance with the test results and sets the testCompletionTime. If testRowStatus is not set to active within an abnormally long period of time after ownership is obtained, the agent should time-out the manager, and reset the value of the testRowStatus object back to 'destroy'. It is suggested that this time-out period be 5 minutes. 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 entity 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. An agent is not required to support such tests. However, if such tests are supported, then 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 Expires December 1997 [Page 9] INTERNET-DRAFT System/Interface Test MIB June 1997 available in the appropriate objects. Note that this requires that the testIndex value assigned to an entity must be unchanged even if the test causes a reboot. An agent must reject any test for which it cannot, perhaps due to resource constraints, make available at least the minimum amount of information after that test completes." ::= { testMIBObjects 2 } testEntry OBJECT-TYPE SYNTAX TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing objects for invoking a test." INDEX { testIndex } ::= { testTable 1 } TestEntry ::= SEQUENCE { testIndex Unsigned32, testTarget RowPointer, testMoreInfo OCTET STRING, testType AutonomousType, testCompletionTime TimeStamp, testResult INTEGER, testCode OBJECT IDENTIFIER, testOwner OwnerString, testRowStatus RowStatus } testIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table." ::= { testEntry 1 } testTarget OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "The target of the test. An example of a test target is an instance of an interface, identified by the OID 'ifIndex.17'." Expires December 1997 [Page 10] INTERNET-DRAFT System/Interface Test MIB June 1997 DEFVAL { { 0 0 } } ::= { testEntry 2 } testMoreInfo OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "Additional information for the test." DEFVAL { "" } ::= { testEntry 3 } testType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The identifier that specifies the test. OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in association with specific types of entity. However, this document assigns a value for a full- duplex loopback test, and defines the special meanings of the subject identifier: noTest OBJECT IDENTIFIER ::= { 0 0 } When the value noTest is written to this object, no action is taken. " DEFVAL { { 0 0 } } ::= { testEntry 4 } testCompletionTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the test completed." ::= { testEntry 5 } testResult OBJECT-TYPE SYNTAX INTEGER { none(1), -- no test yet requested success(2), inProgress(3), notSupported(4), unAbleToRun(5), -- due to state of system Expires December 1997 [Page 11] INTERNET-DRAFT System/Interface Test MIB June 1997 aborted(6), failed(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the result of the most recently requested test, or the value 'none(1)' if no test has been started yet." DEFVAL { none } ::= { testEntry 6 } testCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test or a result value such as round trip time for a 'ping' test. Error codes and other values this object may take are specific to the type of entity and/or test. The value may have the semantics of AutonomousType, InstancePointer, RowPointer or VariablePointer textual conventions as defined in RFC 1903. The identifier: testCodeNone OBJECT IDENTIFIER ::= { 0 0 } is defined for use if no additional result code is available." DEFVAL { { 0 0 } } ::= { testEntry 7 } testOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The manager which currently has the 'ownership' required to invoke a test on this entity." ::= { testEntry 8 } testRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Expires December 1997 [Page 12] INTERNET-DRAFT System/Interface Test MIB June 1997 "The status of the test: - When the manager activates the row the test is started. - When the test is completed the row will remain active or may be destroyed by the manager. - Details of ongoing or just completed tests are reported in testResult and testCode. - A manager may abort ongoing tests or remove completed test information by setting the row status to notInService or destroy." DEFVAL { active } ::= { testEntry 9 } -- Table size testTableMaxSize OBJECT-TYPE SYNTAX Unsigned32 (10..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number entries in the testTable. When the table reaches this size the oldest entries will be discarded when new entries are added. The table is flushed when the agent is reset." ::= { testMIBObjects 3 } -- Test Capabilities Table testCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF TestCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the test that this entity is able to invoke." ::= { testMIBObjects 4 } testCapabilitiesEntry OBJECT-TYPE SYNTAX TestCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a test." INDEX { testCapabilitiesIndex } ::= { testCapabilitiesTable 1 } Expires December 1997 [Page 13] INTERNET-DRAFT System/Interface Test MIB June 1997 TestCapabilitiesEntry ::= SEQUENCE { testCapabilitiesIndex Unsigned32, testCapabilitiesType AutonomousType } testCapabilitiesIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer index that uniquely identifies the entry." ::= { testCapabilitiesEntry 1 } testCapabilitiesType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of test that can be invoked." ::= { testCapabilitiesEntry 2 } -- Notifications testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } testComplete NOTIFICATION-TYPE OBJECTS { testIndex, testTarget, testMoreInfo, testType, testResult, testCode, testOwner } STATUS current DESCRIPTION "A testComplete trap signifies that a test has completed for a particular entity. If the testCode has the semantics of a VariablePointer, the variable it points at will also be included in the objects list." ::= { testMIBNotifications 1 } -- Conformance Information Expires December 1997 [Page 14] INTERNET-DRAFT System/Interface Test MIB June 1997 testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } testMIBGroups OBJECT IDENTIFIER ::= { testMIBConformance 1 } testMIBCompliances OBJECT IDENTIFIER ::= { testMIBConformance 2 } -- Compliance Statements testMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP agents which support generic testing capabilities." MODULE -- this module MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } OBJECT testMaxSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { testMIBCompliances 1 } -- Units of Conformance testMIBGroup OBJECT-GROUP OBJECTS { testIndexNext, testTarget, testMoreInfo, testType, testCompletionTime, testResult, testCode, testOwner, testRowStatus, testTableMaxSize, testCapabilitiesType } STATUS current DESCRIPTION Expires December 1997 [Page 15] INTERNET-DRAFT System/Interface Test MIB June 1997 "A collection of objects providing a generic test capability." ::= { testMIBGroups 1 } testNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { testComplete } STATUS current DESCRIPTION "The notifications used to indicate test completion." ::= { testMIBGroups 2 } END 5. Acknowledgments This document is a product of the IETF's Interfaces MIB Working Group. The original ifTestTable was the work of Keith McCloghrie (Cisco) and Frank Kastenholz (FTP Software) and has been used in this further evolution. The authors would like to acknowledge the following individuals for their input on requirements: James Watt (Newbridge) Dave Fowler (Newbridge) Steven Buchko (Newbridge) Milt Rosslinsky (ACC) Dawn Xie (Lucent) Chris Martin (Netedge) Expires December 1997 [Page 16] INTERNET-DRAFT System/Interface Test MIB June 1997 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC2037, Cisco Systems, January 1996. [6] Kastenholz, F., "Definitions of Managed Objects for the Ethernet- like Interface Types using SMIv2", RFC1650, FTP Software, Inc, August 1994. [6] McCloghrie, K., Kastenholz, F., "Evolution of the Interfaces Group of MIB-II", RFC1573, (should be updated to new IF-MIB RFC#) Cisco Systems, Inc., FTP Software, January 1994. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires December 1997 [Page 17] INTERNET-DRAFT System/Interface Test MIB June 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720-4739 Phone: (508) 266-4570 EMail: greene@nexen.com Keith McCloghrie Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 526-5260 E-mail: kzm@cisco.com Kaj Tesink Bell Communications Research Room 1A-427 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires December 1997 [Page 18] INTERNET-DRAFT System/Interface Test MIB June 1997 Table of Contents 1 The SNMP Network Management Framework ........................ 2 1.1 Object Definitions ......................................... 2 2 Experience with the Interfaces Test Group .................... 3 3 Requirements for a Generic Test MIB .......................... 3 3.1 Test Identification ........................................ 3 3.2 Test Targets ............................................... 4 3.3 Logging Results ............................................ 5 3.4 Log Searching .............................................. 5 3.5 Determining Agent Test Capabilities ........................ 6 4 Definitions .................................................. 7 5 Acknowledgments .............................................. 16 6 References ................................................... 17 7 Security Considerations ...................................... 18 8 Authors' Addresses ........................................... 18 Expires December 1997 [Page 19]