rfc2613.txt

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

Network Working Group                                      R. Waterman
Request for Comments: 2613                         Allot Networks Inc.
Category: Standards Track                                    B. Lahaye
                                                           Xylan Corp.
                                                          D. Romascanu
                                                   Lucent Technologies
                                                         S. Waldbusser
                                                                   INS
                                                             June 1999


     Remote Network Monitoring MIB Extensions for Switched Networks
                              Version 1.0

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing remote network
   monitoring devices in switched networks environments.

Table of Contents

   1 The Network Management Framework                             2
   2 Overview                                                     3
     2.1 Remote Network Management Goals                          3
     2.2 Switched Networks Monitoring                             5
     2.3 Mechanisms for Monitoring Switched Networks              5
         2.3.1 DataSource Objects                                 6
         2.3.2 Copy Port                                          7
         2.3.3 VLAN Monitoring                                    7
     2.4  Relationship to Other MIBs                              8
          2.4.1 The RMON and RMON 2 MIBs                          8
          2.4.2 The Interfaces Group MIB                          8
          2.4.3 The Entity MIB                                    8
          2.4.4 The Bridge MIB                                    9



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


     2.5 Relationship with IEEE 802.1 Standards                   9
   3 SMON/RMON Groups                                             9
     3.1 SMON ProbeCapabilities                                   9
     3.2 smonVlanStats                                           10
     3.3 smonPrioStats                                           10
     3.4 dataSourceCaps                                          10
     3.5 portCopyConfig                                          11
   4 Control of Remote Network Monitoring Devices                12
   5 Definitions                                                 13
   6 References                                                  39
   7 Intellectual Property                                       41
   8 Security Considerations                                     41
   9 Authors' Addresses                                          44
   A Full Copyright Statement                                    44

1. The Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   - An overall architecture, described in RFC 2571 [1].

   - Mechanisms for describing and naming objects and events for the
     purpose of management. The first version of this Structure of
     Management Information (SMI) is called SMIv1 and described in STD
     16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second
     version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC
     2579 [6] and RFC 2580 [7].

   - Message protocols for transferring management information. The
     first version of the SNMP message protocol is called SNMPv1 and
     described in STD 15, RFC 1157 [8]. A second version of the SNMP
     message protocol, which is not an Internet standards track
     protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
     1906 [10].  The third version of the message protocol is called
     SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
     [12].

   - Protocol operations for accessing management information. The first
     set of protocol operations and associated PDU formats is described
     in STD 15, RFC 1157 [8]. A second set of protocol operations and
     associated PDU formats is described in RFC 1905 [13].

   - A set of fundamental applications described in RFC 2573 [14] and
     the view-based access control mechanism described in RFC 2575 [15].






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


   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [24].

2. Overview

   This document continues the architecture created in the RMON MIB [17]
   by providing RMON analysis for switched networks (SMON).

   Remote network monitoring devices, often called monitors or probes,
   are instruments that exist for the purpose of managing a network.
   Often these remote probes are stand-alone devices and devote
   significant internal resources for the sole purpose of managing a
   network.  An organization may employ many of these devices, one per
   network segment, to manage its internet. In addition, these devices
   may be used for a network management service provider to access a
   client network, often geographically remote.

   The objects defined in this document are intended as an interface
   between an RMON agent and an RMON management application and are not
   intended for direct manipulation by humans.  While some users may
   tolerate the direct display of some of these objects, few will
   tolerate the complexity of manually manipulating objects to
   accomplish row creation.  These functions should be handled by the
   management application.

2.1 Remote Network Management Goals

   o Offline Operation

     There are sometimes conditions when a management station will not
     be in constant contact with its remote monitoring devices.  This is
     sometimes by design in an attempt to lower communications costs





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


     (especially when communicating over a WAN or dialup link), or by
     accident as network failures affect the communications between the
     management station and the probe.

     For this reason, this MIB allows a probe to be configured to
     perform diagnostics and to collect statistics continuously, even
     when communication with the management station may not be possible
     or efficient.  The probe may then attempt to notify the management
     station when an exceptional condition occurs.  Thus, even in
     circumstances where communication between management station and
     probe is not continuous, fault, performance, and configuration
     information may be continuously accumulated and communicated to the
     management station conveniently and efficiently.

   o Proactive Monitoring

     Given the resources available on the monitor, it is potentially
     helpful for it continuously to run diagnostics and to log network
     performance.  The monitor is always available at the onset of any
     failure.  It can notify the management station of the failure and
     can store historical statistical information about the failure.
     This historical information can be played back by the management
     station in an attempt to perform further diagnosis into the cause
     of the problem.

   o Problem Detection and Reporting

     The monitor can be configured to recognize conditions, most notably
     error conditions, and continuously to check for them.  When one of
     these conditions occurs, the event may be logged, and management
     stations may be notified in a number of ways.

   o Value Added Data

     Because a remote monitoring device represents a network resource
     dedicated exclusively to network management functions, and because
     it is located directly on the monitored portion of the network, the
     remote network monitoring device has the opportunity to add
     significant value to the data it collects.  For instance, by
     highlighting those hosts on the network that generate the most
     traffic or errors, the probe can give the management station
     precisely the information it needs to solve a class of problems.

   o Multiple Managers

     An organization may have multiple management stations for different
     units of the organization, for different functions (e.g.
     engineering and operations), and in an attempt to provide disaster



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


     recovery.  Because environments with multiple management stations
     are common, the remote network monitoring device has to deal with
     more than one management station, potentially using its resources
     concurrently.

2.2 Switched Networks Monitoring

   This document addresses issues related to applying "Remote
   Technology" to Switch Networks. Switches today differ from standard
   shared media protocols:

   1)   Data is not, in general, broadcast.  This MAY be caused by the
        switch architecture  or by the connection-oriented nature of the
        data. This means, therefore, that monitoring non-broadcast
        traffic needs to be considered.

   2)   Monitoring the multiple entry and exit points from a switching
        device requires a vast amount of resources - memory and CPU, and
        aggregation of the data in logical packets of information,
        determined by the application needs.

   3)   Switching incorporates logical segmentation such as Virtual LANs
        (VLANs).

   4)   Switching incorporates packet prioritization.

   5)   Data across the switch fabric can be in the form of cells. Like
        RMON, SMON is only concerned with the monitoring of packets.

   Differences such as these make monitoring difficult.  The current
   RMON and RMON 2 standards do not provide for things that are unique
   to switches or switched environments.

   In order to overcome the limitations of the existing standards, new
   monitoring mechanisms have been implemented by vendors of switching
   equipment. All these monitoring strategies are currently proprietary
   in nature.

   This document provides the framework to include different switching
   strategies and allow for monitoring operations consistent with the
   RMON framework. This MIB is limited to monitoring and control
   operations aimed at providing monitoring data for RMON probes.

2.3 Mechanisms for Monitoring Switched Networks

   The following mechanisms are used by SMON devices, for the purpose of
   monitoring switched networks.




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


2.3.1 DataSource Objects

   The RMON MIB standard [17] defines data source objects which point to
   MIB-II interfaces, identified by instances of ifIndex objects.

   The SMON MIB extends this concept and allows for other types of
   objects to be defined as data sources for RMON and/or SMON data.
   Three forms of dataSources are described:

      ifIndex.<I>

         Traditional RMON dataSources. Called 'port-based' for
         ifType.<I> not equal to 'propVirtual(53)'. <I> is the ifIndex
         value (see [22]).

      smonVlanDataSource.<V>

         A dataSource of this form refers to a 'Packet-based VLAN' and
         is called a 'VLAN-based' dataSource. <V> is the VLAN ID as
         defined by the IEEE 802.1Q standard [19]. The value is between
         1 and 4094 inclusive, and it represents an 802.1Q VLAN-ID with
         global scope within a given bridged domain, as defined by [19].

      entPhysicalEntry.<N>

         A dataSource of this form refers to a physical entity within
         the agent and is called an 'entity-based' dataSource. <N> is
         the value of the entPhysicalIndex in the entPhysicalTable (see
         [18]).

   In addition to these new dataSource types, SMON introduces a new
   group called dataSourceCapsTable to aid an NMS in discovering
   dataSource identity and attributes.

   The extended data source mechanism supported by the SMON MIB allows
   for the use of external collection points, similar to the one defined
   and supported by the RMON and RMON 2 MIBs, as well as internal
   collection points (e.g. propVirtual ifTable entry, entPhysicalEntry).
   The latter reflects either data sources which MAY be the result of
   aggregation (e.g. switch-wide) or internal channels of physical
   entities, which have the capability of being monitored by an SMON
   probe.









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


2.3.2 Copy Port

   In order to make the switching devices support RMON statistics, many
   vendors have implemented a port copy feature, allowing traffic to be
   replicated from switch port to switch port. Several levels of
   configuration are possible:

      1) 1 source port to 1 destination port
      2) N source ports to 1 destination port
      3) N source ports to M destination ports

   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.