INTERNET-DRAFT System/Interface Test MIB May 1996
Definitions of Managed Objects for
System and Interface Testing
May 29, 1996
<draft-ietf-ifmib-testmib-00.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 1996 [Page 1]
INTERNET-DRAFT System/Interface Test MIB May 1996
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 1996 [Page 2]
INTERNET-DRAFT System/Interface Test MIB May 1996
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 1996 [Page 3]
INTERNET-DRAFT System/Interface Test MIB May 1996
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 has taken advantage of the
Entity MIB by using the entPhysicalIndex to identify test targets.
This does require that the Entity MIB be supported in order to
implement the Test MIB. A physical entity can be a "port", which is
generally associated one-to-one with an interface (as indicated by
the entAliasMappingTable) or it can be another piece of hardware such
as a "module" or a "power supply".
3.3. Single Versus Multiple Simultaneous Tests
The capability of allowing multiple simultaneous tests has sometimes
been described as useful, though the requests for the feature have
been sporadic. However, when allowing for non-interface related tests
this need may become more apparent. Also, proxy situations may make
the ability to run multiple simultaneous tests more desirable. A
related question is: how long may a test run?
This MIB module has taken a middle road approach where simultaneous
tests on different physical entities are possible, while simultaneous
tests on a single physical entity are excluded. This approach avoids
the need for more complex read-create tables. A test in progress can
be stopped by setting the testType to 'noTest'.
Expires December 1996 [Page 4]
INTERNET-DRAFT System/Interface Test MIB May 1996
3.4. 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 capability
(testTable) has been separated from the log (testLogTable). The log
length is limited by a read-write object (testLogMaxSize).
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.5. 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 entPhysicalIndex value.
d) Sort on combinations of the above.
Expires December 1996 [Page 5]
INTERNET-DRAFT System/Interface Test MIB May 1996
This MIB module chooses for the index testId, to address requests
that are expected to be most common:
o What is the result of test testId?
o What are the results of the last n tests?
Since the testId has been defined as monotonically increasing, this
approach will order log entries by time, oldest to newest. The
possibility of testId wrapping is minimized by having it restart at 0
and the log flushed 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 (testId-n) provides the approximate
answer. Note that defining testId as a "TestAndDecr" would yield more
precise results because the testLogTable would then be sorted with
the most recent test first; however this was rejected because of the
counter-intuitive behavior of the resulting index and the slight
increase in complexity due to this new syntax. Note also that the log
is not sorted by entPhysicalIndex, based on the assumption that a
request for tests sorted by physical entity represents a less
frequent need.
3.6. Determining Agent Test Capabilities
The testTable will only have entries for those physical entities
represented by this agent that support tests. No capability has been
defined to list the tests that a physical entity is capable of.
However, if a physical entity is only capable of one test, then the
testType columnar object for that physical entity may be initialized
to that type, or, if it is capable of many tests, it may be
initialized to one of the supported types.
Expires December 1996 [Page 6]
INTERNET-DRAFT System/Interface Test MIB May 1996
4. Definitions
TEST-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, TimeTicks,
experimental, NOTIFICATION-TYPE, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr, AutonomousType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
entPhysicalIndex
FROM ENTITY-MIB
;
testMIB MODULE-IDENTITY
LAST-UPDATED "9605291200Z" -- May 29, 1996
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."
::= { experimental XX }
Expires December 1996 [Page 7]
INTERNET-DRAFT System/Interface Test MIB May 1996
testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 }
-- ******** NOTE TO THE RFC EDITOR **************
-- In case this module is put on the standards track
-- replace the following:
-- "testMIB MODULE-IDENTITY ::= {experimental XX}" with
-- "testMIB MODULE-IDENTITY ::= { mib-2 YY }"
HostName ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"This data type is used to model an administratively
assigned hostname of the owner of a test. This
information is taken from the NVT ASCII character set.
It is suggested that this name contain one or more of
the following: ASCII form of the manager station's
transport address or management station name (e.g.,
domain name)."
SYNTAX OCTET STRING (SIZE(0..255))
-- The Test Table
testTable OBJECT-TYPE
SYNTAX SEQUENCE OF TestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one entry per physical entity that
supports testing. It defines objects which allow a
network manager to instruct an agent to test an physical
entity for various faults. Tests for a physical entity
are defined in the media-specific MIB for that entity.
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 to so indicate. The
testLogTable can be used to provide further test-
specific or entity-specific (or even enterprise-
specific) information concerning the outcome of the
test. Only one test can be in progress on each physical
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 physical entity.
Before starting a test, a manager-station must first
Expires December 1996 [Page 8]
INTERNET-DRAFT System/Interface Test MIB May 1996
obtain 'ownership' of the entry in the testTable for the
physical entity to be tested. This is accomplished with
the testId and testStatus objects as follows:
try_again:
get (testId, testStatus)
while (testStatus != notInUse)
/*
* Loop while a test is running or some other
* manager is configuring a test.
*/
short delay
get (testId, testStatus)
}
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = testId
if ( set (testId = lock_value, testStatus = inUse,
testOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the testEntry -- go
* try again
*/
goto try_again;
/*
* I have the lock
*/
set up any test parameters.
/*
* This starts the test
*/
set (testType = test_to_run);
wait for test completion by polling testResult
when test completes, agent sets testResult
agent also sets testStatus = 'notInUse'
retrieve test results from the testLog using
lock_value as the index
Expires December 1996 [Page 9]
INTERNET-DRAFT System/Interface Test MIB May 1996
A manager station first retrieves the value of the
appropriate testId and testStatus objects,
periodically repeating the retrieval if necessary,
until the value of testStatus is 'notInUse'. The
manager station then tries to set the same testId
object to the value it just retrieved, the same
testStatus object to 'inUse', and the corresponding
testOwner object to a value indicating itself. If
the set operation succeeds then the manager has
obtained ownership of the testEntry, and the value of
the testId object is incremented by the agent (per
the semantics of TestAndIncr). Failure of the set
operation indicates that some other manager has
obtained ownership of the testEntry.
Once ownership is obtained, any test parameters can be
setup, and then the test is initiated by setting
testType. On completion of the test, the agent sets
testStatus to 'notInUse'. Once this occurs, the
manager can retrieve the results. In the (rare) event
that the invocation of tests by two network managers
were to overlap, then there would be 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 testId at the same time as
retrieving the test results, and ensuring that the
results are for the desired request.
If testType is not set within an abnormally long
period of time after ownership is obtained, the agent
should time-out the manager, and reset the value of the
testStatus object back to 'notInUse'. 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 physical 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
Expires December 1996 [Page 10]
INTERNET-DRAFT System/Interface Test MIB May 1996
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 available in the appropriate objects. Note
that this requires that the entPhysicalIndex value
assigned to a physical 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 1 }
testEntry OBJECT-TYPE
SYNTAX TestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing objects for invoking tests on a
physical entity."
INDEX { entPhysicalIndex }
::= { testTable 1 }
TestEntry ::=
SEQUENCE {
testId TestAndIncr,
testStatus INTEGER,
testType AutonomousType,
testResult INTEGER,
testOwner HostName
}
testId OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies the current invocation of any
test, not just tests on the physical entity identified by
the index of this entry. If the agent is restarted the
value of this object shall be set to 0. If the value of
testId ever reaches its maximum value of 2147483647, it
will latch at that value and return the error
'inconsistentValue' (for SNMPv2) or 'badValue' (for
SNMPv1) if the manager attempts to set it.
Expires December 1996 [Page 11]
INTERNET-DRAFT System/Interface Test MIB May 1996
Note that the value the manager sets this object to when
setting the testStatus to 'inUse(2)' is the value that
should be used for testLogIndex to retrieve the results of
the test. After a successful SET, all instances of testId
for all entries in this table will be incremented.
The reason the testId and testStatus objects are not
outside the table is that this would limit the manager to
only running one test at a time."
::= { testEntry 1 }
testStatus OBJECT-TYPE
SYNTAX INTEGER { notInUse(1), inUse(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates whether or not some manager
currently has the necessary 'ownership' required to invoke
a test on this physical entity. A write to this object is
only successful when it changes its value from
'notInUse(1)' to 'inUse(2)'. After completion of a test,
the agent resets the value back to
::= { testEntry 2 }
testType OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control variable used to start and stop operator-
initiated entity tests. Most OBJECT IDENTIFIER values
assigned to tests are defined elsewhere, in association with
specific types of entity. However, this memo 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 unless a test is in progress, in which case the
test is aborted. Writing any other value to this object is
only valid when no test is currently in progress, in which
case the indicated test is initiated.
When read, this object always returns the most recent value
that testType was set to. If it has not been set since the
last initialization of the network management subsystem on
the agent, either a value of or a value of one of the valid
Expires December 1996 [Page 12]
INTERNET-DRAFT System/Interface Test MIB May 1996
test types that can be performed on this physical entity is
returned."
::= { testEntry 3 }
testResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
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 tests have been
requested since the last reset."
::= { testEntry 4 }
testOwner OBJECT-TYPE
SYNTAX HostName
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The manager which currently has the 'ownership'
required to invoke a test on this physical entity."
::= { testEntry 5 }
-- Log size
testLogMaxSize OBJECT-TYPE
SYNTAX INTEGER (10..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number entries in the testLogTable. 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 2 }
Expires December 1996 [Page 13]
INTERNET-DRAFT System/Interface Test MIB May 1996
-- Test Logging Table
testLogTable OBJECT-TYPE
SYNTAX SEQUENCE OF TestLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the most recent test results for tests
which completed with the testResult of either 'success(2)'
or 'failed(7)'."
::= { testMIBObjects 3 }
testLogEntry OBJECT-TYPE
SYNTAX TestLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in this table represents a test result."
INDEX { testLogIndex }
::= { testLogTable 1 }
TestLogEntry ::=
SEQUENCE {
testLogIndex INTEGER,
testLogType AutonomousType,
testLogCompletionTime TimeTicks,
testLogSummary INTEGER,
testLogCode OBJECT IDENTIFIER,
testLogOwner HostName,
testLogEntPhysicalIndex INTEGER
}
testLogIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An integer index that uniquely identifies the entry in the
log."
::= { testLogEntry 1 }
testLogType OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of test that has completed."
Expires December 1996 [Page 14]
INTERNET-DRAFT System/Interface Test MIB May 1996
::= { testLogEntry 2 }
testLogCompletionTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the test completed."
::= { testLogEntry 3 }
testLogSummary OBJECT-TYPE
SYNTAX INTEGER {
success(2),
failed(7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The summary result of this test."
::= { testLogEntry 4 }
testLogCode 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. Error codes and other values this
object may take are specific to the type of physical entity
and/or test. The value may have the semantics of either the
AutonomousType or VariablePointer textual conventions as
defined in RFC 1903. The identifier:
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
is defined for use if no additional result code is
available."
::= { testLogEntry 5 }
testLogOwner OBJECT-TYPE
SYNTAX HostName
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the host that owned the test."
::= { testLogEntry 6 }
Expires December 1996 [Page 15]
INTERNET-DRAFT System/Interface Test MIB May 1996
testLogEntPhysicalIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of entPhysicalIndex for this test."
::= { testLogEntry 7 }
-- Notifications
testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 2 }
testComplete NOTIFICATION-TYPE
OBJECTS {
testLogIndex,
testLogType,
testLogSummary,
testLogCode,
testLogOwner,
testLogEntPhysicalIndex
}
STATUS current
DESCRIPTION
"A testComplete trap signifies that a test has completed for
a particular physical entity. If the testLogCode has the
semantics of a VariablePointer, the variable it points at
will also be included in the objects list."
::= { testMIBNotifications 1 }
-- Conformance Information
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."
Expires December 1996 [Page 16]
INTERNET-DRAFT System/Interface Test MIB May 1996
MODULE -- this module
MANDATORY-GROUPS { testMIBGroup }
OBJECT testLogMaxSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { testMIBCompliances 1 }
-- Units of Conformance
testMIBGroup OBJECT-GROUP
OBJECTS {
testId,
testStatus,
testType,
testResult,
testOwner,
testLogType,
testLogMaxSize,
testLogCompletionTime,
testLogSummary,
testLogCode,
testLogOwner,
testLogEntPhysicalIndex
}
STATUS current
DESCRIPTION
"A collection of objects providing a generic
test capability."
::= { testMIBGroups 1 }
END
Expires December 1996 [Page 17]
INTERNET-DRAFT System/Interface Test MIB May 1996
5. Usage Examples
The following sections show examples of interface testing and system
testing. These examples assume the following physical configuration
represented using the Entity MIB [5].
A router containing two slots. Each slot contains a 3 port
router/bridge module. Each port is represented in the ifTable:
Physical entities -- entPhysicalTable:
1 chassis:
entPhysicalDescr.1 == "Acme Chassis Model 100"
entPhysicalVendorType.1 == acmeProducts.chassisTypes.1
entPhysicalContainedIn.1 == 0
entPhysicalClass.1 == chassis(3)
entPhysicalParentRelPos.1 == 0
2 slots within the chassis:
entPhysicalDescr.2 == "Acme Router Chassis Slot 1"
entPhysicalVendorType.2 == acmeProducts.slotTypes.1
entPhysicalContainedIn.2 == 1
entPhysicalClass.2 == container(5)
entPhysicalParentRelPos.2 == 1
entPhysicalDescr.3 == "Acme Router Chassis Slot 2"
entPhysicalVendorType.3 == acmeProducts.slotTypes.1
entPhysicalContainedIn.3 == 1
entPhysicalClass.3 == container(5)
entPhysicalParentRelPos.3 == 2
2 Field-replaceable modules:
Slot 1 contains a module with 3 ports:
entPhysicalDescr.4 == "Acme Router Module Model 10"
entPhysicalVendorType.4 == acmeProducts.moduleTypes.14
entPhysicalContainedIn.4 == 2
entPhysicalClass.4 == module(9)
entPhysicalParentRelPos.4 == 1
entPhysicalDescr.5 == "Acme Router Ethernet Port 1"
entPhysicalVendorType.5 == acmeProducts.portTypes.2
entPhysicalContainedIn.5 == 4
entPhysicalClass.5 == port(10)
entPhysicalParentRelPos.5 == 1
entPhysicalDescr.6 == "Acme Router Ethernet Port 2"
entPhysicalVendorType.6 == acmeProducts.portTypes.2
entPhysicalContainedIn.6 == 4
Expires December 1996 [Page 18]
INTERNET-DRAFT System/Interface Test MIB May 1996
entPhysicalClass.6 == port(10)
entPhysicalParentRelPos.6 == 2
entPhysicalDescr.7 == "Acme Router Fddi Port 3"
entPhysicalVendorType.7 == acmeProducts.portTypes.3
entPhysicalContainedIn.7 == 4
entPhysicalClass.7 == port(10)
entPhysicalParentRelPos.7 == 3
Slot 2 contains another 3-port module:
entPhysicalDescr.8 == "Acme Router Module Model 11"
entPhysicalVendorType.8 == acmeProducts.moduleTypes.15
entPhysicalContainedIn.8 == 3
entPhysicalClass.8 == module(9)
entPhysicalParentRelPos.8 == 1
entPhysicalDescr.9 == "Acme Router Fddi Port 1"
entPhysicalVendorType.9 == acmeProducts.portTypes.3
entPhysicalContainedIn.9 == 8
entPhysicalClass.9 == port(10)
entPhysicalParentRelPos.9 == 1
entPhysicalDescr.10 == "Acme Router Ethernet Port 2"
entPhysicalVendorType.10 == acmeProducts.portTypes.2
entPhysicalContainedIn.10 == 8
entPhysicalClass.10 == port(10)
entPhysicalParentRelPos.10 == 2
entPhysicalDescr.11 == "Acme Router Ethernet Port 3"
entPhysicalVendorType.11 == acmeProducts.portTypes.2
entPhysicalContainedIn.11 == 8
entPhysicalClass.11 == port(10)
entPhysicalParentRelPos.11 == 3
5.1. Interface Test
In this example, the network manager wishes to run a loopback test on
the third Ethernet port on the module in slot 1. The entPhysicalIndex
of the port is 7. The Ethernet-like Interfaces MIB [6], defines an
OBJECT IDENTIFIER for the dot3TestLoopBack.
Expires December 1996 [Page 19]
INTERNET-DRAFT System/Interface Test MIB May 1996
The test would be invoked as follow:
try_again:
get (testId.7, testStatus.7)
while (testStatus != notInUse)
/*
* Loop while a test is running or some other
* manager is configuring a test.
*/
short delay
get (testId.7, testStatus.7)
}
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = testId
if ( set (testId.7 = lock_value, testStatus.7 = inUse,
testOwner.7 = 'my-IP-address') == FAILURE)
/*
* Another manager got the testEntry -- go
* try again
*/
goto try_again;
/*
* I have the lock
*/
set up any test parameters.
/*
* This starts the test
*/
set (testType.7 = dot3TestLoopBack);
wait for test completion by polling testResult.7
when test completes, agent sets testResult
agent also sets testStatus = 'notInUse'
retrieve any additional test results from
testLogTable using lock_value as the index
Expires December 1996 [Page 20]
INTERNET-DRAFT System/Interface Test MIB May 1996
5.2. System Test
A system test is the same as an interface test from the perspective
of the test table, except that the entPhysicalClass of the entity
will not be port(10). For example, the network administrator may wish
to run a self test on the module in slot 2.
Let's assume such a test is defined in one of the Acme vendor's
enterprise MIBs as follows:
acmeModuleSelfTest OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Run a diagnostic self-test on an Acme hardware
module."
::= { acmeProductsTestTypes 1 }
The procedure of invoking the test and retrieving the results is the
same as that described in the Interface Test example. Note that value
of entPhysicalIndex for the module in slot 2 is 8 based on the
earlier example configuration so the test would be started using this
operation:
/*
* This starts the test
*/
set(testType.8 = acmeModuleSelfTest);
6. 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 almost unchanged in
this further evolution.
The authors would like to acknowledge the following individuals for
their input on requirements:
Dave Fowler (Newbridge)
Steven Buchko (Newbridge)
Milt Rosslinsky (ACC)
Expires December 1996 [Page 21]
INTERNET-DRAFT System/Interface Test MIB May 1996
7. 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", RFC<TBD>,
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, 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 1996 [Page 22]
INTERNET-DRAFT System/Interface Test MIB May 1996
8. Security Considerations
Security issues are not discussed in this memo.
9. 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 1996 [Page 23]
INTERNET-DRAFT System/Interface Test MIB May 1996
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 Single Versus Multiple Simultaneous Tests .................. 4
3.4 Logging Results ............................................ 5
3.5 Log Searching .............................................. 5
3.6 Determining Agent Test Capabilities ........................ 6
4 Definitions .................................................. 7
5 Usage Examples ............................................... 18
5.1 Interface Test ............................................. 19
5.2 System Test ................................................ 21
6 Acknowledgments .............................................. 21
7 References ................................................... 22
8 Security Considerations ...................................... 23
9 Authors' Addresses ........................................... 23
Expires December 1996 [Page 24]
