SNMP OID RFC1213

--------------------------------------------------------------------------------

2007-12-05 11:17:40　标签：SNMP OID RFC1213 网络 管理　　　[推送到技术圈]

首先我们应该对整个OID的定义有所了解，所有使用对象标识符的实体组成一个OID树，结构类似于Internet的域名系统，每个实体就是树中的一个节点。最上面的节点被称为根节点，边缘节点被称为叶节点，每个节点有一个名字和一个非负的整数（表示节点本身在同级节点所处的位置），下图为OID树的一部分。

在整个OID树中，只有叶节点真正表示一个信息实体，其他的节点被称为辅助节点（place holder）。辅助节点组成OID树的枝干，使为数众多的叶节点可以附着在其上。

SNMP使用对象标识符标识MIB中定义的每一个被管理对象。我在图上用框框起来部分就是我们平时常用的一个，也就是说为什么sysDescr的OID为1.3.6.1.2.1.1.1，它其实有三部分组成：

第一部分：1.3.6.1.2.1，表示树的iso-org-dod-internet-mgmt-mib-II。

第二部分：1，因为RFC1213中是这样定义的

system OBJECT IDENTIFIER ::= { mib-2 1 }

interfaces OBJECT IDENTIFIER ::= { mib-2 2 }

at OBJECT IDENTIFIER ::= { mib-2 3 }

ip OBJECT IDENTIFIER ::= { mib-2 4 }

icmp OBJECT IDENTIFIER ::= { mib-2 5 }

tcp OBJECT IDENTIFIER ::= { mib-2 6 }

udp OBJECT IDENTIFIER ::= { mib-2 7 }

egp OBJECT IDENTIFIER ::= { mib-2 8 }

-- historical (some say hysterical)

-- cmot OBJECT IDENTIFIER ::= { mib-2 9 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

sysDescr是属于system组的，所以为1

第三部分：1，因为RC1213是这样定义的{ system 1 }。

关于SNMP中OID压缩算法的研究

肖志彬 陈伟建

（成都电子科技大学 通信与信息工程学院 成都 610054）

【摘要】SNMP协议已经成为事实上的开放网络管理协议，并取得巨大的成功。但是由于SNMP协议过度强调了设计的易实现性。而导致其在大数据获取操作和网络带宽利用上的很多不足。本文在介绍业界提出一种压缩SNMP消息中OID的算法(OID Prefix Compression)，在此基础上并且根据压缩特征提出了另一种算法(OID Substitution Compression)。

关键词 简单网络管理协议 OBJECT IDENTIFIER 消息压缩.

1. 引言

SNMP(simple network management protocol)[1]作为业界实际上的开放网络管理标准，取得了巨大成功，几乎所有的现代网络设备都提供了SNMP服务。然而，由于追求简单和容易实现导致了SNMP协议对大数据获取的低效性和网络带宽的低利用特性，成为SNMP协议成为被人诟病

的一个主要因素。提出SNMP消息压缩算法主要是基于以下考虑：

l 同时由于SNMP消息报文采用的BER编码在空间特性上的低效导致在获取大数据量的时候的会造成冗余数据的出现，所以有必要提出SNMP 消息压缩算法。

l 同时由于进行消息压缩，可以在进行大数据量获取的请求报文的时候，插入更多的请求对象(OID)，从而减少两者的交互，减少网络通信量。

l 由于SNMP消息本身采用了加密算法，导致其数据变得更加具有随机性，增加了下层网络的压缩的难度[2]。所以在加密之前就直接对SNMP消息压缩，有助于避免这种情况的出现。

2. SNMP协议

2.1. 协议简述

SNMP采用了常用的C/S结构，集中式管理信息的方式。在SNMP语境中client指的是network manager,而server则指的是安装在网络设备上的SNMP Agent，两者负责不同的功能。SNMP Agent主要负责收集被管理的设备的数据，存储在本地。而Network Manager则负责从发现SNMP Agent,轮询SNMP Agent 收集数据，分析整理数据，最终得到整个网络的情况。

图表 一个典型SNMP通信协议栈图

2.2. MIB定义

MIB（Managed Information Base）管理信息库，用来定义SNMP Message 中交换的信息。IETF专门为MIB定义规定了一系列语法，称为SMI(Structure Managed Information) 在文档［２］详细介绍了MIB中各种数据结构的定义，以及数据直接之间的关系。在此我们只简要介绍一下OBJECT IDENTIFIER变量的定义。

对于SNMP 来说，MIB中的每一个变量都有对应着一个OBJECT IDENTIFIER，并且所有变量之间是树型关系。在树中每一个节点，我们都给他编号，从根节点开始，按照一定的顺序，最终我们可以使用一组数字来确定和表示MIB中定义的一个变量。

在图表2中，mgmt:= iso(1).org(3).dod(6).internet(1).mgmt(2)，或者我们可以直接用1.3.6.1.2.来表示mgmt变量。

2.3. SNMP消息格式

由于在前期设计SNMP协议尽的要求简单，SNMP只有设计一共6种数据原语操作，ger-request,getnext-request,getbulk-request,reponse-request,trap,inform。从SNMPv2[2]以后，所有的原语采用同一种数据格式来封装。

图表 3 SNMP Message

3. OBJECT IDENTIFIER压缩算法

3.1. OID Prefix Compression（OPC）

从统计规律上看，大部分Variable OID都具有一定的关联性，也就是说都具有相同的前缀，这种特性使得我们可以采用合并前缀的方法来进行OID压缩。

根据文档[4]，每个变量的OID长度最大不超过128。我们采用将根据以下算来实现OID压缩。首先，选取一个作为锚定的目标不做任何压缩，然后根据以下公式对后续的OID进行压缩。

1．选定一个OID作为锚定的OID,对其不做任何压缩处理。

2．找到后续OID的中第一个不同第sub-identi

fier，其位置记为Sdiv.

3．将Sdiv拆分成两个 sub-identifier, S1, S2 S1=Sdiv/40,S2= Sdiv%40。其中 S1∈[0,2],

S2∈[0,39].

4． S3=后续OID中从从第一个不同的sub-identifier后所有的sub-identifier。则后续OID压缩成S1. S2. S3

5. 将此OID作为锚定的OID,转到步骤2。

l 举例：

原始编码：

1.3.6.1.2.1.1.1.0 -- sysUpTime.0

1.3.6.1.2.1.2.2.1.8.1 -- ifOperStatus.1

1.3.6.1.2.1.2.2.1.8.2 -- ifOperStatus.2

1.3.6.1.2.1.2.2.1.10.1 -- ifInOctets.1

1.3.6.1.2.1.2.2.1.10.2 -- ifInOctets.2

压缩编码之后：

1.3.6.1.2.1.1.1.0

0.7.2.2.1.8.1

0.11.2

0.10.10.1

0.11.2

l 适用范围

从OPC算法的特性来看，是不断的将后续的OID与锚定的OID比较，算出出现不同sub-identifier的位置来进行压缩，该算法比较适合只适用在以简单的字段作为索引的MIBTable中实现列遍历的数据获取操作，比如ifTable 中获取所有的ifInOctets。如果要对某一行数据进行操作的时候，根据MIBTable 中OID生成规则，仍然会生成大量的冗余OID编码。比如：

1.3.6.1.2.1.4.1.22.1.2.1.192.147.142.35

--ipNetToMediaPhysAddress.1.192.147.142.35

1.3.6.1.2.1.4.1.22.1.4.1.192.147.142.35

--ipNetToMediaPhysType.1.192.147.142.35

由于两者处于同一行的不同列，而OID生成规则要求将列标识考虑进去，因而造成了从列标识和后面的实例表示都要编码，而造成OID编码冗余，在下面一节我们将提出一种算法来解决这个问题。

3.2. OID Substitution Compression

为了弥补OPC算法对于行数据操作的低效性，和为了继承OPC 算法在列遍历上的优势和算法本身的简单性和易实现性，我们提出一种简单的算法OID Substitution Compression(OSC)。和OPC 一样也是不断通过与前一个OID比较来实现对两者不同的sub-identifier进行编码，从而达到压缩OID的目的。

l 压缩规则

1. 一位简单sub-identifier替换

S offset BER Coding OID

S用一个字节来表示，指明被压缩的OID与前一个OID不同的sub-identifier的位置。由于OID长度小于128，所以S的范围是0x00—0x7f 。0x00表示第一个sub-identifier。

BER Coding OID是在被压缩的OID中与前一个OID不同的sub-identifier的BER编码。

2. 指定范围sub-identifiers替换，

S offset r length BER Coding OID

S表征指明被压缩的OID与前一个OID不同的第一个sub-identifier的位置。S的取值范围是0x80—0xff，其中0x80表示第一位。r表示 在被压缩的OID不同的sub-identifier的长度，r取值范围是0x01—0x7f。BER Coding OID是在被压缩的OID中与前一个OID不同的一组sub-identifiers的BER编码。

l 算法流程

图表4 DPC编码（左）/解码（右）流程

l 测试用例：

1． 单个sub-identifier替换

tcpConnState.0.0.0.0.21.

0.0.0.0.0 = listen(2)

tcpConnState.0.0.0.0.22.0.0.0.0.0 = listen(2)

原始的BER编码 压缩后的编码

30:18

06:13:2B:06:01:02:01:06:0D:01:01:

00:00:00:00:15:00:00:00:00:00

02:01:02

30:18

06:13:2B:06:01:02:01:06:0D:01:01:

00:00:00:00:16:00:00:00:00:00

02:01:02 30:18

06:13:2B:06:01:02:01:06:0D:01:01:

00:00:00:00:15:00:00:00:00:00

02:01:02

30:07

2a:02:0E:16

02:01:02

2． 指定范围sub-identifiers替换。

tcpConnState.134.169.34.190.50054.130.240..53.80 = closeWait(8)

tcpConnState.134.169.34.190.50366.212.185.76.85.80 = closeWait(8)

原始的BER编码 压缩后的编码

30:1F

06:1A:2B:06:01:02:01:06:0D:01:01:

81:06:81:29:22:81:3E:83:87:06:

81:02:81:70:40:35:50

02:01:08

30:1F

06:1A:2B:06:01:02:01:06:0D:01:01:

81:06:81:29:22:81:3E:83::3E:

81:54:81:39:4C:55:50

02:01:08 30:1F

06:1A:2B:06:01:02:01:06:0D:01:01:

81:06:81:29:22:81:3E:83:87:06:

81:02:81:70:40:35:50

02:01:08

30:10 2A:0B:8E:05: 83::3E:81:54:81:39:4C:55

02:01:08

l 算法比较

下面分别去两组样本使用原始编码(BER),和两种压缩算法OPC,OSC进行编码

No:1 1.3.6.1.2.1.1.1.0

1.3.6.1.2.1.1.2.0

1.3.6.1.2.1.1.3.0

1.3.6.1.2.1.1.4.0

No:2 tcpConnState.0.0.0.0.21.0.0.0.0.0

tcpConnState.0.0.0.0.22.0.0.0.0.0

tcpConnState.0.0.0.0.23.0.0.0.0.0

tcpConnState.0.0.0.0.98.0.0.0.0.0

样本 BER OPC OSC

No:1 40 Bytes 25 Bytes 22 Bytes

No:2 84 Bytes 48 Bytes 33 Bytes

4. 结语

由于SNMP消息中的OID较高的关联特性，这两种SNMP的压缩算法和原始消息比较都有比较高的压缩效率。由于OSC算法的灵活性，导致在对MIBTable的行操作上，以及在获取相关性不太强的OID对象压缩比例远远高于OPC,但同时也由于编码的灵活性，导致实现上也较 OPC复杂：比如需要判断是否是简单替换，还是某个范围的替换，同时，由于在报文中由于可能同时存在压缩和没有压缩的OID,需要设置一个辩识为来确定该OID是否别压缩。应而我们可以在不同环境下综合使用这两中算法。

，

参 考 文 献

[1] Case, J., Fedor, M., Schoffstall, M. and J. David, "A Simple Network Management Protocol (SNMP)

col Operations for the Simple Network Management Protocol (SNMP)”,STD 62 RFC 3416,December 2002.

[3] D. Perkins “

[4] K. McCloghrie, D. Perkins, J. Schoenwaelder “Structure of Management Information Version 2 (SMIv2)”

STD 58 ,RFC 2578 ,April 1999

[5] M. Daniele, B. Wijnen, M. Ellison, Ed,” Agent Extensibility (AgentX) Protocol”,STD 63 RFC 2741, January 2000

[6] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol