RFC 2571
An Architecture for Describing SNMP Management Frameworks
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.
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 | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
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.
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.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.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.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.
* One or more models may be present.
(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 RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v v
+------------------------------+
| Network |
+------------------------------+
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. +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-----+ +-----+ +-------+ | UDP | | IPX | . . . | other | +-----+ +-----+ +-------+ (traditional SNMP agent) +-------------------------------------------------------------------+ | ^ | | | +---------------------+ +----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | Transport | | +->| v1MP * |<--->| +------------+ | | | | Mapping | | | +------------+ | | | Other | | | | | (e.g. RFC1906) | | | +------------+ | | | 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 | +-------------------------------------------------------------------+
3.2. The Naming of Identities
principal ^ | | +----------------------------|-------------+ | SNMP engine v | | +--------------+ | | | | | | +-----------------| securityName |---+ | | | Security Model | | | | | | +--------------+ | | | | ^ | | | | | | | | | v | | | | +------------------------------+ | | | | | | | | | | | Model | | | | | | Dependent | | | | | | Security ID | | | | | | | | | | | +------------------------------+ | | | | ^ | | | | | | | | +-------------------------|----------+ | | | | | | | +----------------------------|-------------+ | v network3.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.
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. +-----------------------------------------------------------------+ | SNMP entity (identified by snmpEngineID, example: abcd) | | | | +------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | +------------------------------------------------------------+ | | | | +------------------------------------------------------------+ | | | Command Responder Application | | | | (contextEngineID, example: abcd) | | | | | | | | example contextNames: | | | | | | | | "bridge1" "bridge2" "" (default) | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context | | context | | context | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | other MIB | | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+
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 [RFC2233], 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.
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, RFC1905 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) 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.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 response4.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 error4.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.
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 )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
)
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
)
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 -- identification of the principal
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
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 )
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 | | | |<-------------------| | | | | | |
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 a 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)
