rfc2613.txt

RFC 的详细文档！

   The SMON standard presents a standard MIB interface which allows for
   the control of this function.

   Note that this function can apply to devices that have no other SMON
   or RMON functionality than  copy port. The agent of such a device
   would support only the portCopyCaps and the portCopyConfig MIB
   groups, out of the whole SMON MIB.  Switch vendors are encouraged to
   implement this subset of the SMON MIB, as it would allow for standard
   port copy configuration from the same NMS application that does RMON
   or SMON.

   Port copy may cause congestion problems on the SMON device. This
   situation is more likely occur when copying from a port of higher
   speed to a port of lower speed or copy from multiple port to a single
   port.

   Particular implementations MAY chose to build protection mechanisms
   that would prevent creation of new port copy links when the capacity
   of the destination port is exceeded. The MIB allows for
   implementations to (if supported) instrument a destination drop count
   on port copy to provide NMS applications a sense of the quality of
   data presented at the destination port.

2.3.3 VLAN Monitoring

   VLAN monitoring can be accomplished by using a VLAN-based dataSource
   and/or by configuring smonVlanIdStats and/or smonPrioStats
   collections.  These functions allow VLAN-ID or user priority
   distributions per dataSource. VLAN monitoring provides a high-level
   view of total VLAN usages and relative non-unicast traffic usage as
   well as a profile of VLAN priority as defined in the 3-bit
   user_priority field.

   NOTE: priority statistics reflect what was parsed from the packet,
   not what priority, if any, was necessarily granted by the switch.





Waterman, et al.            Standards Track                     [Page 7]

RFC 2613                        SMON MIB                       June 1999


2.4  Relationship to Other MIBs

2.4.1 The RMON and RMON 2 MIBs

   The Remote Monitoring MIB (RMON) [17] provides several management
   functions that MAY be directly or indirectly applicable to switched
   networks.

   The port copy mechanisms defined by the SMON MIB allow for the
   destination ports to become a data source for any RMON statistics.
   However, an NMS application SHOULD check whether it is in the device
   capability (portCopyCap) to filter errors from a source to a
   destination port and whether this capability is enabled, in order to
   provide a correct interpretation of the copied port traffic.

   RMON host and matrix group statistics entries MAY be aggregated by
   use of the extended dataSource capability defined in SMON. RMON 2
   groups are similarly extended through the use of SMON's dataSource
   definition.

   RMON also defines a simple thresholding monitoring mechanism, event-
   logging and event-notification for any MIB instance; SMON utilizes
   the alarms and events groups from RMON without modification.  These
   groups SHOULD be implemented on SMON devices if a simple thresholding
   mechanism is desired.

   The RMON 2 usrHistory group (user-defined history collection) SHOULD
   be implemented by an SMON device if a history collection mechanism is
   desired for smonStats entries.

2.4.2 The Interfaces Group MIB

   The SMON MIB utilizes the propVirtual(53) ifType defined in the
   Interfaces Group MIB [22] to provide SMON and RMON with new
   dataSources such as VLANs and internal monitoring points. NMS
   applications SHOULD consult the SMON dataSource capabilities group
   (dataSourceCap) for a description of these virtual interfaces.

2.4.3 The Entity MIB

   The SMON MIB does not mandate Entity MIB [18] support, but allows for
   physical entities, as defined by this MIB to be defined as SMON data
   sources. For such cases, the support for the entPhysicalTable is
   required.







Waterman, et al.            Standards Track                     [Page 8]

RFC 2613                        SMON MIB                       June 1999


2.4.4 The Bridge MIB

   One of the important indicators for measuring the effectiveness of a
   switching device is the ratio between the number of forwarded frames
   and the number of dropped frames at the switch port.

   It is out of the scope of this MIB to provide instrumentation
   information relative to switching devices. However, such indication
   may be part of other MIB modules.

   For instance the Bridge MIB [23] provides such MIB objects, for the
   802.1 bridges (dot1dTpPortInFrames, dot1dTpPortInDiscards) and
   switches managed according to the 802.1 bridge model MAY provide this
   information.

2.5 Relationship with IEEE 802.1 Standards

   The SMON MIB provides simple statistics per VLAN and priority levels.
   Those two categories of statistics are important to managers of
   switched networks.  Interoperability for those features is ensured by
   the use of the IEEE 802.1 p/Q standards ([19], [20]) defined by the
   IEEE 802.1 WG. Interoperability from the SMON MIB point of view is
   ensured by referencing the IEEE definition of VLANs and priority
   levels for the SMON statistics.

3. SMON Groups

3.1 SMON ProbeCapabilities

   The SMON probeCapabilities BITS object covers the following four
   capabilities.

      - smonVlanStats(0)
        The probe supports the smonVlanStats object group.

      - smonPrioStats(1)
        The probe supports the smonPrioStats object group.

      - dataSource(2)
        The probe supports the dataSourceCaps object group.

      - portCopy(4)
        The probe supports the portCopyConfig object group.








Waterman, et al.            Standards Track                     [Page 9]

RFC 2613                        SMON MIB                       June 1999


3.2 smonVlanStats

   The smonVlanStats MIB group includes the control and statistics
   objects related to 802.1Q VLANs. Specific statistics per 802.1Q
   virtual LAN are supported. The group provides a high level view of
   total VLAN usage, and relative non-unicast traffic usage.

   It is an implementation-specific matter as to how the agent
   determines the proper default-VLAN for untagged or priority-tagged
   frames.

3.3 smonPrioStats

   The smonPrioStatsTable provides a distribution based on the
   user_priority field in the VLAN header.

   Note that this table merely reports priority as encoded in VLAN
   headers, not the priority (if any) given the frame for actual
   switching purposes.

3.4 dataSourceCaps

   The dataSourceCaps MIB group identifies all supported data sources on
   an SMON device. An NMS MAY use this table to discover the RMON and
   Copy Port attributes of each data source.

   Upon restart of the agent, the dataSourceTable, ifTable and
   entPhysicalTable are initialized for the available data sources. The
   agent MAY modify these tables as data sources become known or are
   removed (e.g. hot swap of interfaces, chassis cards or the discovery
   of VLAN usage). It is understood that dataSources representing VLANs
   may not always be instantiated immediately upon restart, but rather
   as VLAN usage is detected by the agent.  The agent SHOULD attempt to
   create dataSource and interface entries for all dataSources as soon
   as possible.

   For each dataSourceCapsEntry representing a VLAN or entPhysicalEntry,
   the agent MUST create an associated ifEntry with a ifType value of
   associated dataSourceCapsIfIndex object.

   The rationale of the above derives from the fact that according to
   [16] and [17] an RMON dataSource MUST be associated with an ifEntry.
   Specifically, the dataSourceCapsTable allows for an agent to map
   Entity MIB physical entities (e.g., switch backplanes) and entire
   VLANs to ifEntries with ifType "propVirtual(53)". This ifEntry values
   will be used as the actual values in RMON control table dataSource
   objects.  This allows for physical entities and VLANs to be treated
   as RMON data sources, and RMON functions to be applied to this type



Waterman, et al.            Standards Track                    [Page 10]

RFC 2613                        SMON MIB                       June 1999


   of data sources.

3.5 portCopyConfig

   The portCopyConfig MIB group includes the objects defined for the
   control of the port copy functionality in a device.

   The standard does not place a limit on the mode in which this copy
   function may be used:

   Mode 1 --  1:1 Copy

      Single dataSource copied to a single destination dataSource.
      Agent MAY limit configuration based on ifTypes, ifSpeeds, half-
      duplex/full-duplex, or agent resources.  In this mode the single
      instance of the portCopyDestDropEvents object refers to dropped
      frames on the portCopyDest interface.

   Mode 2 --  N:1 Copy

      Multiple dataSources copied to a single destination dataSource.
      Agent MAY limit configuration based on ifTypes, ifSpeeds, half-
      duplex/full-duplex, portCopyDest over-subscription, or agent
      resources.  In this mode all N instances of the
      portCopyDestDropEvents object SHOULD contain the same value, and
      refer to dropped frames on the portCopyDest interface.

   Mode 3 --  N:M Copy

      Multiple dataSources copied to multiple destination dataSources.
      Agent MAY limit configuration based on ifTypes, ifSpeeds, half-
      duplex/full-duplex, portCopyDest over-subscription, or agent
      resources.  Since portCopyDestDropEvents is kept per destination
      port, all instances of the portCopyDestDropEvents object
      associated with (indexed by) a given portCopyDest SHOULD have the
      same value (i.e. replicated or aliased for each instance
      associated with a given portCopyDest).

   The rows do not have an OwnerString, since multiple rows MAY be part
   of the same portCopy operation. The agent is expected to activate or
   deactivate entries one at a time, based on the rowStatus for the
   given row.  This can lead to unpredictable results in Modes 2 and 3
   in applications utilizing the portCopy target traffic, if multiple
   PDUs are used to fully configure the operation.  It is RECOMMENDED
   that an entire portCopy operation be configured in one SetRequest PDU
   if possible.





Waterman, et al.            Standards Track                    [Page 11]

RFC 2613                        SMON MIB                       June 1999


   The portCopyDest object MAY NOT reference an interface associated
   with a packet-based VLAN (smonVlanDataSource.<V>), but this
   dataSource type MAY be used as a portCopySource.

4.  Control of Remote Network Monitoring Devices

   Due to the complex nature of the available functions in these
   devices, the functions often need user configuration.  In many cases,
   the function requires parameters to be set up for a data collection
   operation.  The operation can proceed only after these parameters are
   fully set up.

   Many functional groups in this MIB have one or more tables in which
   to set up control parameters, and one or more data tables in which to
   place the results of the operation.  The control tables are typically
   read/write in nature, while the data tables are typically read-only.
   Because the parameters in the control table often describe resulting
   data in the data table, many of the parameters can be modified only
   when the control entry is not active.  Thus, the method for modifying
   these parameters is to de-activate the entry, perform the SNMP Set
   operations to modify the entry, and then re-activate the entry.
   Deleting the control entry causes the deletion of any associated data
   entries, which also gives a convenient method for reclaiming the
   resources used by the associated data.

   Some objects in this MIB provide a mechanism to execute an action on
   the remote monitoring device.  These objects MAY execute an action as
   a result of a change in the state of the object.  For those objects
   in this MIB, a request to set an object to the same value as it
   currently holds would thus cause no action to occur.

   To facilitate control by multiple managers, resources have to be
   shared among the managers.  These resources are typically the memory
   and computation resources that a function requires.

   The control mechanisms defined and used in this MIB are the same as
   those defined in the RMON MIB [17], for control functionality and
   interaction with multiple managers.













Waterman, et al.            Standards Track                    [Page 12]

RFC 2613                        SMON MIB                       June 1999


5. Definitions

   SMON-MIB DEFINITIONS ::= BEGIN

   IMPORTS
        MODULE-IDENTITY, OBJECT-TYPE, Counter32,
        Integer32, Counter64
                FROM SNMPv2-SMI
        RowStatus, TEXTUAL-CONVENTION
                FROM SNMPv2-TC
        rmon, OwnerString
                FROM RMON-MIB
        LastCreateTime, DataSource, rmonConformance, probeConfig
                FROM RMON2-MIB
        InterfaceIndex
                FROM IF-MIB
        MODULE-COMPLIANCE, OBJECT-GROUP
                FROM SNMPv2-CONF;

   switchRMON MODULE-IDENTITY
        LAST-UPDATED "9812160000Z"
        ORGANIZATION "IETF RMON MIB Working Group"
        CONTACT-INFO
        "IETF RMONMIB WG Mailing list: [e-mail]

                Rich Waterman
                Allot Networks Inc.
                Tel:  [phone]