rfc1905.txt

radius服务器

Network Working Group                               SNMPv2 Working Group
Request for Comments: 1905                                       J. Case
Obsoletes: 1448                                      SNMP Research, Inc.
Category: Standards Track                                  K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                            January 1996


                          Protocol Operations
                          for Version 2 of the
              Simple Network Management Protocol (SNMPv2)

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.

1.  Introduction

   A 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
   authentication, authorization, access control, and privacy policies.

   Management stations execute management applications which monitor and
   control managed elements.  Managed elements are devices such as
   hosts, routers, terminal servers, etc., which are monitored and
   controlled via 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].






SNMPv2 Working Group        Standards Track                     [Page 1]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   The management protocol, version 2 of the Simple Network Management
   Protocol, provides for the exchange of messages which convey
   management information between the agents and the management
   stations.  The form of these messages is a message "wrapper" which
   encapsulates a Protocol Data Unit (PDU).  The form and meaning of the
   "wrapper" is determined by an administrative framework which defines
   both authentication and authorization policies.

   It is the purpose of this document, Protocol Operations for SNMPv2,
   to define the operations of the protocol with respect to the sending
   and receiving of the PDUs.

1.1.  A Note on Terminology

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

2.  Overview

2.1.  Roles of Protocol Entities

   A SNMPv2 entity may operate in a manager role or an agent role.

   A SNMPv2 entity acts in an agent role when it performs SNMPv2
   management operations in response to received SNMPv2 protocol
   messages (other than an inform notification) or when it sends trap
   notifications.

   A SNMPv2 entity acts in a manager role when it initiates SNMPv2
   management operations by the generation of SNMPv2 protocol messages
   or when it performs SNMPv2 management operations in response to
   received trap or inform notifications.

   A SNMPv2 entity may support either or both roles, as dictated by its
   implementation and configuration.  Further, a SNMPv2 entity can also
   act in the role of a proxy agent, in which it appears to be acting in
   an agent role, but satisfies management requests by acting in a
   manager role with a remote entity.

2.2.  Management Information

   The term, variable, refers to an instance of a non-aggregate object
   type defined according to the conventions set forth in the SMI [2] or
   the textual conventions based on the SMI [3].  The term, variable
   binding, normally refers to the pairing of the name of a variable and



SNMPv2 Working Group        Standards Track                     [Page 2]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   its associated value.  However, if certain kinds of exceptional
   conditions occur during processing of a retrieval request, a variable
   binding will pair a name and an indication of that exception.

   A variable-binding list is a simple list of variable bindings.

   The name of a variable is an OBJECT IDENTIFIER which is the
   concatenation of the OBJECT IDENTIFIER of the corresponding object-
   type together with an OBJECT IDENTIFIER fragment identifying the
   instance.  The OBJECT IDENTIFIER of the corresponding object-type is
   called the OBJECT IDENTIFIER prefix of the variable.

2.3.  Access to Management Information

   Three types of access to management information are provided by the
   protocol.  One type is a request-response interaction, in which a
   SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
   entity, acting in an agent role, and the latter SNMPv2 entity then
   responds to the request.  This type is used to retrieve or modify
   management information associated with the managed device.

   A second type is also a request-response interaction, in which a
   SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
   entity, also acting in a manager role, and the latter SNMPv2 entity
   then responds to the request.  This type is used to notify a SNMPv2
   entity, acting in a manager role, of management information
   associated with another SNMPv2 entity, also acting in a manager role.

   The third type of access is an unconfirmed interaction, in which a
   SNMPv2 entity, acting in an agent role, sends a unsolicited message,
   termed a trap, to a SNMPv2 entity, acting in a manager role, and no
   response is returned.  This type is used to notify a SNMPv2 entity,
   acting in a manager role, of an exceptional situation, which has
   resulted in changes to management information associated with the
   managed device.

2.4.  Retransmission of Requests

   For all types of request in this protocol, the receiver is required
   under normal circumstances, to generate and transmit a response to
   the originator of the request.  Whether or not a request should be
   retransmitted if no corresponding response is received in an
   appropriate time interval, is at the discretion of the application
   originating the request.  This will normally depend on the urgency of
   the request.  However, such an application needs to act responsibly
   in respect to the frequency and duration of re-transmissions.





SNMPv2 Working Group        Standards Track                     [Page 3]

RFC 1905             Protocol Operations for SNMPv2         January 1996


2.5.  Message Sizes

   The maximum size of a SNMPv2 message is limited to the minimum of:

(1)  the maximum message size which the destination SNMPv2 entity can
     accept; and,

(2)  the maximum message size which the source SNMPv2 entity can
     generate.

   The former may be known on a per-recipient basis; and in the absence
   of such knowledge, is indicated by transport domain used when sending
   the message.  The latter is imposed by implementation-specific local
   constraints.

   Each transport mapping for the SNMPv2 indicates the minimum message
   size which a SNMPv2 implementation must be able to produce or
   consume.  Although implementations are encouraged to support larger
   values whenever possible, a conformant implementation must never
   generate messages larger than allowed by the receiving SNMPv2 entity.

   One of the aims of the GetBulkRequest-PDU, specified in this
   protocol, is to minimize the number of protocol exchanges required to
   retrieve a large amount of management information.  As such, this PDU
   type allows a SNMPv2 entity acting in a manager role to request that
   the response be as large as possible given the constraints on message
   sizes.  These constraints include the limits on the size of messages
   which the SNMPv2 entity acting in an agent role can generate, and the
   SNMPv2 entity acting in a manager role can receive.

   However, it is possible that such maximum sized messages may be
   larger than the Path MTU of the path across the network traversed by
   the messages.  In this situation, such messages are subject to
   fragmentation.  Fragmentation is generally considered to be harmful
   [4], since among other problems, it leads to a decrease in the
   reliability of the transfer of the messages.  Thus, a SNMPv2 entity
   which sends a GetBulkRequest-PDU must take care to set its parameters
   accordingly, so as to reduce the risk of fragmentation.  In
   particular, under conditions of network stress, only small values
   should be used for max-repetitions.

2.6.  Transport Mappings

   It is important to note that the exchange of SNMPv2 messages requires
   only an unreliable datagram service, with every message being
   entirely and independently contained in a single transport datagram.
   Specific transport mappings and encoding rules are specified
   elsewhere [5].  However, the preferred mapping is the use of the User



SNMPv2 Working Group        Standards Track                     [Page 4]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   Datagram Protocol [6].

3.  Definitions

     SNMPv2-PDU DEFINITIONS ::= BEGIN

     IMPORTS
         ObjectName, ObjectSyntax, Integer32
             FROM SNMPv2-SMI;


     -- protocol data units

     PDUs ::=
         CHOICE {
             get-request
                 GetRequest-PDU,

             get-next-request
                 GetNextRequest-PDU,

             get-bulk-request
                 GetBulkRequest-PDU,

             response
                 Response-PDU,

             set-request
                 SetRequest-PDU,

             inform-request
                 InformRequest-PDU,

             snmpV2-trap
                 SNMPv2-Trap-PDU,

             report
                 Report-PDU,
         }


     -- PDUs

     GetRequest-PDU ::=
         [0]
             IMPLICIT PDU

     GetNextRequest-PDU ::=



SNMPv2 Working Group        Standards Track                     [Page 5]

RFC 1905             Protocol Operations for SNMPv2         January 1996


         [1]
             IMPLICIT PDU

     Response-PDU ::=
         [2]
             IMPLICIT PDU

     SetRequest-PDU ::=
         [3]
             IMPLICIT PDU

     -- [4] is obsolete

     GetBulkRequest-PDU ::=
         [5]
             IMPLICIT BulkPDU

     InformRequest-PDU ::=
         [6]
             IMPLICIT PDU

     SNMPv2-Trap-PDU ::=
         [7]
             IMPLICIT PDU

     --   Usage and precise semantics of Report-PDU are not presently
     --   defined.  Any SNMP administrative framework making use of
     --   this PDU must define its usage and semantics.
     Report-PDU ::=
         [8]
             IMPLICIT PDU

     max-bindings
         INTEGER ::= 2147483647

     PDU ::=
         SEQUENCE {
             request-id
                 Integer32,

             error-status            -- sometimes ignored
                 INTEGER {
                     noError(0),
                     tooBig(1),
                     noSuchName(2),   -- for proxy compatibility
                     badValue(3),     -- for proxy compatibility
                     readOnly(4),     -- for proxy compatibility
                     genErr(5),