ITF-MIB Table View

A list of interface entries.  The number of entries is given by
the value of ifNumber.
          
ALCATEL NOTE:
   SUPPORT: YES   TABLESIZE: DEP ifNumber.

A list of interface entries.  The number of entries
is given by the value of ifNumber.  This table
contains additional objects for the interface table.
          
ALCATEL NOTE:
   SUPPORT: YES   TABLESIZE: DEP ifNumber.

The table containing information on the relationships between
the multiple sub-layers of network interfaces.
In particular, it contains information on which sub-layers run
'on top of' which other sub-layers.  Each sub-layer corresponds
to a conceptual row in the ifTable.
          
ALCATEL NOTE:
   SUPPORT: YES   TABLESIZE: DEP.

This table contains one entry per interface.  It
defines objects which allow a network manager to
instruct an agent to test an interface for various
faults.  Tests for an interface are defined in the
media-specific MIB for that interface.  After invoking
a test, the object ifTestResult can be read to
determine the outcome.  If an agent can not perform
the test, ifTestResult is set to so indicate.  The
object ifTestCode can be used to provide further
test-specific or interface-specific (or even
enterprise-specific) information concerning the
outcome of the test.  Only one test can be in progress
on each interface 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 interface.
Before starting a test, a manager-station must first
obtain 'ownership' of the entry in the ifTestTable for
the interface to be tested.  This is accomplished with
the ifTestId and ifTestStatus objects as follows:
          
  try_again:
      get (ifTestId, ifTestStatus)
      while (ifTestStatus != notInUse)
          /*
           * Loop while a test is running or some other
           * manager is configuring a test.
           */
          short delay
          get (ifTestId, ifTestStatus)
      }
          
      /*
       * Is not being used right now -- let's compete
       * to see who gets it.
       */
      lock_value = ifTestId
          
      if ( set(ifTestId = lock_value, ifTestStatus = inUse,
               ifTestOwner = 'my-IP-address') == FAILURE)
          /*
           * Another manager got the ifTestEntry -- go
           * try again
           */
          goto try_again;
          
      /*
       * I have the lock
       */
      set up any test parameters.
          
      /*
       * This starts the test
       */
      set(ifTestType = test_to_run);
          
      wait for test completion by polling ifTestResult
          
      when test completes, agent sets ifTestResult
           agent also sets ifTestStatus = 'notInUse'
          
      retrieve any additional test results, and ifTestId
          
      if (ifTestId == lock_value+1) results are valid
          
A manager station first retrieves the value of the
appropriate ifTestId and ifTestStatus objects,
periodically repeating the retrieval if necessary,
until the value of ifTestStatus is 'notInUse'.  The
manager station then tries to set the same ifTestId
object to the value it just retrieved, the same
ifTestStatus object to 'inUse', and the corresponding
ifTestOwner object to a value indicating itself.  If
the set operation succeeds then the manager has
obtained ownership of the ifTestEntry, and the value of
the ifTestId 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 ifTestEntry.
          
Once ownership is obtained, any test parameters can be
setup, and then the test is initiated by setting
ifTestType.  On completion of the test, the agent sets
ifTestStatus 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 ifTestId at the same time as
retrieving the test results, and ensuring that the
results are for the desired request.
          
If ifTestType 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
ifTestStatus 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 interface 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 ifIndex value assigned
to an interface 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.
          
ALCATEL NOTE:
   SUPPORT: YES   TABLESIZE: DEP ifNumber.

This table contains an entry for each address
(broadcast, multicast, or uni-cast) for which the
system will receive packets/frames on a particular
interface, except as follows:
          
- for an interface operating in promiscuous mode,
entries are only required for those addresses for
which the system would receive frames were it not
operating in promiscuous mode.
          
- for 802.5 functional addresses, only one entry is
required, for the address which has the functional
address bit ANDed with the bit mask of all functional
addresses for which the interface will accept frames.
          
A system is normally able to use any unicast address
which corresponds to an entry in this table as a
source address.