[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06                                          
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]