INTERNET-DRAFT System/Interface Test MIB June 1997
Definitions of Managed Objects for
System and Interface Testing
June, 1997
<draft-ietf-ifmib-testmib-03.txt>
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]
