Definitions of Managed Objects for
                      System and Interface Testing

                           December 24, 1996


                   <draft-ietf-ifmib-testmib-02.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).













INTERNET-DRAFT         System/Interface Test MIB           December 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 June 1997                                         [Page 2]


INTERNET-DRAFT         System/Interface Test MIB           December 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 June 1997                                         [Page 3]


INTERNET-DRAFT         System/Interface Test MIB           December 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 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.


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 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 June 1997                                         [Page 4]


INTERNET-DRAFT         System/Interface Test MIB           December 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 combinations of the above.









Expires June 1997                                         [Page 5]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


   This MIB module chooses for the index testId, which is an integer
   identifier for an invocation of a test. This addresses the 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.


3.6.  Determining Agent Test Capabilities

   The testTable will only have entries for those entities represented
   by this agent that support tests. No capability has been defined to
   list the tests that an entity is capable of. However, if an entity is
   only capable of one test, then the testType columnar object for that
   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 June 1997                                         [Page 6]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


4.  Definitions

     TEST-MIB DEFINITIONS ::= BEGIN

     IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, TimeTicks, Unsigned32,
       experimental, NOTIFICATION-TYPE, mib-2
            FROM SNMPv2-SMI
       TestAndIncr, AutonomousType, RowPointer
            FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
            FROM SNMPv2-CONF
       OwnerString
            FROM IF-MIB
       ;

     testMIB MODULE-IDENTITY
          LAST-UPDATED "9611251200Z" -- November 25, 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."
     -- ********  NOTE TO THE RFC EDITOR  **************





Expires June 1997                                         [Page 7]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


     -- 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 }

     --    The Test Table

     testTable   OBJECT-TYPE
         SYNTAX      SEQUENCE OF TestEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
                 "This table contains one entry per entity that supports
                 testing.  It defines objects which allow a network
                 manager to instruct an agent to test an entity for
                 various faults.  Tests for an entity are defined in the
                 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 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 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)
                 }





Expires June 1997                                         [Page 8]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


                 /*
                  * 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

                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





Expires June 1997                                         [Page 9]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


                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 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
                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 1 }

   testEntry OBJECT-TYPE





Expires June 1997                                        [Page 10]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


       SYNTAX       TestEntry
       MAX-ACCESS   not-accessible
       STATUS       current
       DESCRIPTION
               "An entry containing objects for invoking tests on an
               entity. There is one testEntry for every entity associated
               with the agent that supports testing."
       INDEX  { testIndex }
       ::= { testTable 1 }

   TestEntry ::=
       SEQUENCE {
           testIndex        Unsigned32,
           testTarget       RowPointer,
           testId           TestAndIncr,
           testStatus       INTEGER,
           testType         AutonomousType,
           testResult       INTEGER,
           testOwner        OwnerString
       }

   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-write
      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'."
     ::= { testEntry 2 }

 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 entity identified by the index of





Expires June 1997                                        [Page 11]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


             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.

             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 3 }

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 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 'notInUse(1)'."
    ::= { testEntry 4 }

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





Expires June 1997                                        [Page 12]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


            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
            test types that can be performed on this entity is
            returned."
    ::= { 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
                     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 6 }

testOwner      OBJECT-TYPE
    SYNTAX       OwnerString
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION
            "The manager which currently has the 'ownership'
            required to invoke a test on this entity."
    ::= { testEntry 7 }


-- Log size

testLogMaxSize OBJECT-TYPE
    SYNTAX        Unsigned32 (10..4294967295)
    MAX-ACCESS    read-write
    STATUS        current
    DESCRIPTION
            "The maximum number entries in the testLogTable.  When the





Expires June 1997                                        [Page 13]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


            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 }



-- 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            Unsigned32,
        testLogType             AutonomousType,
        testLogCompletionTime   TimeTicks,
        testLogSummary          INTEGER,
        testLogCode             OBJECT IDENTIFIER,
        testLogOwner            OwnerString,
        testLogTestIndex        Unsigned32
        }

testLogIndex OBJECT-TYPE
    SYNTAX        Unsigned32
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
            "An integer index that uniquely identifies the entry in the
            log. This is the value of testId for the completed test."
    ::= { testLogEntry 1 }





Expires June 1997                                        [Page 14]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


testLogType OBJECT-TYPE
    SYNTAX        AutonomousType
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
            "The type of test that has completed."
    ::= { 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 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."
    ::= { testLogEntry 5 }





Expires June 1997                                        [Page 15]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


testLogOwner OBJECT-TYPE
    SYNTAX         OwnerString
    MAX-ACCESS     read-only
    STATUS         current
    DESCRIPTION
            "The name of the manager that owned the test."
    ::= { testLogEntry 6 }

testLogTestIndex OBJECT-TYPE
    SYNTAX         Unsigned32
    MAX-ACCESS     read-only
    STATUS         current
    DESCRIPTION
            "The value of testIndex for this test."
    ::= { testLogEntry 7 }

-- Notifications

testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 }

testComplete NOTIFICATION-TYPE
    OBJECTS {
        testLogType,
        testLogSummary,
        testLogCode,
        testLogOwner,
        testLogTestIndex
    }
    STATUS current
    DESCRIPTION
            "A testComplete trap signifies that a test has completed for
            a particular 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 }





Expires June 1997                                        [Page 16]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


-- 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      testLogMaxSize
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

        ::= { testMIBCompliances 1 }


-- Units of Conformance


testMIBGroup     OBJECT-GROUP
     OBJECTS {
        testTarget,
        testId,
        testStatus,
        testType,
        testResult,
        testOwner,
        testLogType,
        testLogMaxSize,
        testLogCompletionTime,
        testLogSummary,
        testLogCode,
        testLogOwner,
        testLogTestIndex
     }
     STATUS    current
     DESCRIPTION
       "A collection of objects providing a generic
        test capability."
   ::= { testMIBGroups 1 }

testNotificationGroup NOTIFICATION-GROUP
    NOTIFICATIONS {





Expires June 1997                                        [Page 17]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


        testComplete
    }
    STATUS      current
    DESCRIPTION
       "The notifications used to indicate test completion."
   ::= { testMIBGroups 2 }

END











































Expires June 1997                                        [Page 18]


INTERNET-DRAFT         System/Interface Test MIB           December 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] and that, for convenience, the
   agent uses the value of entPhysicalIndex for testIndex. Note that
   this is just a convenience for an agent that supports both the Entity
   MIB and the Test MIB and is not a requirement.

   A router containing two slots.  Each slot contains a 3 port
   router/bridge module. Each port is also 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





Expires June 1997                                        [Page 19]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


         entPhysicalDescr.6 ==             "Acme Router Ethernet Port 2"
         entPhysicalVendorType.6  ==       acmeProducts.portTypes.2
         entPhysicalContainedIn.6 ==       4
         entPhysicalClass.6 ==             port(10)
         entPhysicalParentRelPos.6 ==      2

         entPhysicalDescr.7 ==             "Acme Router Ethernet 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


     Entities Supporting Tests -- testTable:
         testTarget.4 ==   entPhysicalIndex.4
         testTarget.5 ==   ifIndex.17
         testTarget.6 ==   ifIndex.18
         testTarget.7 ==   ifIndex.19
         testTarget.8 ==   entPhysicalIndex.8
         testTarget.9 ==   ifIndex.3
         testTarget.10 ==  ifIndex.4
         testTarget.11 ==  ifIndex.5





Expires June 1997                                        [Page 20]


INTERNET-DRAFT         System/Interface Test MIB           December 1996





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 testIndex of the
   port is 7. The Ethernet-like Interfaces MIB [6], defines an OBJECT
   IDENTIFIER for the dot3TestLoopBack.










































Expires June 1997                                        [Page 21]


INTERNET-DRAFT         System/Interface Test MIB           December 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 June 1997                                        [Page 22]


INTERNET-DRAFT         System/Interface Test MIB           December 1996


5.2.  System Test

   A system test is the same as an interface test from the perspective
   of the test table. 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:

       James Watt (Newbridge)
       Dave Fowler (Newbridge)
       Steven Buchko (Newbridge)
       Milt Rosslinsky (ACC)










Expires June 1997                                        [Page 23]


INTERNET-DRAFT         System/Interface Test MIB           December 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", 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 June 1997                                        [Page 24]


INTERNET-DRAFT         System/Interface Test MIB           December 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 June 1997                                        [Page 25]


INTERNET-DRAFT         System/Interface Test MIB           December 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 ...............................................   19
   5.1 Interface Test .............................................   21
   5.2 System Test ................................................   23
   6 Acknowledgments ..............................................   23
   7 References ...................................................   24
   8 Security Considerations ......................................   25
   9 Authors' Addresses ...........................................   25






























Expires June 1997                                        [Page 26]