跳到主要内容

3. 架构元素 (Elements of the Architecture)

3. 架构元素 (Elements of the Architecture)

本节描述构成 SNMP 架构的元素. 该架构围绕 SNMP engine 的概念设计, SNMP engine 为一个或多个 SNMP applications 提供服务.

3.1. 实体的命名 (The Naming of Entities)

该架构中标识了若干类型的实体:

  • SNMP engine: 本架构所定义服务的一种实现. SNMP engine 提供 message processing, security, 和 access control 服务.

  • SNMP entity: 一个 SNMP engine 加上一个或多个 SNMP applications. SNMP entity 可以充当 agent, manager, 或同时充当二者.

  • SNMP agent: 提供对管理信息访问能力的 SNMP entity. agent 通常运行在被管理设备上.

  • SNMP manager: 发起 SNMP 请求并处理 SNMP 响应和通知的 SNMP entity. manager 通常运行在管理站上.

3.1.1. SNMP engine

SNMP engine 是 SNMP message processing, security, 和 access control 服务的一种实现. SNMP engine 由 snmpEngineID 唯一标识.

3.1.1.1. snmpEngineID

snmpEngineID 是一个 OCTET STRING, 用于唯一标识一个 SNMP engine. snmpEngineID 通过管理方式分配, 并且应选择为在网络中的所有 SNMP engines 范围内唯一.

snmpEngineID 的格式旨在确保唯一性. 它通常包含企业编号以及附加标识信息, 例如 MAC 地址, IP 地址, 或通过管理方式分配的值.

snmpEngineID 有几个重要用途:

  1. 标识发起消息的 SNMP engine
  2. 标识其 managed objects 正在被访问的 SNMP engine
  3. 作为 security information 的键
  4. 作为 localized security parameters 的键
3.1.1.2. Dispatcher

Dispatcher 负责:

  1. 从网络接收消息并确定消息版本
  2. 将消息路由到适当的 Message Processing Model
  3. 将 PDUs 路由到适当的 SNMP application
  4. 向网络发送消息

Dispatcher 向 applications 以及 SNMP engine 的 subsystems 提供 abstract service interfaces.

3.1.1.3. Message Processing Subsystem

Message Processing Subsystem 负责为传输准备消息, 并从收到的消息中提取数据.

Message Processing Subsystem 可以包含多个 Message Processing Models. 每个 Message Processing Model 定义一种消息格式以及处理该消息格式的过程.

3.1.1.3.1. Message Processing Model

Message Processing Model 定义一种消息格式以及处理该消息格式的过程. 不同的 Message Processing Models 可以共存于同一个 SNMP engine 中.

标准 Message Processing Models 包括:

  • SNMPv1: 定义于 RFC 3584
  • SNMPv2c: 定义于 RFC 3584
  • SNMPv3: 定义于 RFC 3412

每个 Message Processing Model 由唯一的 messageProcessingModel 值标识.

3.1.1.4. Security Subsystem

Security Subsystem 提供安全服务, 例如 authentication, privacy, 和 timeliness checking.

Security Subsystem 可以包含多个 Security Models. 每个 Security Model 定义一组 security protocols 以及应用这些协议的过程.

3.1.1.4.1. Security Model

Security Model 定义一组 security protocols 以及将它们应用到 SNMP messages 的过程. 不同的 Security Models 可以共存于同一个 SNMP engine 中.

标准 Security Models 包括:

  • User-based Security Model (USM): 定义于 RFC 3414, 使用对称密码技术提供 authentication 和 privacy
  • Community-based Security Model: 与 SNMPv1 和 SNMPv2c 一起使用, 定义于 RFC 3584

每个 Security Model 由唯一的 securityModel 值标识.

3.1.1.4.2. Security Protocol

Security Protocol 是 Security Model 使用的特定加密算法. 例如, User-based Security Model 支持多个 authentication protocols (HMAC-MD5-96, HMAC-SHA-96) 和多个 privacy protocols (CBC-DES, CBC-AES).

3.1.2. Access Control Subsystem

Access Control Subsystem 判定是否应允许某个特定 SNMP 操作. 它基于用户身份, 操作类型, 以及正在访问的 managed object 做出该判定.

Access Control Subsystem 可以包含多个 Access Control Models. 每个 Access Control Model 定义一项用于做出 access control 决策的策略.

3.1.2.1. Access Control Model

Access Control Model 定义一项策略, 用于判定是否应授予对 managed object 的访问. 不同的 Access Control Models 可以共存于同一个 SNMP engine 中.

标准 Access Control Model 是 View-based Access Control Model (VACM), 定义于 RFC 3415.

每个 Access Control Model 由唯一的 accessControlModel 值标识.

3.1.3. Applications

SNMP applications 使用 SNMP engine 的服务来执行管理功能. 一个 SNMP entity 可以包含多个 applications.

3.1.3.1. SNMP Manager

SNMP manager 是发起 SNMP 请求并处理 SNMP 响应和通知的 SNMP entity. manager 通常包含以下类型的 applications:

  • Command Generator: 发起 Get, GetNext, GetBulk, 和 Set 操作
  • Notification Receiver: 接收 Trap 和 InformRequest 操作

manager 还可以包含 Proxy Forwarder application, 用于将 SNMP messages 转发给其他 SNMP entities.

3.1.3.2. SNMP Agent

SNMP agent 是提供对管理信息访问能力的 SNMP entity. agent 通常包含以下类型的 applications:

  • Command Responder: 响应 Get, GetNext, GetBulk, 和 Set 操作
  • Notification Originator: 发起 Trap 和 InformRequest 操作

agent 还可以包含 Proxy Forwarder application, 用于将 SNMP messages 转发给其他 SNMP entities.

agent 包含 instrumentation, 即提供对实际 managed objects 访问能力的软件. instrumentation 在 SNMP operations 与访问底层 managed objects 所需的操作之间进行转换.

3.2. 身份的命名 (The Naming of Identities)

该架构区分 entities (即实现) 与 identities (即代表用户或 principals 的身份).

3.2.1. Principal

principal 是代表其发送或接收 SNMP message 的用户或系统. principal 是 SNMP operation 的最终授权来源.

3.2.2. securityName

securityName 是表示 principal 的人类可读字符串. 它是与 security model 无关的用户标识符.

securityName 由 Access Control Subsystem 使用, 以判定是否应允许某项操作. 不同的 Security Models 可以使用不同格式来表示 principal, 但它们都必须能够生成可供 Access Control Subsystem 使用的 securityName.

3.2.3. 依赖模型的安全 ID (Model-dependent security ID)

model-dependent security ID 是 Security Model 特定的 principal 表示. 例如, 在 User-based Security Model 中, model-dependent security ID 是 userName.

Security Model 负责在 model-dependent security ID 与 securityName 之间转换.

3.3. 管理信息的命名 (The Naming of Management Information)

管理信息被组织为相关对象的集合. 该架构提供用于命名和标识这些集合的机制.

3.3.1. SNMP Context

SNMP context 是 SNMP entity 可访问的一组管理信息. SNMP entity 可以访问多个 contexts.

contexts 的使用允许单个 SNMP agent 表示来自多个设备或 subsystems 的管理信息. 例如, proxy agent 可以表示来自若干设备的管理信息, 并将每个设备的信息放在单独的 context 中.

contexts 由 contextEngineID 和 contextName 标识.

3.3.2. contextEngineID

contextEngineID 唯一标识一个 SNMP entity, 该 SNMP entity 可以实现具有特定 contextName 的某个 context 实例. 这通常是能够访问该管理信息的 SNMP engine 的 snmpEngineID.

3.3.3. contextName

contextName 用于命名一个 context. 它是人类可读字符串.

contextEngineID 和 contextName 共同唯一标识一组管理信息.

3.3.4. scopedPDU

scopedPDU 是包含 contextEngineID 和 contextName 字段的 PDU. 这允许 PDU 标识操作适用于哪个 context.

scopedPDU 用于 SNMPv3 messages. 它由以下部分组成:

  • contextEngineID
  • contextName
  • PDU (实际的 protocol data unit)

3.4. 其他构造 (Other Constructs)

3.4.1. maxSizeResponseScopedPDU

maxSizeResponseScopedPDU 是可在响应消息中发送的 scopedPDU 的最大大小. 该值在消息交换期间协商, 用于避免发送过大而使接收实体无法处理的消息.

3.4.2. Local Configuration Datastore

Local Configuration Datastore (LCD) 是配置性信息的概念性存储库. 它包含 SNMP engine 所需的信息, 例如 security parameters 和 access control rules.

LCD 通常使用可通过 SNMP 访问和修改的 managed objects 来实现. 具体的 managed objects 定义在各种 MIB modules 中, 例如 SNMP-FRAMEWORK-MIB, SNMP-USER-BASED-SM-MIB, 和 SNMP-VIEW-BASED-ACM-MIB.

3.4.3. securityLevel

securityLevel 指示应用于 SNMP message 的安全级别. 定义了三个安全级别:

  1. noAuthNoPriv: 无 authentication 且无 privacy
  2. authNoPriv: 有 authentication 但无 privacy
  3. authPriv: 同时有 authentication 和 privacy

securityLevel 在发送消息时由 application 指定, 并在接收消息时由 Security Subsystem 判定.