Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3411

An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

Pages: 64
Internet Standard: 62
STD 62 is also:  3412341334143415341634173418
Obsoletes:  2571
Updated by:  53435590
Part 2 of 3 – Pages 16 to 39
First   Prev   Next

Top   ToC   RFC3411 - Page 16   prevText

3. Elements of the Architecture

This section describes the various elements of the architecture and how they are named. There are three kinds of naming: 1) the naming of entities, 2) the naming of identities, and 3) the naming of management information.
Top   ToC   RFC3411 - Page 17
   This architecture also defines some names for other constructs that
   are used in the documentation.

3.1. The Naming of Entities

An SNMP entity is an implementation of this architecture. Each such SNMP entity consists of an SNMP engine and one or more associated applications. The following figure shows details about an SNMP entity and the components within it. +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
Top   ToC   RFC3411 - Page 18

3.1.1. SNMP engine

An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. There is a one-to-one association between an SNMP engine and the SNMP entity which contains it. The engine contains: 1) a Dispatcher, 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem.
3.1.1.1. snmpEngineID
Within an administrative domain, an snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one-to- one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within that administrative domain. Note that it is possible for SNMP entities in different administrative domains to have the same value for snmpEngineID. Federation of administrative domains may necessitate assignment of new values.
3.1.1.2. Dispatcher
There is only one Dispatcher in an SNMP engine. It allows for concurrent support of multiple versions of SNMP messages in the SNMP engine. It does so by: - sending and receiving SNMP messages to/from the network, - determining the version of an SNMP message and interacting with the corresponding Message Processing Model, - providing an abstract interface to SNMP applications for delivery of a PDU to an application. - providing an abstract interface for SNMP applications that allows them to send a PDU to a remote SNMP entity.
Top   ToC   RFC3411 - Page 19
3.1.1.3. Message Processing Subsystem
The Message Processing Subsystem is responsible for preparing messages for sending, and extracting data from received messages. The Message Processing Subsystem potentially contains multiple Message Processing Models as shown in the next figure. * One or more Message Processing Models may be present. +------------------------------------------------------------------+ | | | Message Processing Subsystem | | | | +------------+ +------------+ +------------+ +------------+ | | | * | | * | | * | | * | | | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | | | Message | | Message | | Message | | Message | | | | Processing | | Processing | | Processing | | Processing | | | | Model | | Model | | Model | | Model | | | | | | | | | | | | | +------------+ +------------+ +------------+ +------------+ | | | +------------------------------------------------------------------+
3.1.1.3.1. Message Processing Model
Each Message Processing Model defines the format of a particular version of an SNMP message and coordinates the preparation and extraction of each such version-specific message format.
Top   ToC   RFC3411 - Page 20
3.1.1.4. Security Subsystem
The Security Subsystem provides security services such as the authentication and privacy of messages and potentially contains multiple Security Models as shown in the following figure * One or more Security Models may be present. +------------------------------------------------------------------+ | | | Security Subsystem | | | | +----------------+ +-----------------+ +-------------------+ | | | * | | * | | * | | | | User-Based | | Other | | Other | | | | Security | | Security | | Security | | | | Model | | Model | | Model | | | | | | | | | | | +----------------+ +-----------------+ +-------------------+ | | | +------------------------------------------------------------------+
3.1.1.4.1. Security Model
A Security Model specifies the threats against which it protects, the goals of its services, and the security protocols used to provide security services such as authentication and privacy.
3.1.1.4.2. Security Protocol
A Security Protocol specifies the mechanisms, procedures, and MIB objects used to provide a security service such as authentication or privacy.
Top   ToC   RFC3411 - Page 21

3.1.2. Access Control Subsystem

The Access Control Subsystem provides authorization services by means of one or more (*) Access Control Models. +------------------------------------------------------------------+ | | | Access Control Subsystem | | | | +---------------+ +-----------------+ +------------------+ | | | * | | * | | * | | | | View-Based | | Other | | Other | | | | Access | | Access | | Access | | | | Control | | Control | | Control | | | | Model | | Model | | Model | | | | | | | | | | | +---------------+ +-----------------+ +------------------+ | | | +------------------------------------------------------------------+
3.1.2.1. Access Control Model
An Access Control Model defines a particular access decision function in order to support decisions regarding access rights.

3.1.3. Applications

There are several types of applications, including: - command generators, which monitor and manipulate management data, - command responders, which provide access to management data, - notification originators, which initiate asynchronous messages, - notification receivers, which process asynchronous messages, and - proxy forwarders, which forward messages between entities. These applications make use of the services provided by the SNMP engine.
Top   ToC   RFC3411 - Page 22
3.1.3.1. SNMP Manager
An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager. (traditional SNMP manager) +-------------------------------------------------------------------+ | +--------------+ +--------------+ +--------------+ SNMP entity | | | NOTIFICATION | | NOTIFICATION | | COMMAND | | | | ORIGINATOR | | RECEIVER | | GENERATOR | | | | applications | | applications | | applications | | | +--------------+ +--------------+ +--------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------+--------+-----------------+ | | ^ | | | +---------------------+ +----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | | | | | | +------------+ | | | Other | | | | | | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +------------+ | | | | Dispatcher <--------->+ | | | | | | | | | +------------+ | | +------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | Transport | | | +------------+ | | | Security | | | | | Mapping | | | +------------+ | | | Model | | | | | (e.g., RFC 3417) | | +->| otherMP * |<--->| +------------+ | | | +-------------------+ | +------------+ | | | | | ^ +---------------------+ +----------------+ | | | | | v | +-------------------------------------------------------------------+ +-----+ +-----+ +-------+ | UDP | | IPX | . . . | other | +-----+ +-----+ +-------+ ^ ^ ^ | | | * One or more models may be present. v v v +------------------------------+ | Network | +------------------------------+
Top   ToC   RFC3411 - Page 23
3.1.3.2. SNMP Agent
An SNMP entity containing one or more command responder and/or notification originator applications (along with their associated SNMP engine) has traditionally been called an SNMP agent.
Top   ToC   RFC3411 - Page 24
   * One or more models may be present.

   +------------------------------+
   |           Network            |
   +------------------------------+
      ^       ^              ^
      |       |              |
      v       v              v
   +-----+ +-----+       +-------+
   | UDP | | IPX | . . . | other |
   +-----+ +-----+       +-------+              (traditional SNMP agent)
   +-------------------------------------------------------------------+
   |              ^                                                    |
   |              |        +---------------------+  +----------------+ |
   |              |        | Message Processing  |  | Security       | |
   | Dispatcher   v        | Subsystem           |  | Subsystem      | |
   | +-------------------+ |     +------------+  |  |                | |
   | | Transport         | |  +->| v1MP     * |<--->| +------------+ | |
   | | Mapping           | |  |  +------------+  |  | | Other      | | |
   | | (e.g., RFC 3417)  | |  |  +------------+  |  | | Security   | | |
   | |                   | |  +->| v2cMP    * |<--->| | Model      | | |
   | | Message           | |  |  +------------+  |  | +------------+ | |
   | | Dispatcher  <--------->|  +------------+  |  | +------------+ | |
   | |                   | |  +->| v3MP     * |<--->| | User-based | | |
   | |                   | |  |  +------------+  |  | | Security   | | |
   | | PDU Dispatcher    | |  |  +------------+  |  | | Model      | | |
   | +-------------------+ |  +->| otherMP  * |<--->| +------------+ | |
   |              ^        |     +------------+  |  |                | |
   |              |        +---------------------+  +----------------+ |
   |              v                                                    |
   |      +-------+-------------------------+---------------+          |
   |      ^                                 ^               ^          |
   |      |                                 |               |          |
   |      v                                 v               v          |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   | |   COMMAND   |   | ACCESS  |   | NOTIFICATION |  |    PROXY    | |
   | |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |
   | | application |   |         |   | applications |  | application | |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   |      ^                                 ^                          |
   |      |                                 |                          |
   |      v                                 v                          |
   | +----------------------------------------------+                  |
   | |             MIB instrumentation              |      SNMP entity |
   +-------------------------------------------------------------------+
Top   ToC   RFC3411 - Page 25

3.2. The Naming of Identities

principal ^ | | +----------------------------|-------------+ | SNMP engine v | | +--------------+ | | | | | | +-----------------| securityName |---+ | | | Security Model | | | | | | +--------------+ | | | | ^ | | | | | | | | | v | | | | +------------------------------+ | | | | | | | | | | | Model | | | | | | Dependent | | | | | | Security ID | | | | | | | | | | | +------------------------------+ | | | | ^ | | | | | | | | +-------------------------|----------+ | | | | | | | +----------------------------|-------------+ | v network

3.2.1. Principal

A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and combinations thereof.

3.2.2. securityName

A securityName is a human readable string representing a principal. It has a model-independent format, and can be used outside a particular Security Model.
Top   ToC   RFC3411 - Page 26

3.2.3. Model-dependent security ID

A model-dependent security ID is the model-specific representation of a securityName within a particular Security Model. Model-dependent security IDs may or may not be human readable, and have a model-dependent syntax. Examples include community names, and user names. The transformation of model-dependent security IDs into securityNames and vice versa is the responsibility of the relevant Security Model.

3.3. The Naming of Management Information

Management information resides at an SNMP entity where a Command Responder Application has local access to potentially multiple contexts. This application uses a contextEngineID equal to the snmpEngineID of its associated SNMP engine.
Top   ToC   RFC3411 - Page 27
   +-----------------------------------------------------------------+
   |  SNMP entity (identified by snmpEngineID, for example:          |
   |  '800002b804616263'H (enterpise 696, string "abc")              |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  | SNMP engine (identified by snmpEngineID)                   | |
   |  |                                                            | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  | |             | |            | |           | |           | | |
   |  | | Dispatcher  | | Message    | | Security  | | Access    | | |
   |  | |             | | Processing | | Subsystem | | Control   | | |
   |  | |             | | Subsystem  | |           | | Subsystem | | |
   |  | |             | |            | |           | |           | | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  |                                                            | |
   |  +------------------------------------------------------------+ |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  |  Command Responder Application                             | |
   |  |  (contextEngineID, example: '800002b804616263'H)           | |
   |  |                                                            | |
   |  |  example contextNames:                                     | |
   |  |                                                            | |
   |  |  "bridge1"          "bridge2"            "" (default)      | |
   |  |  ---------          ---------            ------------      | |
   |  |      |                  |                   |              | |
   |  +------|------------------|-------------------|--------------+ |
   |         |                  |                   |                |
   |  +------|------------------|-------------------|--------------+ |
   |  |  MIB | instrumentation  |                   |              | |
   |  |  +---v------------+ +---v------------+ +----v-----------+  | |
   |  |  | context        | | context        | | context        |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | | bridge MIB | | | | bridge MIB | | | | some  MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | | | other MIB  | |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   +-----------------------------------------------------------------+
Top   ToC   RFC3411 - Page 28

3.3.1. An SNMP Context

An SNMP context, or just "context" for short, is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts. Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within a management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices, but a context is always defined as a subset of a single SNMP entity. Thus, in order to identify an individual item of management information within the management domain, its contextName and contextEngineID must be identified in addition to its object type and its instance. For example, the managed object type ifDescr [RFC2863], is defined as the description of a network interface. To identify the description of device-X's first network interface, four pieces of information are needed: the snmpEngineID of the SNMP entity which provides access to the management information at device-X, the contextName (device-X), the managed object type (ifDescr), and the instance ("1"). Each context has (at least) one unique identification within the management domain. The same item of management information can exist in multiple contexts. An item of management information may have multiple unique identifications. This occurs when an item of management information exists in multiple contexts, and this also occurs when a context has multiple unique identifications. The combination of a contextEngineID and a contextName unambiguously identifies a context within an administrative domain; note that there may be multiple unique combinations of contextEngineID and contextName that unambiguously identify the same context.

3.3.2. contextEngineID

Within an administrative domain, a contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.
Top   ToC   RFC3411 - Page 29

3.3.3. contextName

A contextName is used to name a context. Each contextName MUST be unique within an SNMP entity.

3.3.4. scopedPDU

A scopedPDU is a block of data containing a contextEngineID, a contextName, and a PDU. The PDU is an SNMP Protocol Data Unit containing information named in the context which is unambiguously identified within an administrative domain by the combination of the contextEngineID and the contextName. See, for example, RFC 3416 for more information about SNMP PDUs.

3.4. Other Constructs

3.4.1. maxSizeResponseScopedPDU

The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that a PDU's sender would be willing to accept. Note that the size of a scopedPDU does not include the size of the SNMP message header.

3.4.2. Local Configuration Datastore

The subsystems, models, and applications within an SNMP entity may need to retain their own sets of configuration information. Portions of the configuration information may be accessible as managed objects. The collection of these sets of information is referred to as an entity's Local Configuration Datastore (LCD).

3.4.3. securityLevel

This architecture recognizes three levels of security: - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv)
Top   ToC   RFC3411 - Page 30
   These three values are ordered such that noAuthNoPriv is less than
   authNoPriv and authNoPriv is less than authPriv.

   Every message has an associated securityLevel.  All Subsystems
   (Message Processing, Security, Access Control) and applications are
   REQUIRED to either supply a value of securityLevel or to abide by the
   supplied value of securityLevel while processing the message and its
   contents.

4. Abstract Service Interfaces

Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity. The abstract service interfaces are intended to help clarify the externally observable behavior of SNMP entities, and are not intended to constrain the structure or organization of implementations in any way. Most specifically, they should not be interpreted as APIs or as requirements statements for APIs. These abstract service interfaces are defined by a set of primitives that define the services provided and the abstract data elements that are to be passed when the services are invoked. This section lists the primitives that have been defined for the various subsystems.

4.1. Dispatcher Primitives

The Dispatcher typically provides services to the SNMP applications via its PDU Dispatcher. This section describes the primitives provided by the PDU Dispatcher.
Top   ToC   RFC3411 - Page 31

4.1.1. Generate Outgoing Request or Notification

The PDU Dispatcher provides the following primitive for an application to send an SNMP Request or Notification to another SNMP entity: statusInformation = -- sendPduHandle if success -- errorIndication if failure sendPdu( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE )

4.1.2. Process Incoming Request or Notification PDU

The PDU Dispatcher provides the following primitive to pass an incoming SNMP PDU to an application: processPdu( -- process Request/Notification PDU IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of the Response PDU IN stateReference -- reference to state information ) -- needed when sending a response
Top   ToC   RFC3411 - Page 32

4.1.3. Generate Outgoing Response

The PDU Dispatcher provides the following primitive for an application to return an SNMP Response PDU to the PDU Dispatcher: result = -- SUCCESS or FAILURE returnResponsePdu( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size sender can accept IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication ) -- error counter OID/value if error

4.1.4. Process Incoming Response PDU

The PDU Dispatcher provides the following primitive to pass an incoming SNMP Response PDU to an application: processResponsePdu( -- process Response PDU IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN statusInformation -- success or errorIndication IN sendPduHandle -- handle from sendPdu )

4.1.5. Registering Responsibility for Handling SNMP PDUs

Applications can register/unregister responsibility for a specific contextEngineID, for specific pduTypes, with the PDU Dispatcher according to the following primitives. The list of particular pduTypes that an application can register for is determined by the Message Processing Model(s) supported by the SNMP entity that contains the PDU Dispatcher.
Top   ToC   RFC3411 - Page 33
   statusInformation =            -- success or errorIndication
     registerContextEngineID(
     IN   contextEngineID         -- take responsibility for this one
     IN   pduType                 -- the pduType(s) to be registered
          )

   unregisterContextEngineID(
     IN   contextEngineID         -- give up responsibility for this one
     IN   pduType                 -- the pduType(s) to be unregistered
          )

   Note that realizations of the registerContextEngineID and
   unregisterContextEngineID abstract service interfaces may provide
   implementation-specific ways for applications to register/deregister
   responsibility for all possible values of the contextEngineID or
   pduType parameters.

4.2. Message Processing Subsystem Primitives

The Dispatcher interacts with a Message Processing Model to process a specific version of an SNMP Message. This section describes the primitives provided by the Message Processing Subsystem.

4.2.1. Prepare Outgoing SNMP Request or Notification Message

The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Request or Notification Message: statusInformation = -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching -- incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length )
Top   ToC   RFC3411 - Page 34

4.2.2. Prepare an Outgoing SNMP Response Message

The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Response Message: result = -- SUCCESS or FAILURE prepareResponseMessage( IN messageProcessingModel -- typically, SNMP version IN securityModel -- same as on incoming request IN securityName -- same as on incoming request IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size able to accept IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication -- error counter OID/value if error OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length )
Top   ToC   RFC3411 - Page 35

4.2.3. Prepare Data Elements from an Incoming SNMP Message

The Message Processing Subsystem provides this service primitive for preparing the abstract data elements from an incoming SNMP message: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for possible Response )

4.3. Access Control Subsystem Primitives

Applications are the typical clients of the service(s) of the Access Control Subsystem. The following primitive is provided by the Access Control Subsystem to check if access is allowed: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object )
Top   ToC   RFC3411 - Page 36

4.4. Security Subsystem Primitives

The Message Processing Subsystem is the typical client of the services of the Security Subsystem.

4.4.1. Generate a Request or Notification Message

The Security Subsystem provides the following primitive to generate a Request or Notification message: statusInformation = generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message )

4.4.2. Process Incoming Message

The Security Subsystem provides the following primitive to process an incoming message: statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response
Top   ToC   RFC3411 - Page 37

4.4.3. Generate a Response Message

The Security Subsystem provides the following primitive to generate a Response message: statusInformation = generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- for the outgoing message IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message )

4.5. Common Primitives

These primitive(s) are provided by multiple Subsystems.

4.5.1. Release State Reference Information

All Subsystems which pass stateReference information also provide a primitive to release the memory that holds the referenced state information: stateRelease( IN stateReference -- handle of reference to be released )
Top   ToC   RFC3411 - Page 38

4.6. Scenario Diagrams

4.6.1. Command Generator or Notification Originator

This diagram shows how a Command Generator or Notification Originator application requests that a PDU be sent, and how the response is returned (asynchronously) to that application. Command Dispatcher Message Security Generator | Processing Model | | Model | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | |
Top   ToC   RFC3411 - Page 39

4.6.2. Scenario Diagram for a Command Responder Application

This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Response is (asynchronously) send back to the network. Command Dispatcher Message Security Responder | Processing Model | | Model | | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | |


(next page on part 3)

Next Section