rfc1451.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 2,125 行 · 第 1/5 页

          Network Working Group                                  J. Case
          Request for Comments: 1451                 SNMP Research, Inc.
                                                           K. McCloghrie
                                                      Hughes LAN Systems
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                              Carnegie Mellon University
                                                              April 1993


                                Manager-to-Manager
                           Management Information Base


          Status of this Memo

          This RFC specifes an IAB standards track protocol for the
          Internet community, and requests discussion and suggestions
          for improvements.  Please refer to the current edition of the
          "IAB Official Protocol Standards" for the standardization
          state and status of this protocol.  Distribution of this memo
          is unlimited.


          Table of Contents


          1 Introduction ..........................................    2
          1.1 A Note on Terminology ...............................    2
          2 Overview ..............................................    3
          2.1 A SNMPv2 Entity Acting in a Dual Role ...............    3
          2.2 Alarms, Events, and Notifications ...................    3
          2.3 Access Control ......................................    4
          3 Definitions ...........................................    6
          3.1 The Alarm Group .....................................    7
          3.1.1 Alarm-Related Notifications .......................   20
          3.2 The Event Group .....................................   21
          3.3 Conformance Information .............................   29
          3.3.1 Compliance Statements .............................   29
          3.3.2 Units of Conformance ..............................   29
          4 Acknowledgements ......................................   31
          5 References ............................................   35
          6 Security Considerations ...............................   36
          7 Authors' Addresses ....................................   36









          Case, McCloghrie, Rose & Waldbusser                   [Page 1]





          RFC 1451            Manager-to-Manager MIB          April 1993


          1.  Introduction

          A network management system contains: several (potentially
          many) nodes, each with a processing entity, termed an agent,
          which has access to management instrumentation; at least one
          management station; and, a management protocol, used to convey
          management information between the agents and management
          stations.  Operations of the protocol are carried out under an
          administrative framework which defines both authentication and
          authorization policies.

          Network management stations execute management applications
          which monitor and control network elements.  Network elements
          are devices such as hosts, routers, terminal servers, etc.,
          which are monitored and controlled through access to their
          management information.

          Management information is viewed as a collection of managed
          objects, residing in a virtual information store, termed the
          Management Information Base (MIB).  Collections of related
          objects are defined in MIB modules.  These modules are written
          using a subset of OSI's Abstract Syntax Notation One (ASN.1)
          [1], termed the Structure of Management Information (SMI) [2].

          The management protocol, version 2 of the Simple Network
          Management Protocol [3], provides for the exchange of messages
          which convey management information between the agents and the
          management stations, including between management stations.
          It is the purpose of this document to define managed objects
          which describe the behavior of a SNMPv2 entity acting in both
          a manager role and an agent role.


          1.1.  A Note on Terminology

          For the purpose of exposition, the original Internet-standard
          Network Management Framework, as described in RFCs 1155, 1157,
          and 1212, is termed the SNMP version 1 framework (SNMPv1).
          The current framework is termed the SNMP version 2 framework
          (SNMPv2).










          Case, McCloghrie, Rose & Waldbusser                   [Page 2]





          RFC 1451            Manager-to-Manager MIB          April 1993


          2.  Overview

          The purpose of this MIB is to provide the means for
          coordination between multiple management stations.  That is,
          the means by which the controlling and monitoring functions of
          network management can be distributed amongst multiple
          management stations.  Such distribution facilitates the
          scaling of network management solutions based on the SNMPv2 to
          meet the needs of very large networks, or of networks composed
          of multiple interconnected administrations. Specifically, this
          MIB provides the means for one management station to request
          management services from another management station.


          2.1.  A SNMPv2 Entity Acting in a Dual Role

          A management station providing services to other management
          station(s), is a SNMPv2 entity which acts in the dual role of
          both manager and agent; the requests for service are received
          through acting in an agent role (with respect to the managed
          objects defined in this MIB), and the requested services are
          performed through acting in a manager role.


          2.2.  Alarms, Events, and Notifications

          In this initial version, this MIB defines the concepts of
          "alarms", "events", and "notifications".  Each alarm is a
          specific condition detected through the periodic (at a
          configured sampling interval) monitoring of the value of a
          specific management information variable.  An example of an
          alarm condition is when the monitored variable falls outside a
          configured range.  Each alarm condition triggers an event, and
          each event can cause (one or more) notifications to be
          reported to other management stations using the Inform-Request
          PDU.

          Specifically, this MIB defines three MIB tables and a number
          of scalar objects.  The three tables are: the Alarm Table, the
          Event Table, and the Notification Table.










          Case, McCloghrie, Rose & Waldbusser                   [Page 3]





          RFC 1451            Manager-to-Manager MIB          April 1993


          2.3.  Access Control

          The Administrative Model for SNMPv2 document [4] includes an
          access control model, which must not be subverted by allowing
          access to management information variables via the Alarm
          table.  That is, access to a monitored variable via the Alarm
          table must be controlled according to the identity of the
          management station accessing the particular entry in the Alarm
          table.

          An entry in the Alarm table provides the means to configure
          the sampling of the value of a MIB variable in the MIB view
          associated with the specified context (which can refer to
          object resources that are either local or remote).  The
          sampling is done by (conceptually or actually) issuing a
          SNMPv2 request to retrieve the variable's value.  This request
          is authenticated and/or protected from disclosure according to
          a source party and a destination party pair which has access
          to the indicated context.

          Thus, to provide the required access control, the initial MIB
          view assigned, by convention, to parties on SNMPv2 entities
          that implement the snmpAlarmTable, must include the component:

            viewSubtree  = { snmpAlarm }
            viewStatus   = { excluded }
            viewMask     = { ''H }

          Then, the MIB view associated with the context,
          requestContext, accessible by a requesting management station,
          can be configured to include specific Alarm table entries --
          the ones associated with those contexts to which the
          requesting management station has access.

          In particular, to provide a requestContext with access to the
          sampling context sampleContext, the following family of view
          subtrees would be included for the requestContext on the
          SNMPv2 entity acting in a dual role:

               { snmpAlarmEntry WILDCARD sampleContext }

          Which would be configured in the party MIB [5] as:

            contextIdentity   = { requestContext }
            contextViewIndex  = { ViewIndex }





          Case, McCloghrie, Rose & Waldbusser                   [Page 4]





          RFC 1451            Manager-to-Manager MIB          April 1993


        viewIndex         = { ViewIndex }
        viewSubtree       = { snmpAlarmEntry 0 sampleContext }
        viewStatus        = { included }
        viewMask          = { 'FFEF'H } -- specifies wildcard for column














































          Case, McCloghrie, Rose & Waldbusser                   [Page 5]





          RFC 1451            Manager-to-Manager MIB          April 1993


          3.  Definitions

          SNMPv2-M2M-MIB DEFINITIONS ::= BEGIN

          IMPORTS
              MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
              Integer32, Counter32, snmpModules
                  FROM SNMPv2-SMI
              DisplayString, InstancePointer, RowStatus, TimeStamp
                  FROM SNMPv2-TC
              MODULE-COMPLIANCE, OBJECT-GROUP
                  FROM SNMPv2-CONF
              contextIdentity
                  FROM SNMPv2-PARTY-MIB;


          snmpM2M MODULE-IDENTITY
              LAST-UPDATED "9304010000Z"
              ORGANIZATION "IETF SNMPv2 Working Group"
              CONTACT-INFO
                      "        Steven Waldbusser

                       Postal: Carnegie Mellon University
                               4910 Forbes Ave
                               Pittsburgh, PA  15213

                          Tel: [phone]
                          Fax: [phone]

                       E-mail: [e-mail]"
              DESCRIPTION
                      "The Manager-to-Manager MIB module."
              ::= { snmpModules 2 }


          snmpM2MObjects OBJECT IDENTIFIER ::= { snmpM2M 1 }














          Case, McCloghrie, Rose & Waldbusser                   [Page 6]





          RFC 1451            Manager-to-Manager MIB          April 1993


          -- the alarm group
          --
          -- a collection of objects allowing the description and
          -- configuration of threshold alarms from a SNMPv2 entity
          -- acting in a dual role.

          snmpAlarm      OBJECT IDENTIFIER ::= { snmpM2MObjects 1 }

          -- This Alarm mechanism periodically takes statistical samples
          -- from variables available via SNMPv2 and compares them to
          -- thresholds that have been configured.  The alarm table
          -- stores configuration entries that each define a variable,
          -- polling period, and threshold parameters.  If a sample is
          -- found to cross the threshold values, an event is generated.
          -- Only variables that resolve to an ASN.1 primitive type of
          -- INTEGER (Integer32, Counter32, Gauge32, TimeTicks,
          -- Counter64, or UInteger32) may be monitored in this way.
          --
          -- This function has a hysteresis mechanism to limit the
          -- generation of events.  This mechanism generates one event
          -- as a threshold is crossed in the appropriate direction.  No
          -- more events are generated for that threshold until the
          -- opposite threshold is crossed.
          --
          -- In the case of sampling a deltaValue, an entity may
          -- implement this mechanism with more precision if it takes a
          -- delta sample twice per period, each time comparing the sum
          -- of the latest two samples to the threshold.  This allows
          -- the detection of threshold crossings that span the sampling
          -- boundary.  Note that this does not require any special
          -- configuration of the threshold value.  It is suggested that
          -- entities implement this more precise algorithm.
          --

















          Case, McCloghrie, Rose & Waldbusser                   [Page 7]





          RFC 1451            Manager-to-Manager MIB          April 1993


          snmpAlarmNextIndex OBJECT-TYPE
              SYNTAX     INTEGER (0..65535)
              MAX-ACCESS read-only
              STATUS     current
              DESCRIPTION