RMON-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
    NOTIFICATION-TYPE, mib-2, Counter32,
    Integer32, TimeTicks                   FROM SNMPv2-SMI

    TEXTUAL-CONVENTION, DisplayString      FROM SNMPv2-TC

    MODULE-COMPLIANCE, OBJECT-GROUP,
    NOTIFICATION-GROUP                     FROM SNMPv2-CONF;

– Remote Network Monitoring MIB

rmonMibModule MODULE-IDENTITY

LAST-UPDATED "200005110000Z"  -- 11 May, 2000
ORGANIZATION "IETF RMON MIB Working Group"
CONTACT-INFO
    "Steve Waldbusser
    Phone: +1-650-948-6500
    Fax:   +1-650-745-0671
    Email: waldbusser@nextbeacon.com"
DESCRIPTION
    "Remote network monitoring devices, often called
    monitors or probes, are instruments that exist for
    the purpose of managing a network. This MIB defines
    objects for managing remote network monitoring devices."

REVISION "200005110000Z"    -- 11 May, 2000
DESCRIPTION
    "Reformatted into SMIv2 format.

    This version published as RFC 2819."

REVISION "199502010000Z" -- 1 Feb, 1995
DESCRIPTION
    "Bug fixes, clarifications and minor changes based on
    implementation experience, published as RFC1757 [18].

    Two changes were made to object definitions:

    1) A new status bit has been defined for the
    captureBufferPacketStatus object, indicating that the
    packet order within the capture buffer may not be identical to
    the packet order as received off the wire.  This bit may only

    be used for packets transmitted by the probe.  Older NMS
    applications can safely ignore this status bit, which might be
    used by newer agents.

    2) The packetMatch trap has been removed.  This trap was never
    actually 'approved' and was not added to this document along
    with the risingAlarm and fallingAlarm traps. The packetMatch
    trap could not be throttled, which could cause disruption of
    normal network traffic under some circumstances. An NMS should
    configure a risingAlarm threshold on the appropriate
    channelMatches instance if a trap is desired for a packetMatch
    event. Note that logging of packetMatch events is still
    supported--only trap generation for such events has been
    removed.

    In addition, several clarifications to individual object
    definitions have been added to assist agent and NMS
    implementors:

    - global definition of 'good packets' and 'bad packets'

    - more detailed text governing conceptual row creation and
      modification

    - instructions for probes relating to interface changes and
      disruptions

    - clarification of some ethernet counter definitions

    - recommended formula for calculating network utilization

    - clarification of channel and captureBuffer behavior for some
      unusual conditions

    - examples of proper instance naming for each table"

REVISION "199111010000Z"    -- 1 Nov, 1991
DESCRIPTION
    "The original version of this MIB, published as RFC1271."
::= { rmonConformance 8 }

rmon    OBJECT IDENTIFIER ::= { mib-2 16 }

-- textual conventions

OwnerString ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
    "This data type is used to model an administratively
    assigned name of the owner of a resource. Implementations
    must accept values composed of well-formed NVT ASCII
    sequences. In addition, implementations should accept
    values composed of well-formed UTF-8 sequences.

    It is suggested that this name contain one or more of
    the following: IP address, management station name,
    network manager's name, location, or phone number.
    In some cases the agent itself will be the owner of
    an entry.  In these cases, this string shall be set
    to a string starting with 'monitor'.

    SNMP access control is articulated entirely in terms
    of the contents of MIB views; access to a particular
    SNMP object instance depends only upon its presence
    or absence in a particular MIB view and never upon
    its value or the value of related object instances.
    Thus, objects of this type afford resolution of
    resource contention only among cooperating
    managers; they realize no access control function
    with respect to uncooperative parties."
SYNTAX OCTET STRING (SIZE (0..127))

EntryStatus ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
    "The status of a table entry.

    Setting this object to the value invalid(4) has the
    effect of invalidating the corresponding entry.
    That is, it effectively disassociates the mapping
    identified with said entry.
    It is an implementation-specific matter as to whether
    the agent removes an invalidated entry from the table.
    Accordingly, management stations must be prepared to
    receive tabular information from agents that corresponds
    to entries currently not in use.  Proper
    interpretation of such entries requires examination
    of the relevant EntryStatus object.

    An existing instance of this object cannot be set to
    createRequest(2).  This object may only be set to
    createRequest(2) when this instance is created.  When
    this object is created, the agent may wish to create
    supplemental object instances with default values
    to complete a conceptual row in this table.  Because the

    creation of these default objects is entirely at the option
    of the agent, the manager must not assume that any will be
    created, but may make use of any that are created.
    Immediately after completing the create operation, the agent
    must set this object to underCreation(3).

    When in the underCreation(3) state, an entry is allowed to
    exist in a possibly incomplete, possibly inconsistent state,
    usually to allow it to be modified in multiple PDUs.  When in
    this state, an entry is not fully active.
    Entries shall exist in the underCreation(3) state until
    the management station is finished configuring the entry
    and sets this object to valid(1) or aborts, setting this
    object to invalid(4).  If the agent determines that an
    entry has been in the underCreation(3) state for an
    abnormally long time, it may decide that the management
    station has crashed.  If the agent makes this decision,
    it may set this object to invalid(4) to reclaim the
    entry.  A prudent agent will understand that the
    management station may need to wait for human input
    and will allow for that possibility in its
    determination of this abnormally long period.

    An entry in the valid(1) state is fully configured and
    consistent and fully represents the configuration or
    operation such a row is intended to represent.  For
    example, it could be a statistical function that is
    configured and active, or a filter that is available
    in the list of filters processed by the packet capture
    process.

    A manager is restricted to changing the state of an entry in
    the following ways:

         To:       valid  createRequest  underCreation  invalid
    From:
    valid             OK             NO             OK       OK
    createRequest    N/A            N/A            N/A      N/A
    underCreation     OK             NO             OK       OK
    invalid           NO             NO             NO       OK
    nonExistent       NO             OK             NO       OK

    In the table above, it is not applicable to move the state
    from the createRequest state to any other state because the
    manager will never find the variable in that state.  The
    nonExistent state is not a value of the enumeration, rather
    it means that the entryStatus variable does not exist at all.

    An agent may allow an entryStatus variable to change state in
    additional ways, so long as the semantics of the states are
    followed.  This allowance is made to ease the implementation of
    the agent and is made despite the fact that managers should
    never exercise these additional state transitions."
SYNTAX INTEGER {
           valid(1),
           createRequest(2),
           underCreation(3),
           invalid(4)
       }

statistics        OBJECT IDENTIFIER ::= { rmon 1 }
history           OBJECT IDENTIFIER ::= { rmon 2 }
alarm             OBJECT IDENTIFIER ::= { rmon 3 }
hosts             OBJECT IDENTIFIER ::= { rmon 4 }
hostTopN          OBJECT IDENTIFIER ::= { rmon 5 }
matrix            OBJECT IDENTIFIER ::= { rmon 6 }
filter            OBJECT IDENTIFIER ::= { rmon 7 }
capture           OBJECT IDENTIFIER ::= { rmon 8 }
event             OBJECT IDENTIFIER ::= { rmon 9 }
rmonConformance   OBJECT IDENTIFIER ::= { rmon 20 }

– The Ethernet Statistics Group