rfc2591.txt

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

Network Working Group                                            D. Levi
Request for Comments: 2591                               Nortel Networks
Category: Standards Track                               J. Schoenwaelder
                                                         TU Braunschweig
                                                                May 1999


                   Definitions of Managed Objects for
                    Scheduling Management Operations

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 the Internet community.
   In particular, it describes a set of managed objects that are used to
   schedule management operations periodically or at specified dates and
   times.

Table of Contents

   1. Introduction ....................................................2
   2. The SNMP Management Framework....................................2
   3. Overview ........................................................3
   3.1 Periodic Schedules .............................................3
   3.2 Calendar Schedules .............................................4
   3.3 One-shot Schedules .............................................4
   3.4 Time Transitions ...............................................4
   3.5 Actions ........................................................5
   4. Definitions .....................................................5
   5. Usage Examples .................................................18
   5.1 Starting a script to ping devices every 20 minutes ............18
   5.2 Starting a script at the next Friday the 13th .................18
   5.3 Turning an interface off during weekends ......................19
   6. Security Considerations ........................................21
   7. Intellectual Property ..........................................22
   8. Acknowledgments ................................................22



Levi & Schoenwaelder        Standards Track                     [Page 1]

RFC 2591                     Scheduling MIB                     May 1999


   9. References .....................................................22
   10. Editors' Addresses ............................................24
   11. Full Copyright Statement ......................................25

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of managed objects that are used to
   schedule management operations periodically or at specified dates and
   times.

   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 [19].

2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o   An overall architecture, described in RFC 2271 [1].

   o   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].

   o   Message protocols for transferring management information. The
       first version of the SNMP message protocol is called SNMPv1 and
       described in 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 2272 [11] and RFC 2274 [12].

   o   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].

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




Levi & Schoenwaelder        Standards Track                     [Page 2]

RFC 2591                     Scheduling MIB                     May 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
   translation is possible (use of Counter64). Some machine readable
   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.

3.  Overview

   The MIB defined in this memo provides scheduling of actions
   periodically or at specified dates and times. The actions can be used
   to realize on-duty / off-duty schedules or to trigger management
   functions in a distributed management application.

   Schedules can be enabled or disabled by modifying a control object.
   This allows pre-configured schedules which are activated or de-
   activated by some other management functions.

   The term `scheduler' is used throughout this memo to refer to the
   entity which implements the scheduling MIB and which invokes the
   actions at the specified points in time.

3.1.  Periodic Schedules

   Periodic schedules are based on fixed time periods between the
   initiation of scheduled actions. Periodic schedules are defined by
   specifying the number of seconds between two initiations. The time
   needed to complete the action is usually not known by the scheduler
   and does therefore not influence the next scheduling point.

   Implementations must guarantee that action invocations will not occur
   before their next scheduled time.  However, implementations may be
   forced to delay invocations in the face of local constraints (e.g., a
   heavy load on higher-priority tasks).  An accumulation of such delays
   would result in a drift of the scheduling interval with respect to
   time, and should be avoided.

   Scheduled actions collecting statistical data should retrieve time
   stamps from the data source and not rely on the accuracy of the
   periodic scheduler in order to obtain accurate statistics.




Levi & Schoenwaelder        Standards Track                     [Page 3]

RFC 2591                     Scheduling MIB                     May 1999


3.2.  Calendar Schedules

   Calendar schedules trigger scheduled actions at specified days of the
   week and days of the month. Calendar schedules are therefore aware of
   the notion of months, days, weekdays, hours and minutes.

   It is possible to specify multiple values for each calendar item.
   This provides a mechanism for defining complex schedules.  For
   example, a schedule could be defined which triggers an action every
   15 minutes on a given weekday.

   Months, days and weekdays are specified using the objects schedMonth,
   schedDay and schedWeekDay of type BITS. Setting multiple bits to one
   in these objects causes an OR operation. For example, setting the
   bits monday(1) and friday(5) in schedWeekDay restricts the schedule
   to Mondays and Fridays.

   The bit fields for schedMonth, schedDay and schedWeekDay are combined
   using an AND operation. For example, setting the bits june(5) and
   july(6) in schedMonth and combining it with the bits monday(1) and
   friday(5) set in schedWeekDay will result in a schedule which is
   restricted to every Monday and Friday in the months June and July.
   Wildcarding of calendar items is achieved by setting all bits to one.

   It is possible to define calendar schedules that will never trigger
   an action. For example, one can define a calendar schedule which
   should trigger an action on February 31st. Schedules like this will
   simply be ignored by the scheduler.

   Finally, calendar schedules are always expressed in local time. A
   scalar, schedLocalTime is provided so that a manager can retrieve the
   notion of local time and the offset to GMT time.

3.3.  One-shot Schedules

   One-shot Schedules are similar to calendar schedules. The difference
   between a calendar schedule and a one-shot schedule is that a one-
   shot schedule will automatically disable itself once an action has
   been invoked.

3.4.  Time Transitions

   When a system's notion of time is changed for some reason,
   implementations of the Schedule MIB must schedule actions
   differently.  One example of a change to a system's notion of time is
   when a daylight savings time transition occurs.





Levi & Schoenwaelder        Standards Track                     [Page 4]

RFC 2591                     Scheduling MIB                     May 1999


   There are two possible situations when a time transition occurs.
   First, time may be set backwards, in which case particular times will
   appear to occur twice within the same day.  These are called
   'ambiguous times'.  Second, time may be set forwards, in which case
   particular times will appear to not occur within a day.  This are
   called 'nonexistent times'.

   When an action is configured in the Schedule MIB to occur at an
   ambiguous time during a time transition, the action SHALL only be
   invoked at the first occurence of the ambiguous time.  For example,
   if an action is scheduled to occur at 2:00 am, and a time transition
   occurs at 3:00 am which sets the clock back to 2:00 am, the action
   SHALL only be invoked at the first occurence of 2:00 am.

   When an action is configured in the Schedule MIB to occur at a
   nonexistent time, the action SHOULD be invoked immediately upon a
   time transition. If multiple actions are invoked in this way, they
   SHALL be invoked in the order in which they normally would be invoked
   had the time transition not occured. For example, if an action (a) is
   scheduled at 2:05 am and another action (b) at 2:10 am, then both
   actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time
   jumps forward from 2:00 am to 3:00 am.

3.5.  Actions

   Scheduled actions are modeled by SNMP set operations on local MIB
   variables. Scheduled actions described in this MIB are further
   restricted to objects of type INTEGER. This restriction does not
   limit the usefulness of the MIB.  Simple schedules such as on-duty /
   off-duty schedules for resources that have a status MIB object (e.g.
   ifAdminStatus) are possible.

   More complex actions can be realized by triggering a management
   script which is responsible for performing complex state transitions.
   A management script can also be used to perform SNMP set operations
   on remote SNMP engines.

4.  Definitions

    DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN

    IMPORTS
        MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
        Integer32, Unsigned32, Counter32, mib-2
            FROM SNMPv2-SMI

        TEXTUAL-CONVENTION,
        DateAndTime, RowStatus, StorageType, VariablePointer



Levi & Schoenwaelder        Standards Track                     [Page 5]

RFC 2591                     Scheduling MIB                     May 1999


            FROM SNMPv2-TC

        MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
            FROM SNMPv2-CONF

        SnmpAdminString
            FROM SNMP-FRAMEWORK-MIB;

    schedMIB MODULE-IDENTITY
        LAST-UPDATED "9811171800Z"
        ORGANIZATION "IETF Distributed Management Working Group"
        CONTACT-INFO
            "David B. Levi
             Nortel Networks
             4401 Great America Parkway
             Santa Clara, CA 95052-8185
             U.S.A.
             Tel: [phone]
             E-mail: [e-mail]

             Juergen Schoenwaelder
             TU Braunschweig
             Bueltenweg 74/75
             38106 Braunschweig
             Germany
             Tel: [phone]
             E-mail: [e-mail]"
        DESCRIPTION
            "This MIB module defines a MIB which provides mechanisms
             to schedule SNMP set operations periodically or at
             specific points in time."
        ::= { mib-2 63 }

    --
    -- The various groups defined within this MIB definition:
    --

    schedObjects       OBJECT IDENTIFIER ::= { schedMIB 1 }
    schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 }
    schedConformance   OBJECT IDENTIFIER ::= { schedMIB 3 }

    --
    -- Textual Conventions:
    --

    SnmpPduErrorStatus ::= TEXTUAL-CONVENTION
        STATUS       current
        DESCRIPTION



Levi & Schoenwaelder        Standards Track                     [Page 6]

RFC 2591                     Scheduling MIB                     May 1999


            "This TC enumerates the SNMPv1 and SNMPv2 PDU error status
             codes as defined in RFC 1157 and RFC 1905. It also adds a
             pseudo error status code `noResponse' which indicates a
             timeout condition."
        SYNTAX      INTEGER {
                        noResponse(-1),
                        noError(0),
                        tooBig(1),
                        noSuchName(2),