Skip to main content

3. Elements of the Architecture

3. Elements of the Architecture​

This section describes the elements that make up the SNMP architecture. The architecture is designed around the concept of an SNMP engine, which provides services to one or more SNMP applications.

3.1. The Naming of Entities​

Several types of entities are identified within the architecture:

  • SNMP engine: An implementation of the services defined in this architecture. An SNMP engine provides message processing, security, and access control services.

  • SNMP entity: An SNMP engine plus one or more SNMP applications. An SNMP entity can act as an agent, a manager, or both.

  • SNMP agent: An SNMP entity that provides access to management information. An agent typically runs on a managed device.

  • SNMP manager: An SNMP entity that initiates SNMP requests and processes SNMP responses and notifications. A manager typically runs on a management station.

3.1.1. SNMP engine​

An SNMP engine is an implementation of the SNMP message processing, security, and access control services. An SNMP engine is uniquely identified by an snmpEngineID.

3.1.1.1. snmpEngineID​

The snmpEngineID is an OCTET STRING that uniquely identifies an SNMP engine. The snmpEngineID is administratively assigned and should be chosen to be unique across all SNMP engines in the network.

The format of the snmpEngineID is designed to ensure uniqueness. It typically includes an enterprise number and additional identifying information such as a MAC address, IP address, or administratively assigned value.

The snmpEngineID serves several important purposes:

  1. It identifies the SNMP engine that originated a message
  2. It identifies the SNMP engine whose managed objects are being accessed
  3. It serves as a key for security information
  4. It serves as a key for localized security parameters
3.1.1.2. Dispatcher​

The Dispatcher is responsible for:

  1. Receiving messages from the network and determining the message version
  2. Routing messages to the appropriate Message Processing Model
  3. Routing PDUs to the appropriate SNMP application
  4. Sending messages to the network

The Dispatcher provides abstract service interfaces to applications and to subsystems of the SNMP engine.

3.1.1.3. Message Processing Subsystem​

The Message Processing Subsystem is responsible for preparing messages for transmission and for extracting data from received messages.

The Message Processing Subsystem can contain multiple Message Processing Models. Each Message Processing Model defines a message format and the procedures for processing that message format.

3.1.1.3.1. Message Processing Model​

A Message Processing Model defines a message format and the procedures for processing that message format. Different Message Processing Models can coexist within a single SNMP engine.

Standard Message Processing Models include:

  • SNMPv1: Defined in RFC 3584
  • SNMPv2c: Defined in RFC 3584
  • SNMPv3: Defined in RFC 3412

Each Message Processing Model is identified by a unique messageProcessingModel value.

3.1.1.4. Security Subsystem​

The Security Subsystem provides security services such as authentication, privacy, and timeliness checking.

The Security Subsystem can contain multiple Security Models. Each Security Model defines a set of security protocols and the procedures for applying them.

3.1.1.4.1. Security Model​

A Security Model defines a set of security protocols and the procedures for applying them to SNMP messages. Different Security Models can coexist within a single SNMP engine.

Standard Security Models include:

  • User-based Security Model (USM): Defined in RFC 3414, provides authentication and privacy using symmetric cryptography
  • Community-based Security Model: Used with SNMPv1 and SNMPv2c, defined in RFC 3584

Each Security Model is identified by a unique securityModel value.

3.1.1.4.2. Security Protocol​

A Security Protocol is a specific cryptographic algorithm used by a Security Model. For example, the User-based Security Model supports multiple authentication protocols (HMAC-MD5-96, HMAC-SHA-96) and multiple privacy protocols (CBC-DES, CBC-AES).

3.1.2. Access Control Subsystem​

The Access Control Subsystem determines whether a particular SNMP operation should be allowed. It makes this determination based on the identity of the user, the type of operation, and the managed object being accessed.

The Access Control Subsystem can contain multiple Access Control Models. Each Access Control Model defines a policy for making access control decisions.

3.1.2.1. Access Control Model​

An Access Control Model defines a policy for determining whether access to a managed object should be granted. Different Access Control Models can coexist within a single SNMP engine.

The standard Access Control Model is the View-based Access Control Model (VACM), defined in RFC 3415.

Each Access Control Model is identified by a unique accessControlModel value.

3.1.3. Applications​

SNMP applications use the services of the SNMP engine to perform management functions. An SNMP entity can contain multiple applications.

3.1.3.1. SNMP Manager​

An SNMP manager is an SNMP entity that initiates SNMP requests and processes SNMP responses and notifications. A manager typically contains the following types of applications:

  • Command Generator: Initiates Get, GetNext, GetBulk, and Set operations
  • Notification Receiver: Receives Trap and InformRequest operations

A manager may also contain a Proxy Forwarder application, which forwards SNMP messages to other SNMP entities.

3.1.3.2. SNMP Agent​

An SNMP agent is an SNMP entity that provides access to management information. An agent typically contains the following types of applications:

  • Command Responder: Responds to Get, GetNext, GetBulk, and Set operations
  • Notification Originator: Initiates Trap and InformRequest operations

An agent may also contain a Proxy Forwarder application, which forwards SNMP messages to other SNMP entities.

An agent contains instrumentation, which is the software that provides access to the actual managed objects. The instrumentation translates between SNMP operations and the operations needed to access the underlying managed objects.

3.2. The Naming of Identities​

The architecture distinguishes between entities (which are implementations) and identities (which represent users or principals).

3.2.1. Principal​

A principal is a user or system on whose behalf an SNMP message is sent or received. The principal is the ultimate source of authority for an SNMP operation.

3.2.2. securityName​

A securityName is a human-readable string representing a principal. It is the security-model-independent identifier for a user.

The securityName is used by the Access Control Subsystem to determine whether an operation should be allowed. Different Security Models may use different formats for representing the principal, but they all must be able to produce a securityName that can be used by the Access Control Subsystem.

3.2.3. Model-dependent security ID​

A model-dependent security ID is the Security Model-specific representation of a principal. For example, in the User-based Security Model, the model-dependent security ID is a userName.

The Security Model is responsible for translating between the model-dependent security ID and the securityName.

3.3. The Naming of Management Information​

Management information is organized into collections of related objects. The architecture provides mechanisms for naming and identifying these collections.

3.3.1. An SNMP Context​

An SNMP context is a collection of management information accessible by an SNMP entity. An SNMP entity can have access to multiple contexts.

The use of contexts allows a single SNMP agent to represent management information from multiple devices or subsystems. For example, a proxy agent might represent management information from several devices, with each device's information in a separate context.

Contexts are identified by a contextEngineID and a contextName.

3.3.2. contextEngineID​

The contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. This is typically the snmpEngineID of the SNMP engine that has access to the management information.

3.3.3. contextName​

The contextName is used to name a context. It is a human-readable string.

Together, the contextEngineID and contextName uniquely identify a collection of management information.

3.3.4. scopedPDU​

A scopedPDU is a PDU that includes contextEngineID and contextName fields. This allows the PDU to identify which context the operation applies to.

The scopedPDU is used in SNMPv3 messages. It consists of:

  • contextEngineID
  • contextName
  • PDU (the actual protocol data unit)

3.4. Other Constructs​

3.4.1. maxSizeResponseScopedPDU​

The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that can be sent in a response message. This is negotiated during message exchange and is used to avoid sending messages that are too large for the receiving entity to process.

3.4.2. Local Configuration Datastore​

The Local Configuration Datastore (LCD) is a conceptual repository of configuration information. It contains information needed by the SNMP engine, such as security parameters and access control rules.

The LCD is typically implemented using managed objects that can be accessed and modified using SNMP. The specific managed objects are defined in various MIB modules, such as the SNMP-FRAMEWORK-MIB, SNMP-USER-BASED-SM-MIB, and SNMP-VIEW-BASED-ACM-MIB.

3.4.3. securityLevel​

The securityLevel indicates the level of security that is applied to an SNMP message. Three security levels are defined:

  1. noAuthNoPriv: No authentication and no privacy
  2. authNoPriv: Authentication but no privacy
  3. authPriv: Both authentication and privacy

The securityLevel is specified by the application when sending a message, and is determined by the Security Subsystem when receiving a message.

Last updated on