rfc1757.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,467 行 · 第 1/5 页

Network Working Group                                      S. Waldbusser
Request for Comments: 1757                    Carnegie Mellon University
Obsoletes: 1271                                            February 1995
Category: Standards Track


         Remote Network Monitoring Management Information Base

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.

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.

Table of Contents

   1. The Network Management Framework ......................    2
   2. Overview ..............................................    3
   2.1 Remote Network Management Goals ......................    3
   2.2 Textual Conventions ..................................    5
   2.3 Structure of MIB .....................................    5
   2.3.1 The Ethernet Statistics Group ......................    6
   2.3.2 The History Control Group ..........................    6
   2.3.3 The Ethernet History Group .........................    6
   2.3.4 The Alarm Group ....................................    6
   2.3.5 The Host Group .....................................    6
   2.3.6 The HostTopN Group .................................    7
   2.3.7 The Matrix Group ...................................    7
   2.3.8 The Filter Group ...................................    7
   2.3.9 The Packet Capture Group ...........................    7
   2.3.10 The Event Group ...................................    7
   3. Control of Remote Network Monitoring Devices ..........    7
   3.1 Resource Sharing Among Multiple Management Stations ..    8
   3.2 Row Addition Among Multiple Management Stations ......   10
   4. Conventions ...........................................   11
   5. Definitions ...........................................   11
   6. Acknowledgments .......................................   89
   7. References ............................................   89
   8. Security Considerations ...............................   90



Waldbusser                                                      [Page 1]

RFC 1757             Remote Network Monitoring MIB         February 1995


   9. Author's Address ......................................   90
   10. Appendix: Changes from RFC 1271 ......................   91

1.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      STD 16, RFC 1155 [1] which defines the SMI, the mechanisms used
      for describing and naming objects for the purpose of management.

      STD 16, RFC 1212 [2] defines a more concise description mechanism,
      which is wholly consistent with the SMI.

      STD 17, RFC 1213 [3] which defines MIB-II, the core set of managed
      objects for the Internet suite of protocols.

      STD 15, RFC 1157 [4] which defines the SNMP, the protocol used for
      network access to managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Within a given MIB module,
   objects are defined using RFC 1212's OBJECT-TYPE macro.  At a
   minimum, each object has a name, a syntax, an access-level, and an
   implementation-status.

   The name is an object identifier, an administratively assigned name,
   which specifies an object type.  The object type together with an
   object instance serves to uniquely identify a specific instantiation
   of the object.  For human convenience, we often use a textual string,
   termed the object descriptor, to also refer to the object type.

   The syntax of an object type defines the abstract data structure
   corresponding to that object type.  The ASN.1[5] language is used for
   this purpose.  However, RFC 1155 purposely restricts the ASN.1
   constructs which may be used.  These restrictions are explicitly made
   for simplicity.

   The access-level of an object type defines whether it makes "protocol
   sense" to read and/or write the value of an instance of the object
   type.  (This access-level is independent of any administrative
   authorization policy.)

   The implementation-status of an object type indicates whether the
   object is mandatory, optional, obsolete, or deprecated.



Waldbusser                                                      [Page 2]

RFC 1757             Remote Network Monitoring MIB         February 1995


2.  Overview

   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.

   While most of the objects in this document are suitable for the
   management of any type of network, there are some which are specific
   to managing Ethernet networks.  These are the objects in the
   etherStatsTable, the etherHistoryTable, and some attributes of the
   filterPktStatus and capturBufferPacketStatus objects.  The design of
   this MIB allows similar objects to be defined for other network
   types.  It is intended that future versions of this document and
   additional documents will define extensions for other network types
   such as Token Ring and FDDI.

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
                  (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



Waldbusser                                                      [Page 3]

RFC 1757             Remote Network Monitoring MIB         February 1995


                  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 recovery.  Because
                  environments with multiple management stations are
                  common, the remote network monitoring device has to
                  deal with more than own management station,
                  potentially using its resources concurrently.




Waldbusser                                                      [Page 4]

RFC 1757             Remote Network Monitoring MIB         February 1995


2.2.  Textual Conventions

   Two new data types are introduced as a textual convention in this MIB
   document.  These textual conventions enhance the readability of the
   specification and can ease comparison with other specifications if
   appropriate.  It should be noted that the introduction of the these
   textual conventions has no effect on either the syntax nor the
   semantics of any managed objects.  The use of these is merely an
   artifact of the explanatory method used.  Objects defined in terms of
   one of these methods are always encoded by means of the rules that
   define the primitive type.  Hence, no changes to the SMI or the SNMP
   are necessary to accommodate these textual conventions which are
   adopted merely for the convenience of readers and writers in pursuit
   of the elusive goal of clear, concise, and unambiguous MIB documents.

   The new data types are: OwnerString and EntryStatus.

2.3.  Structure of MIB

   The objects are arranged into the following groups:

                  - ethernet statistics

                  - history control

                  - ethernet history

                  - alarm

                  - host

                  - hostTopN

                  - matrix

                  - filter

                  - packet capture

                  - event

   These groups are the basic unit of conformance.  If a remote
   monitoring device implements a group, then it must implement all
   objects in that group.  For example, a managed agent that implements
   the host group must implement the hostControlTable, the hostTable and
   the hostTimeTable.





Waldbusser                                                      [Page 5]

RFC 1757             Remote Network Monitoring MIB         February 1995


   All groups in this MIB are optional.  Implementations of this MIB
   must also implement the system and interfaces group of MIB-II [6].
   MIB-II may also mandate the implementation of additional groups.

   These groups are defined to provide a means of assigning object
   identifiers, and to provide a method for managed agents to know which
   objects they must implement.