php-5.2.1-Win32.zip

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