rfc2925.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   A management application can delete an active remote ping request by
   setting the corresponding pingCtlRowStatus object to destroy(6).

   The contents of the pingCtlTable is preserved across reIPLs (Initial
   Program Loads) of its agent according the values of each of the
   pingCtlStorageType objects.

3.1.3  pingResultsTable

   An entry in the pingResultsTable is created for a corresponding
   pingCtlEntry once the test defined by this entry is started.

3.1.4  pingProbeHistoryTable

   The results of past ping probes can be stored in this table on a per
   pingCtlEntry basis.  This table is initially indexed by
   pingCtlOwnerIndex and pingCtlTestName in order for the results of a
   probe to relate to the pingCtlEntry that caused it.  The maximum
   number of entries stored in this table per pingCtlEntry is determined
   by the value of pingCtlMaxRows.

   An implementation of this MIB will remove the oldest entry in the
   pingProbeHistoryTable to allow the addition of an new entry once the
   number of rows in the pingProbeHistoryTable reaches the value
   specified by pingCtlMaxRows.  An implementation MUST start assigning
   pingProbeHistoryIndex values at 1 and wrap after exceeding the
   maximum possible value as defined by the limit of this object
   ('ffffffff'h).








White                       Standards Track                     [Page 7]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


3.2  Traceroute MIB

   The DISMAN-TRACEROUTE-MIB consists of the following components:

   o   traceRouteMaxConcurrentRequests

   o   traceRouteCtlTable

   o   traceRouteResultsTable

   o   traceRouteProbeHistoryTable

   o   traceRouteHopsTable

3.2.1  traceRouteMaxConcurrentRequests

   The object traceRouteMaxConcurrentRequests enables control of the
   maximum number of concurrent active requests that an agent
   implementation supports.  It is permissible for an agent either to
   limit the maximum upper range allowed for this object or to implement
   this object as read-only with an implementation limit expressed as
   its value.

3.2.2  traceRouteCtlTable

   A remote traceroute test is started by setting
   traceRouteCtlAdminStatus to enabled(1).  The corresponding
   traceRouteCtlEntry MUST have been created and its
   traceRouteCtlRowStatus set to active(1) prior to starting the test.
   A single SNMP PDU can be used to create and start a remote traceroute
   test.  Within the PDU, traceRouteCtlTargetAddress should be set to
   the target host's address (traceRouteCtlTargetAddressType will
   default to ipv4(1)), traceRouteCtlAdminStatus to enabled(1), and
   traceRouteCtlRowStatus to createAndGo(4).

   The first index element, traceRouteCtlOwnerIndex, is of type
   SnmpAdminString, a textual convention that allows for use of the
   SNMPv3 View-Based Access Control Model (RFC 2575 [11], VACM) and
   allows a management application to identify its entries.  The second
   index, traceRouteCtlTestName (also an SnmpAdminString), enables the
   same management application to have multiple requests outstanding.

   Traceroute has a much longer theoretical maximum time for completion
   than ping. Basically 42 hours and 30 minutes (the product of
   traceRouteCtlTimeOut, traceRouteCtlProbesPerHop, and
   traceRouteCtlMaxTtl) plus some network transit time!  Use of the
   defaults defined within an traceRouteCtlEntry yields a maximum of 4
   minutes and 30 seconds for a default traceroute operation.  Clearly



White                       Standards Track                     [Page 8]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   42 plus hours is too long to wait for a traceroute operation to
   complete.

   The maximum TTL value in effect for traceroute determines how long
   the traceroute function will keep increasing the TTL value in the
   probe it transmits hoping to reach the target host.  The function
   ends whenever the maximum TTL is exceeded or the target host is
   reached.  The object traceRouteCtlMaxFailures was created in order to
   impose a throttle for how long traceroute continues to increase the
   TTL field in a probe without receiving any kind of response
   (timeouts).  It is RECOMMENDED that agent implementations impose a
   time limit for how long it allows a traceroute operation to take
   relative to how the function is implemented.  For example, an
   implementation that can't process multiple traceroute operations at
   the same time SHOULD impose a shorter maximum allowed time period.

   A management application can delete an active remote traceroute
   request by setting the corresponding traceRouteCtlRowStatus object to
   destroy(6).

   The contents of the traceRouteCtlTable is preserved across reIPLs
   (Initial Program Loads) of its agent according to the values of each
   of the traceRouteCtlStorageType objects.

3.2.3  traceRouteResultsTable

   An entry in the traceRouteResultsTable is created upon determining
   the results of a specific traceroute operation.  Entries in this
   table relate back to the traceRouteCtlEntry that caused the
   corresponding traceroute operation to occur.  The objects
   traceRouteResultsCurHopCount and traceRouteResultsCurProbeCount can
   be examined to determine how far the current remote traceroute
   operation has reached.

3.2.4  traceRouteProbeHistoryTable

   The results of past traceroute probes can be stored in this table on
   a per traceRouteCtlEntry basis.  This table is initially indexed by
   traceRouteCtlOwnerIndex and traceRouteCtlTestName in order for the
   results of a probe to relate to the traceRouteCtlEntry that caused
   it.  The number of entries stored in this table per
   traceRouteCtlEntry is determined by the value of
   traceRouteCtlMaxRows.

   An implementation of this MIB will remove the oldest entry in the
   traceRouteProbeHistoryTable to allow the addition of an new entry
   once the number of rows in the traceRouteProbeHistoryTable reaches
   the value of traceRouteCtlMaxRows.  An implementation MUST start



White                       Standards Track                     [Page 9]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   assigning traceRouteProbeHistoryIndex values at 1 and wrap after
   exceeding the maximum possible value as defined by the limit of this
   object ('ffffffff'h).

3.2.5  traceRouteHopsTable

   The current traceroute path can be stored in this table on a per
   traceRouteCtlEntry basis.  This table is initially indexed by
   traceRouteCtlOwnerIndex and traceRouteCtlTestName in order for a
   traceroute path to relate to the traceRouteCtlEntry that caused it.
   A third index, traceRouteHopsHopIndex, enables keeping one
   traceRouteHopsEntry per traceroute hop.  Creation of
   traceRouteHopsTable entries is enabled by setting the corresponding
   traceRouteCtlCreateHopsEntries object to true(1).

3.3  Lookup MIB

   The DISMAN-NSLOOKUP-MIB consists of the following components:

   o   lookupMaxConcurrentRequests, and lookupPurgeTime

   o   lookupCtlTable

   o   lookupResultsTable

3.3.1  lookupMaxConcurrentRequests and lookupPurgeTime

   The object lookupMaxConcurrentRequests enables control of the maximum
   number of concurrent active requests that an agent implementation is
   structured to support.  It is permissible for an agent either to
   limit the maximum upper range allowed for this object or to implement
   this object as read-only with an implementation limit expressed as
   its value.

   The object lookupPurgeTime provides a method for entries in the
   lookupCtlTable and lookupResultsTable to be automatically deleted
   after the corresponding operation completes.

3.3.2  lookupCtlTable

   A remote lookup operation is initiated by performing an SNMP SET
   request on lookupCtlRowStatus.  A single SNMP PDU can be used to
   create and start a remote lookup operation.  Within the PDU,
   lookupCtlTargetAddress should be set to the entity to be resolved
   (lookupCtlTargetAddressType will default to ipv4(1)) and
   lookupCtlRowStatus to createAndGo(4).  The object lookupCtlOperStatus





White                       Standards Track                    [Page 10]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   can be examined to determine the state of an lookup operation.  A
   management application can delete an active remote lookup request by
   setting the corresponding lookupCtlRowStatus object to destroy(6).

   An lookupCtlEntry is initially indexed by lookupCtlOwnerIndex, which
   is of type SnmpAdminString, a textual convention that allows for use
   of the SNMPv3 View-Based Access Control Model (RFC 2575 [11], VACM)
   and also allows for a management application to identify its entries.
   The lookupCtlOwnerIndex portion of the index is then followed by
   lookupCtlOperationName.  The lookupCtlOperationName index enables the
   same lookupCtlOwnerIndex entity to have multiple outstanding
   requests.

   The value of lookupCtlTargetAddressType determines which lookup
   function to perform.  Specification of dns(16) as the value of this
   index implies that the gethostbyname function should be performed to
   determine the numeric addresses associated with a symbolic name via
   lookupResultsTable entries.  Use of a value of either ipv4(1) or
   ipv6(2) implies that the gethostbyaddr function should be performed
   to determine the symbolic name(s) associated with a numeric address
   at a remote host.

3.3.3  lookupResultsTable

   The lookupResultsTable is used to store the results of lookup
   operations.  The lookupResultsTable is initially indexed by the same
   index elements that the lookupCtlTable contains (lookupCtlOwnerIndex
   and lookupCtlOperationName) but has a third index element,
   lookupResultsIndex (Unsigned32 textual convention), in order to
   associate multiple results with the same lookupCtlEntry.

   Both the gethostbyname and gethostbyaddr functions typically return a
   pointer to a hostent structure after being called.  The hostent
   structure is defined as:

      struct hostent {
         char  *h_name;      /* official host name       */
         char  *h_aliases[]; /* list of other aliases    */
         int    h_addrtype;  /* host address type        */
         int    h_length;    /* length of host address   */
         char **h_addr_list; /* list of address for host */
      };

   The hostent structure is listed here in order to address the fact
   that a remote host can be multi-homed and can have multiple symbolic
   (DNS) names.  It is not intended to imply that implementations of the
   DISMAN-LOOKUP-MIB are limited to systems where the hostent structure
   is supported.



White                       Standards Track                    [Page 11]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   The gethostbyaddr function is called with a host address as its
   parameter and is used primarily to determine a symbolic name to
   associate with the host address.  Entries in the lookupResultsTable
   MUST be made for each host name returned.  The official host name
   MUST be assigned a lookupResultsIndex of 1.

   The gethostbyname function is called with a symbolic host name and is
   used primarily to retrieve a host address.  Normally, the first
   h_addr_list host address is considered to be the primary address and
   as such is associated with the symbolic name passed on the call.

   Entries MUST be stored in the lookupResultsTable in the order that
   they are retrieved.  Values assigned to lookupResultsIndex MUST start
   at 1 and increase in order.

   An implementation SHOULD NOT retain SNMP-created entries in the
   lookupTable across reIPLs (Initial Program Loads) of its agent, since
   management applications need to see consistent behavior with respect
   to the persistence of the table entries that they create.

4.0  Definitions

4.1  DISMAN-PING-MIB

DISMAN-PING-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Integer32,
    Unsigned32, mib-2,
    NOTIFICATION-TYPE, OBJECT-IDENTITY
        FROM SNMPv2-SMI                  -- RFC2578
    TEXTUAL-CONVENTION, RowStatus,
    StorageType, DateAndTime, TruthValue
        FROM SNMPv2-TC                   -- RFC2579
    MODULE-COMPLIANCE, OBJECT-GROUP,
    NOTIFICATION-GROUP
        FROM SNMPv2-CONF                 -- RFC2580
    InterfaceIndexOrZero                 -- RFC2863
        FROM IF-MIB
    SnmpAdminString
        FROM SNMP-FRAMEWORK-MIB          -- RFC2571
    InetAddressType, InetAddress
        FROM INET-ADDRESS-MIB;           -- RFC2851

 pingMIB MODULE-IDENTITY
    LAST-UPDATED "200009210000Z"         -- 21 September 2000
    ORGANIZATION "IETF Distributed Management Working Group"
    CONTACT-INFO



White                       Standards Track                    [Page 12]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


        "Kenneth White

        International Business Machines Corporation
        Network Computing Software Division
        Research Triangle Park, NC, USA

        E-mail: [e-mail]"
    DESCRIPTION
        "The Ping MIB (DISMAN-PING-MIB) provides the capability of
        controlling the use of the ping function at a remote
        host."

     --  Revision history

     REVISION     "200009210000Z"         -- 21 September 2000
     DESCRIPTION
         "Initial version, published as RFC 2925."

    ::= { mib-2 80 }

 -- Textual Conventions

  OperationResponseStatus ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "Used to report the result of an operation:

         responseReceived(1) - Operation completes successfully.
         unknown(2) - Operation failed due to unknown error.
         internalError(3) - An implementation detected an error
              in its own processing that caused an operation
              to fail.
         requestTimedOut(4) - Operation failed to receive a
              valid reply within the time limit imposed on it.