3. SNMP 架构
SNMP 体系结构模型中隐含的是一组网络管理站和网络元素。网络管理站执行监视和控制网络元素的管理应用。网络元素是诸如主机、网关、终端服务器之类的设备，它们具有管理代理，负责执行网络管理站所请求的网络管理功能。简单网络管理协议（SNMP）用于在网络管理站与网络元素中的代理之间传递管理信息。
3.1. 架构目标
SNMP 明确地将管理代理本身所实现的管理功能的数量和复杂度降到最低。这一目标至少在四个方面具有吸引力：
-
支持该协议所必需的管理代理软件的开发成本相应地降低。
-
远程支持的管理功能程度相应地提高，从而能够在管理任务中最充分地利用互联网资源。
-
远程支持的管理功能程度相应地提高，从而对管理工具的形式和精巧程度施加尽可能少的限制。
-
简化后的管理功能集易于被网络管理工具开发者理解和使用。
该协议的第二个目标是，用于监视和控制的功能范式应具有足够的可扩展性，以容纳网络运行和管理中额外的、可能未曾预料到的方面。
第三个目标是，该体系结构应尽可能独立于特定主机或特定网关的体系结构和机制。
3.2. 架构要素
SNMP 体系结构从以下方面阐述了网络管理问题的解决方案：
-
协议所传递管理信息的范围，
-
协议所传递管理信息的表示，
-
协议所支持的对管理信息的操作，
-
管理实体之间交换的形式和含义，
-
管理实体之间管理关系的定义，以及
-
对管理信息的引用的形式和含义。
3.2.1. 管理信息的范围
通过 SNMP 运行所传递的管理信息的范围，正是由所有非聚合对象类型的实例所表示的范围，这些非聚合对象类型要么定义于 Internet 标准 MIB 中，要么按照 Internet 标准 SMI [5] 所阐述的约定在其他地方定义。
对 MIB 中聚合对象类型的支持，既不是与 SMI 保持一致所要求的，也不是 SNMP 所实现的。
3.2.2. 管理信息的表示
通过 SNMP 运行所传递的管理信息，按照 ASN.1 语言 [9] 中为 SMI 里非聚合类型的定义所指定的子集来表示。
SGMP 采用了使用 ASN.1 语言 [9] 一个明确定义的子集的约定。SNMP 沿用并扩展了这一传统，使用一个稍为复杂的 ASN.1 子集来描述被管对象，以及描述用于管理这些对象的协议数据单元。此外，为了便于最终向基于 OSI 的网络管理协议过渡，人们用 ASN.1 语言定义了 Internet 标准的管理信息结构（SMI）[5] 和管理信息库（MIB）[6]。ASN.1 语言的使用，部分地受到 ASN.1 在早期工作中——尤其是 SGMP 中——成功应用的鼓励。作为 SMI 一部分的对 ASN.1 使用的限制，有助于实现 SGMP 所倡导并经其经验验证的简洁性。
同样出于简洁性考虑，SNMP 只使用 ASN.1 [10] 基本编码规则的一个子集。即，所有编码都使用定长形式。此外，只要允许，就使用非构造型编码而不是构造型编码。这一限制适用于 ASN.1 编码的所有方面，无论是对顶层协议数据单元还是对它们所包含的数据对象。
3.2.3. 管理信息上支持的操作
SNMP 将管理代理的所有功能都建模为对变量的修改或查看。因此，位于逻辑上远程主机（可能就是这个网络元素本身）上的协议实体与驻留在网络元素上的管理代理交互，以检索（get）或修改（set）变量。这一策略至少有两个正面结果：
-
它的效果是把管理代理所实现的基本管理功能的数量限制为两个：一个操作用于为指定的配置或其他参数赋值，另一个操作用于检索这样的值。
-
这一决定的第二个效果是避免在协议定义中引入对命令式管理命令的支持：这类命令的数量在实践中不断增加，而且这类命令的语义通常任意复杂。
SNMP 中隐含的策略是，对网络状态在任何有意义细节层次上的监视，主要通过在监控中心一侧轮询适当的信息来完成。数量有限的非请求消息（trap）指导轮询的时机和焦点。限制非请求消息的数量，与追求简洁并最小化网络管理功能所产生流量的目标是一致的。
将命令式命令排除在显式支持的管理功能集合之外，不太可能排除任何需要的管理代理操作。目前，大多数命令要么是设置某个参数的值的请求，要么是检索这样的值的请求，而当前所支持的少数命令式命令的功能，在这个管理模型下很容易以异步方式实现。在这一方案中，命令式命令可以实现为设置一个参数值，该参数值随后触发所需动作。例如，与其实现一条"reboot command"，不如简单地设置一个表示距离系统重启还有多少秒的参数来触发这一动作。
3.2.4. 协议交换的形式和含义
在 SNMP 中，管理实体之间管理信息的通信通过协议消息的交换来实现。这些消息的形式和含义在第 4 节中定义。
与最小化管理代理复杂度的目标一致，SNMP 消息的交换只要求不可靠的数据报服务，而且每条消息都完整且独立地由单个传输数据报表示。尽管本文档规定通过 UDP 协议 [11] 交换消息，但 SNMP 的机制通常适用于多种多样的传输服务。
3.2.5. 管理关系的定义
SNMP 体系结构允许参与该协议的实体之间存在多种管理关系。驻留在管理站和网络元素上、使用 SNMP 相互通信的实体称为 SNMP 应用实体。实现 SNMP 并因此支持 SNMP 应用实体的对等进程称为协议实体。
SNMP 代理与某个任意的 SNMP 应用实体集合的配对称为 SNMP 团体。每个 SNMP 团体由一个八位位组串命名，该串称为该团体的团体名。
由某个 SNMP 应用实体发起、而该实体事实上属于由所述消息的团体组件所命名的 SNMP 团体的 SNMP 消息，称为可信 SNMP 消息。用于将一条 SNMP 消息识别为某个特定 SNMP 团体的可信 SNMP 消息的规则集合，称为鉴别方案。按照一种或多种鉴别方案来识别可信 SNMP 消息的功能的实现，称为鉴别服务。
显然，要有效地管理 SNMP 应用实体之间的管理关系，就需要鉴别服务能够（通过使用加密或其他技术）以很高的确定性识别出可信 SNMP 消息。有些 SNMP 实现可能只希望支持一种平凡的鉴别服务，即把所有 SNMP 消息都识别为可信 SNMP 消息。
对于任何网络元素，MIB 中与该元素相关的对象子集称为一个 SNMP MIB 视图。注意，SNMP MIB 视图中表示的对象类型的名称不必属于对象类型名字空间的单一子树。
集合 { READ-ONLY, READ-WRITE } 的一个元素称为一个 SNMP 访问模式。
SNMP 访问模式与 SNMP MIB 视图的配对称为一个 SNMP 团体配置文件。一个 SNMP 团体配置文件表示对指定 MIB 视图中变量的指定访问特权。对于给定 SNMP 团体配置文件的 MIB 视图中的每个变量，对该变量的访问由该配置文件按照以下约定表示：
-
如果所述变量在 MIB 中定义时 "Access:" 为 "none"，则它不能作为任何运算符的操作数；
-
如果所述变量在 MIB 中定义时 "Access:" 为 "read-write" 或 "write-only"，并且给定配置文件的访问模式为 READ-WRITE，则该变量可作为 get、set 和 trap 操作的操作数；
-
否则，该变量可作为 get 和 trap 操作的操作数。
-
在 "write-only" 变量作为 get 或 trap 操作所用操作数的情形下，为该变量给出的值是特定于实现的。
SNMP 团体与 SNMP 团体配置文件的配对称为一个 SNMP 访问策略。一个访问策略表示指定 SNMP 团体的 SNMP 代理向该团体其他成员提供的指定团体配置文件。SNMP 应用实体之间的所有管理关系都在体系结构上按 SNMP 访问策略来定义。
对于每个 SNMP 访问策略，如果指定 SNMP 团体的 SNMP 代理所在的网络元素，不是指定配置文件的 MIB 视图所针对的网络元素，则该策略称为 SNMP 委托访问策略。与委托访问策略相关联的 SNMP 代理称为 SNMP 委托代理。虽然对代理访问策略的定义不加注意可能导致管理环路，但谨慎地定义代理策略至少在两个方面有用：
-
它允许对那些本来无法使用管理协议和传输协议寻址的网络元素进行监视和控制。也就是说，委托代理可以提供协议转换功能，使管理站能够把一致的网络管理框架应用于所有网络元素，包括调制解调器、多路复用器以及支持不同管理框架的其他设备。
-
它有可能使网络元素免受复杂访问控制策略的影响。例如，委托代理可以实现精细的访问控制，使 MIB 内各不相同的变量子集可供不同的管理站访问，而不增加网络元素的复杂度。
作为示例，图 1 说明了管理站、委托代理和管理代理之间的关系。在此示例中，委托代理被设想为某个管理域中一个普通的 Internet 网络运行中心（INOC），该管理域与一组管理代理具有标准的管理关系。
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
- Domain: 元素的管理域
- PCommunity: 使用委托代理的团体的名称
- DCommunity: 直接团体的名称
图 1: 网络管理配置示例
3.2.6. 被管对象引用的形式和含义
SMI 要求一致性管理协议的定义必须处理以下问题：
-
有歧义的 MIB 引用的消解，
-
存在多个 MIB 版本时 MIB 引用的消解，以及
-
MIB 中所定义对象类型的特定实例的标识。
3.2.6.1. 消除有歧义的 MIB 引用
因为任何 SNMP 操作的范围在概念上都限于与单个网络元素相关的对象，并且因为对 MIB 对象的所有 SNMP 引用都（隐式或显式地）通过唯一的变量名进行，所以任何对 MIB 中所定义对象类型的 SNMP 引用都不可能解析为该类型的多个实例。
3.2.6.2. 解析跨 MIB 版本的引用
任何 SNMP 操作所引用的对象实例，正是作为该操作请求的一部分所指定的那个实例，或者（在 get-next 操作的情况下）它在整个 MIB 中的直接后继者。特别地，对作为 Internet 标准 MIB 某个版本一部分的对象的引用，不会解析为不属于所述 Internet 标准 MIB 该版本的任何对象，除非所请求的操作是 get-next 且所指定的对象名在作为所述 Internet 标准 MIB 该版本一部分而呈现的所有对象名中按字典序排在最后。
3.2.6.3. 对象实例的标识
MIB 中所有对象类型的名称，要么在 Internet 标准 MIB 中显式定义，要么在符合 SMI 命名约定的其他文档中显式定义。SMI 要求一致性管理协议定义用于标识特定网络元素上这些对象类型各个实例的机制。
MIB 中所定义任何对象类型的每个实例，在 SNMP 操作中都通过一个称为其"变量名"的唯一名称来标识。一般来说，SNMP 变量的名称是形如 x.y 的 OBJECT IDENTIFIER，其中 x 是 MIB 中所定义非聚合对象类型的名称，而 y 是一个 OBJECT IDENTIFIER 片段，它以特定于所命名对象类型的方式标识所需的实例。
这种命名策略允许最充分地利用 GetNextRequest-PDU 的语义（参见第 4 节），因为它为相关变量分配名称，使它们在 MIB 中已知的所有变量名的字典序中彼此相邻。
下面针对若干类对象类型定义了对象实例的特定于类型的命名。以下命名约定均不适用的对象类型的实例，由形如 x.0 的 OBJECT IDENTIFIER 命名，其中 x 是 MIB 定义中所述对象类型的名称。
例如，假设要标识变量 sysDescr 的一个实例。sysDescr 的对象类是：
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
因此，对象类型 x 将是 1.3.6.1.2.1.1.1，并附加实例子标识符 0。也就是说，1.3.6.1.2.1.1.1.0 标识 sysDescr 唯一的那一个实例。
3.2.6.3.1. ifTable 对象类型名称
子网接口 s 的名称是形如 i 的 OBJECT IDENTIFIER 值，其中 i 取与 s 相关联的 ifIndex 对象类型该实例的值。
对于每个对象类型 t，如果其定义的名称 n 具有 ifEntry 前缀，则 t 的实例 i 由形如 n.s 的 OBJECT IDENTIFIER 命名，其中 s 是 i 所表示信息的那个子网接口的名称。
例如，假设要标识与接口 2 相关联的变量 ifType 的实例。相应地，ifType.2 将标识所需的实例。
3.2.6.3.2. atTable 对象类型名称
AT 缓存的网络地址 x 的名称是形如 1.a.b.c.d 的 OBJECT IDENTIFIER，其中 a.b.c.d 是与 x 相关联的 atNetAddress 对象类型实例的值（采用熟悉的"点"表示法）。
地址转换等价物 e 的名称是形如 s.w 的 OBJECT IDENTIFIER 值，其中 s 是与 e 相关联的 atIndex 对象类型该实例的值，而 w 是与 e 相关联的 AT 缓存网络地址的名称。
对于每个对象类型 t，如果其定义的名称 n 具有 atEntry 前缀，则 t 的实例 i 由形如 n.y 的 OBJECT IDENTIFIER 命名，其中 y 是 i 所表示信息的那个地址转换等价物的名称。
例如，假设要查找地址转换表（ARP 缓存）中与 IP 地址 89.1.1.42 和接口 3 相关联的条目的物理地址。相应地，atPhysAddress.3.1.89.1.1.42 将标识所需的实例。
3.2.6.3.3. ipAddrTable 对象类型名称
可 IP 寻址的网络元素 x 的名称是形如 a.b.c.d 的 OBJECT IDENTIFIER，其中 a.b.c.d 是与 x 相关联的 ipAdEntAddr 对象类型该实例的值（采用熟悉的"点"表示法）。
对于每个对象类型 t，如果其定义的名称 n 具有 ipAddrEntry 前缀，则 t 的实例 i 由形如 n.y 的 OBJECT IDENTIFIER 命名，其中 y 是 i 所表示信息的那个可 IP 寻址网络元素的名称。
例如，假设要查找 IP 接口表中与 IP 地址 89.1.1.42 相关联的条目的网络掩码。相应地，ipAdEntNetMask.89.1.1.42 将标识所需的实例。
3.2.6.3.4. ipRoutingTable 对象类型名称
IP 路由 x 的名称是形如 a.b.c.d 的 OBJECT IDENTIFIER，其中 a.b.c.d 是与 x 相关联的 ipRouteDest 对象类型该实例的值（采用熟悉的"点"表示法）。
对于每个对象类型 t，如果其定义的名称 n 具有 ipRoutingEntry 前缀，则 t 的实例 i 由形如 n.y 的 OBJECT IDENTIFIER 命名，其中 y 是 i 所表示信息的那个 IP 路由的名称。
例如，假设要查找 IP 路由表中与目的地 89.1.1.42 相关联的条目的下一跳。相应地，ipRouteNextHop.89.1.1.42 将标识所需的实例。
3.2.6.3.5. tcpConnTable 对象类型名称
TCP 连接 x 的名称是形如 a.b.c.d.e.f.g.h.i.j 的 OBJECT IDENTIFIER，其中 a.b.c.d 是与 x 相关联的 tcpConnLocalAddress 对象类型该实例的值（采用熟悉的"点"表示法），f.g.h.i 是与 x 相关联的 tcpConnRemoteAddress 对象类型该实例的值（采用熟悉的"点"表示法），e 是与 x 相关联的 tcpConnLocalPort 对象类型该实例的值，而 j 是与 x 相关联的 tcpConnRemotePort 对象类型该实例的值。
对于每个对象类型 t，如果其定义的名称 n 具有 tcpConnEntry 前缀，则 t 的实例 i 由形如 n.y 的 OBJECT IDENTIFIER 命名，其中 y 是 i 所表示信息的那个 TCP 连接的名称。
例如，假设要查找本地地址 89.1.1.42 的 TCP 端口 21 与远程地址 10.0.0.51 的 TCP 端口 2059 之间某条 TCP 连接的状态。相应地，tcpConnState.89.1.1.42.21.10.0.0.51.2059 将标识所需的实例。
3.2.6.3.6. egpNeighTable 对象类型名称
EGP 邻居 x 的名称是形如 a.b.c.d 的 OBJECT IDENTIFIER，其中 a.b.c.d 是与 x 相关联的 egpNeighAddr 对象类型该实例的值（采用熟悉的"点"表示法）。
对于每个对象类型 t，如果其定义的名称 n 具有 egpNeighEntry 前缀，则 t 的实例 i 由形如 n.y 的 OBJECT IDENTIFIER 命名，其中 y 是 i 所表示信息的那个 EGP 邻居的名称。
例如，假设要查找 IP 地址 89.1.1.42 的邻居状态。相应地，egpNeighState.89.1.1.42 将标识所需的实例。