为使用SNMP定义Trap的惯例

【为使用SNMP定义Trap的惯例】1. 历史前景
就如RFC1025中所报告的,为Internet网络治理标准[1]发展做的IAB推荐,一个基于
TCP/IP的网管的双重策略被采纳 。在短期内,在RFC中定义的简单网管协议,被用来管
理Internet社区的节点 。在长期内,OSI网络治理框架的使用将会通过检验 。产生了两份
文档来定义治理信息:RFC1065,它定义了治理信息结构(SMI),以及RFC1066 。定义
了治理信息基础 。设计这两份文档以便于与SNMP和OSI网管框架相协调 。
这个策略在短期内非常成功:在几个月内,通过研究和商业社区,形成了基于Internet
的网管技术 。由此而产生的结果是:一时间Internet部分社区变为可治理的网络 。
在RFC1109中报告的,第二AdHoc网管审查组[2]的报告,SNMP和OSI网管框架
比预期的有很大不同 。由此,在SMI和MIB之间以及二者共同的和谐性的需求被暂停了 。
这个行动答应了基于SNMP的可操作的网管框架在Internet社区通过MIB-II产生来响应新
的操作请求 。
1990年5月,核心文档以被建议的身份被提升为标准协议 。由此,Internet标准网管
框架包含:基于TCP/IPinternet治理信息的结构和认证,即RFC1155[3],它描述了包含
在MIB中被治理的对象是如何被定义的;基于TCP/IPinternet网管的治理信息基础,即RFC
1156[4],它描述了包含在MIB中的被治理的对象;简单网管协议,即RFC1157[5],定义
了用于治理这些对象的协议 。
2.定义陷阱
由于Internet标准SMI起初独立于协议的要求,它并没有提供定义陷阱的方法 。取而
代之的是,SNMP定义了一些标准化的陷阱,为企业的治理传送企业专用陷阱提供了一种
方法 。
然而,随着实验性MIBs的出现,其中有些需要定义实验专用的陷阱,急需一种定义陷阱的
方便的方法 。为此建议使用陷阱类型宏 。
IMPORTS
ObjectName
FROMRFC1155-SMI;
TRAP-TYPEMACRO::=
BEGIN
TYPENOTATION::="ENTERPRISE"value
(enterpriseOBJECTIDENTIFIER)
VarPart
DescrPart
ReferPart
VALUENOTATION::=value(VALUEINTEGER)
VarPart::=
"VARIABLES""{"VarTypes"}"
empty
VarTypes::=
VarTypeVarTypes","VarType
VarType::=
value(vartypeObjectName)
DescrPart::=
"DESCRIPTION"value(descriptionDisplayString)
empty
ReferPart::=
"REFERENCE"value(referenceDisplayString)
empty
END
然而必须强调在Internet标准网管框架中,使用陷阱是非常令人失望的 。陷阱类型宏是
用来认可现存的简明的定义,而不是促使定义新的陷阱 。
2.1.制定陷阱宏种类
应该注重的是陷阱类型宏的扩张概念上是发生在完成时而不是在运行期间 。
2.1.1.制定企业条款
企业条款,必须是现有的,定义了企业治理,在其下的注册权限,这个陷阱是定义了的 。(关
于注册权限的授权的讨论,见SMI[3]) 。评估被放在SNMP陷阱协议数据单元的企业项内 。
根据惯例,假如企业条款的评估是简单网管协议中的
对象标志符::={mib-211}
就象在MIB-II[7]中定义的,sysObjectID的评估被放在SNMP陷阱协议数据单元的企业项
内,而不使用此项评估 。这提供了一种使用陷阱类型宏来代表现存的SNMP标准陷阱的方
法;它并没有用来提供定义另外的SNMP标准陷阱的方法 。
2.1.2.制定变量条款
变量条款,不必是现有的,定义了MIB对象的有序的序列,这些对象包含在每个陷阱
类型的实例中 。每个变量按顺序被放置在SNMP陷阱协议数据单元的变量绑定域内 。注重

推荐阅读