环境的网络管理消息转换

4转换算法流程设计4.1数据模型分析

与SNMP相比,NETCONF是一个全新的XML配置管理协议.NETCONF协议在概念上分为四层,分别是内容层、操作层、RPC层和传输协议层.目前操作层、RPC层、传输协议层都有相应的标准和规范,内容层并没有给出具体要求,允许单独定义NETCONF数据模型,使得它的灵活性增强,但是另一方面也阻碍了NETCONF的广泛应用,数据模型定义与传统数据模型的转换是目前各大国际化标准研究的重点和热点.2009年,NETMOD工作组提出将 YANG[14]作为标准的NETCONF数据建模方法目前还处于讨论和验证中.现有的数据模型语言,如XML Schema Definition(XSD)和Relax NG可以用于其数据模型.正因为NETCONF基于XML,所以XSD是其一种比较理想的选择,本文也是采用XSD作为数据建模语言来开展实验.IETF组织,特别是NETCONF工作。

ParseXML类用于对NETCONF报文进行解析,其实现依赖于其他三个关键类;XmlDocument类主要用来提取基于XML的 NETCONF报文的关键信息,如设备P地址.操作对象OID、操作类型等;Operations类提供三种基本SNMP操作:GetRequest、GetBulkRequest和SetRequest，这为实现SNMP的基本功能提供了可能;UdpTarget类主要用来构造SNMP PDU,并依据具体操作发送相应SNMP请求报文.4.3转换算法流程设计

转换流程如图6(见下页)所示.5实验与分析

5.1实验环境和参数

采用Visual Studio 2010作为开发平台,编程语言是C#.实验选择了四台机器，一台机器作为基于NETCONF的网络管理端,一台机器作为报文转换器，一台机器作为SNMP代

理,一台作为NETCONF代理, SNMP代理端和NETCONF代理端分别通过RS232与汇聚节点相连,通过USB与和RFID读卡器相连,汇聚节点通过ZigBee 协议与静态节点相连.实验环境如图7(见下页)所示.

5.2运行实例

本文选取SNMP代理和NETCONF代理进行实验,目标是通过基于NETCONF管理端是获取设备的sysUpTime.

点击“ import object of management”,管理对象以树形结构显示在对象浏览器窗口中选择管理设备.输入代理的P地址再分别选择操作类型,数据库状态,操作对象,点击“cre-ateMessage”,管理端产生基于NETCONF管理报文并显示在发送窗口中.点击“sendMessage”,发送报文,等待转换器响应后,响应报文显示在报文接收窗口中.

若对应的是SNMP代理,接收窗口直接显示结果,发送报文以及返回报文如图8(见下页)所示.

若对应的是 NETCONF代理,接收窗口显示基于NET-CONF的rpc-reply报文,发送报文及返回报文如图9所示.若对应的是NETCONF代理并且发送报文缺少message-id,则返回基于NETCONF的rpc-error报文,封装在rpc-reply 中,发物联网网关

送和返回的报文如图10所示.5.3实验分析结果与改进

图11和图12分别表示系统测试20组,每组100次随机get-config操作的响应时间比较.测试的响应时间类型分别是响应总时间Ta﹑管理端到转换器传输时间工转换器处理时可知,四种类型响应时间在一个相对稳定的区间内波动,但是间TR 、转换器到代理端响应时间TTA.本文在测试时,第一次Tan和Tan明显高于Tn和TT,.经过分析,这主要是因为两方面响应时间作为特例不考虑,这是因为转换器以Web服务的方原因,首先基于TCP的报文传输时间明显高于基于UDP的报式发布,通过TCP三次握手与管理端建立连接,而转换器与代文传输时间,另外在包的大小方面,基于NETCONF的管理端理之间通过UDP通信,UDP不需要建立连接.由图11和图12发送的是XML报文,相对于SNMP只需变量绑定要复杂。

图12表示的是管理端发送的报文与经过转换后的报文叶子结点的实例,转换器自动调用GetBulkOperation与代理大小的变化比较,实验只考虑TCP或UDP报文段的数据部交互.由图13可知, NETCONF管理端的管理报文大小几乎分.本文测试用mib-2中前8个基本对象组,对于MIB树中非是稳定不变的,通过转换器转换后的SNMP管理报文大小的

变化波动相对较大.通过分析,这主要因为考虑到8个基本对象组中标量对象的个数不尽相同,权衡代理的处理时间和转换后报文数量后,实验将SNMPv2 GetBulk报文的NonRe-peaters字段设置为0, MaxRepetitions字段设置为20,对于标量对象大于20的对象组需要发送多个GetBulk请求.今后这部分可以优化,根据实际需要自动生成这两个参数来减少转换后的报文大小.测试转换前后报文大小变化为今后转化器位置部署提供了参考.

图13(见上页)表示的是随机产生20组,每组10000次管理报文得到正确响应报文的成功率,失败的操作将会返回错误类型.通过实验发现两种操作的成功率稳定在99.4%以上,通过返回的错误类型发现,失败与否主要与当前网络和系统状况有关. get-congfig 操作的成功率总体上高于edit-config的成功率,这是因为配置操作相对于取值操作受限更多.物联网网关

实验选择了响应时间、报文大小变化、成功率来评价系统的性能.实验主要考虑的是NETCONF管理端与SNMP代理的兼容性,数据模型采用的是在4.1节介绍的基于XML的四层结构,即将MIB-2库通过smidump转换成实验所需要的模型.实验过程中还发现,在转换过程中存在MIB树中间结点丢失的情况,由此可见转换MIB信息表达效率不够精确.

6结论

为了在物联网环境中部署一种基于NETCONF的统一网络管理系统,考虑到当前SNMP在配置性能、安全性和扩展性方面的不足,以及SMI语法复杂和灵活性差等问题,文章提出了面向物联网环境下网络管理消息转换机制,它能够自适应地对各种设备进行管理,特别是将这种转换机制通过web Service的方式提供给管理端,在安全性、可扩展性﹑配置效率上有很大程度提高.本文还提出了管理端、转换器、代理端的设计架构,通过实验验证了系统对SNMP代理的兼容性,能够对SNMP设备进行有效管理.

未来工作中我们将研究重点集中在数据模型、可扩展性、被管设备监控性能优化三个方面,最终实现物联网环境下网络设备的统一高效管理.

关键词：物联网网关