面向物联网环境的网络设备消息转换机制分析
物联网在当前互联网的基础上有了许多新的特点，因此对于物联网网络管理提出了新的需求，下面是小编搜集的一篇相关论文范文，欢迎阅读借鉴。
1引言
ISO定义的网络管理5个系统管理功能在物联网时代难以满足新的需求，传统的基于简单网络管理协议(SNMP，SimpleNetworkManagementPro-tocol)的网络管理系统，不管在扩展性方面还是管理效率方面的局限性日益突出，因此迫切需要新的网络管理系统模型.可扩展标记语言[1](XML，eXtensibleMarkupLanguage)的出现为构建物联网环境下的网络管理模型提供了可能.基于XML的网络管理系统具有其他网络管理系统无法比拟的特性，这些特性使得它非常适用于物联网网络管理.基于上述优势，为了统一规范基于XML的网络管理，IETF在2006年提出了基于XML技术的NETCONF[3](RFC4741)协议.NETCONF的提出不仅使基于XML新一代网络管理配置方面的功能得以加强，形成了结构明晰的规范，也使得XML网络管理的效率得到显着提升.基于NETCONF的网络管理已经得到广泛认可，事实上一些IT公司也开发并实现了支持NETCONF的相关系统，如Juniper公司的JU-NO[4]产品、Cisco公司的IOS[5]产品，相关开源产品有en-suite[6]的yencap+manager和yuma[7]等.
对于物联网这种融入各种异构网络的网络系统，更加迫切需要基于NETCONF的网络管理系统实现对网络设备跨网络、跨系统的高效管理.物联网相对于传统的互联网具有自身的一些显着特征，比如，网络拓扑变化很快;网络节点可以高速移动;节点间的链路状态变化频繁;节点能量、计算能力、存储能力有限等.NETCONF取代事实上的工业标准SNMP协议将会是一个漫长的过程，有必要通过一种转换机制，实现既能管理SNMP的网络设备，又能对基于其他网络协议的设备进行有效管理.将NETCONF应用于物联网网络管理，首先必须实现对SNMP的兼容，能将基于NETCONF的管理报文转换为SNMP管理报文.目前，协议转换研究吸引了许多网络管理专家的注意，但是大多数停留在理论阶段，或者研发的系统扩展性较差，针对物联网这一复杂网络环境下的消息转换方法研究很少.本文设计的消息转换机制可以实现对目前广泛采用的SNMP协议，非SNMP协议(比如ANMP，NETCONF)的支持，并且结合物联网特点设计NETCONF管理端、代理端，便于今后在物联网这个大环境下实现网络设备的统一管理.
2相关工作
在转换网关方面，为了弥补SNMP协议在网络管理扩展性以及效率上的不足，文献[8]提出一种SNMPMIB到XML的转换算法，并将转换算法应用于SNMP-XML转换网关.文献[9]重点讨论了SNMP-XML翻译网关中的MIB转换技术，并实现了MIB文件到XML文件的转换.文献[10]提出一种基于NETCONF的网络管理系统对SNMP和CLI设备进行管理的方法，文章主要分析数据模型的转换以及消息映射.文献[11]提出了一种通用网关模型，实现基于XML网络管理对SNMP代理和非SNMP代理的统一管理.在NETCONF协议的分析和应用开发方面，文献[12]通过实验分析证明了NETCONF在复杂网络环境下的强大性能，实验结果显示了NETCONF相对于SNMP和CLI，在网络管理上更高效、更安全、扩展性更强、更容易开发新的应用.文献[13]对NETCONF的三种建模语言XMLSchema、RelaxNG和YANG进行了对比分析，得出尽管YANG是专门为NET-CONF设计的建模语言，但是仍然有些地方考虑不足，比如转换工具设计得并不完善.上述文献大多数停留在理论架构阶段，或者仅仅对某个单一功能进行实现，例如文献[8]提出的转换器安全性不高，数据在传输过程中容易被劫取，而且使用的XML管理报文没有形成统一规范.文献[9-10]主要针对数据模型转换，文献[11]主要停留在管理消息转换的架构设计上，在实现方面只做了简单的描述.尽管NETCONF有众多优点，但是SNMP作为事实上的网络管理工业标准有很多不可替代的特性，比如它的简易性、实用性，以及它对设备的实时监控性优于NET-CONF协议，这些决定了未来SNMP协议将长期存在于网络环境中，单纯地将NETCONF应用于物联网不切实际.本文基于NETCONF协议，提出面向物联网网络管理的消息转换机制，实现对SNMP的兼容，同时也考虑了对其他网络管理协议的支持和系统的扩展性，为物联网环境下网络设备的统一管理提供了参考.
3基于NETCONF网络管理架构
3.1基于NETCONF管理端
管理端一共包含3个模块，如图1所示，分别是交互界面、管理消息处理层、会话通信层.交互界面负责与管理员进行信息交互.消息处理层是管理端的核心模块，负责将管理消息封装成基于NETCONF的管理报文，并传送给会话通信层.另外还负责验证收到的报文格式，解析出操作结果.内容层封装是根据采用的数据模型对报文进行封装.操作层封装、RPC封装则根据用户选择的操作类型将报文封装到相应的RPC报文中去.会话通信层对应NETCONF逻辑模型中传输层，负责将管理消息传输给消息转换器，并等待消息转换器的响应，将响应结果返回给消息处理层.【1】
3.2消息转换器架构
本文的消息转换器基于WebService进行通信.基于对XML的广泛接受，WebService成为使用标准传输、编码和协议来交换信息的应用程序.选择WebService作为管理端与消息转换器之间报文的传递，符合在物联网下网络管理消息传递的特性要求，更容易实现跨平台、跨设备、跨网络对网络设备的监管.消息转换器对发送过来的管理报文进行相应转换，使得网络管理端可以与不同类型的代理端进行通信，消息转换器以WebService的方式发布，实现与管理端交互，并且直接与物联网环境下不同类型的代理进行信息交互.消息转换器的整体架构如下页图2所示.主要分为三个功能模块，即消息分类器SNMP，报文转换模块，其它代理报文转换模块.
3.2.1NETCONF-SNMP管理消息转换负责将NETCONF管理报文转换为SNMP管理报文的转换器主要由6个模块构成，分别是请求分析器、MIB-XML翻译器、XMLDOM、XML询问器、trap处理模块(由trap接收器、trap分析器和trap过滤器组成)以及报文生成器.请求分析器结合XMLSchema判断管理报文的合法性，并且结合操作类型映射表提取操作类型.MIB-XML翻译器负责将SMIMIB转换为XML，转换后的XML，可以实现查找操作对象对应的OID，和操作对象的映射.XMLDOM是转换器的核心，对XML文件进行分析，将得到的设备地址、操作类型，操作对象OID等，传给SNMP轮询器，还负责接收trap，实现trap中参数映射后，传递给XML报文生成器.SNMP轮询器将得到的参数包装成SNMPPDU传给SNMP代理，并且接受来自SNMP代理的响应.为了减少管理端与转换器之间的通信流量，对SNMPtrap处理上采用过滤机制，trap处理器由3个模块组成，将接收到的trap进行分类，并建立分级制度来判断紧急程度，最后过滤掉一些重复或者失效的trap报文，并传递给XMLDOM报文生成器生成相应的响应报文或通知报文后传给NETCONF管理端.NETCONF-SNMP转换器也可以实现对ANMP代理的兼容性，这在于ANMP使用与SNMP相同的PDU格式，而且同样使用UDP作为传输协议来发送ANMP消息，在数据收集和控制方面，ANMP扩展了SNMPMIB以便记录AdHoc网络特有的信息.若要对ANMP代理进行管理，首先管理端载入对应的MIB文件，消息分类器判断管理报文中的IP地址，若对应的是ANMP代理时，将管理报文传给转换器，可以实现对ANMP代理对应设备的有效管理.
3.2.2对其他网络管理协议的支持考虑到物联网环境下存在少量其他网络管理协议，本文加入了一种支持其他网络管理协议的理论构架，下面对这种架构进行阐述.如图2所示，架构主要有四部分组成，分别是数据表、适配器、消息产生器、Trap接收器.其中三个数据表和三个适配器是架构的关键，设备信息表记录代理的相关信息，用以区分管理端与哪个代理通信;私有数据表将NETCONF的属性映射为代理的私有属性;操作表则将NETCONF的操作类型映射为代理的私有操作类型.报文适配器实现报文格式对应;传输适配器负责转换器与多种代理进行通信;trap适配器则负责代理如何主动与管理端进程通信，通知管理进程有某些事情发生.【2】
当管理端与代理通信时，转换器首先载入该代理的XML配置文件，生成三个数据表，分别是设备信息表、操作类型表、私有数据表.通过数据表生成上述三个适配器的具体实现，适配管理器负责初始化适配器并在合适的时候调用适配器.在适配管理器的协调下，消息产生器就能将管理端传递过来的NETCONF配置报文通过适配器转化为代理能够识别的PDU，返回的PDU也能通过管理消息产生器转换为基于NETCONF的响应报文.
3.3代理端架构设计
目前Cisco，Juniper等网络设备生产商都实现了基于RFC4741的代理，并嵌入到了它们最新的路由器当中.NETCONF采用XML进行数据传输和模块表达，具有较强的可扩展性，网络设备提供商可以使用此协议获取、设置所有的配置数据，适合物联网下的不同类型设备快速添加和高效管理.这些功能很大一部分依赖于代理端的实现，如何将基1对其进行网络管理是一个迫切需要解决的问题，这关系到NETCONF在物联网网络管理的生命力.本文将代理分为三种类型，分别是SNMP代理、NETCONF代理和其他代理.本节结合物联网的特征分析了NETCONF代理架构设计，按照RFC4741中规定，一个基本的NETCONF代理分四层结构来设计.另外代理必须完成对能力特性、三种数据库状态和事件通知的支持，基于NETCONF的代理架构如图3所示.【3】
会话通信层负责与管理端交互，代理端启动后会监听来自管理端的管理消息.消息处理器接受来自会话通信层的管理消息后，能够解析出操作类型和操作对象并传给操作处理器，也能将操作处理器操作后的结果封装成基于NETCONF的响应报文.操作处理器执行消息处理器解析出来的具体操作.管理对象信息库中配置信息状态分为3个阶段，对应3种数据库状态:运行状态(running)、启动状态(startup)和候选状态(candidate).能力(capabilities)是NETCONF的新特性，这种特性允许客户端发现服务端支持的协议扩展集，“能力”的提出丰富了基本操作集，增加新的操作使代理端扩展性得到提高.被管理设备将能力集传递给管理数据库存储，在管理端发出“HELLO”报文后，传递给管理端以告知管理端被管设备支持的协议扩展集.通知(Notification)模块负责将被管理设备主动发出的消息传递给消息处理器，再由消息处理器封装后，通过会话通信层传递给管理端.本文并没有将重点放在讨论“能力”和“通知”这种两种特性上，但这两种特性对于将NETCONF应用到物联网环境中至关重要，因为物联网环境需要“能力”来支持可扩展性，“通知”来支持对被管设备的实时监控，这也是我们未来工作讨论的重点.
4转换算法流程设计
4.1数据模型分析
与SNMP相比，NETCONF是一个全新的XML配置管理协议.NETCONF协议在概念上分为四层，分别是内容层、操作层、RPC层和传输协议层.目前操作层、RPC层、传输协议层都有相应的标准和规范，内容层并没有给出具体要求，允许单独定义NETCONF数据模型，使得它的灵活性增强，但是另一方面也阻碍了NETCONF的广泛应用，数据模型定义与传统数据模型的转换是目前各大国际化标准研究的重点和热点.2009年，NETMOD工作组提出将YANG[14]作为标准的NET-CONF数据建模方法目前还处于讨论和验证中.现有的数据模型语言，如XMLSchemaDefinition(XSD)和RelaxNG可以用于其数据模型.正因为NETCONF基于XML，所以XSD是其一种比较理想的选择，本文也是采用XSD作为数据建模语言来开展实验.IETF组织，特别是NETCONF工作组将XMLSchema列入考虑之中.【4】
德国开发的LIBSMI[15]是比较成功的案例，得到了广泛的认可，它将MIB树转换为公认较好的`四层结构，如图4所示.前两层与具体MIB无关，只有下两层才依赖于具体MIB，第三层为表结点的ENTRY结点，或者是标量结点的容器结点，第四层是叶子结点.对于非MIB树形式的管理对象也可以建立这样的四层结构模型，这样统一了网络被管对象的描述.本文在实验中便采用了该四层结构来规范管理对象数据.
4.2关键类设计
为了实现基于XML的NETCONF报文到SNMP报文的转换，需要对NETCONF报文进行解析.基于第2节中的转换器架构，本文设计的关键类有:ParseXML类、XmlDocument类、Oper-ations类以及UdpTarget类，关键类图如图5所示.ParseXML类用于对NETCONF报文进行解析，其实现依赖于其他三个关键类;XmlDocument类主要用来提取基于XML的NETCONF报文的关键信息，如设备IP地址、操作对象OID、操作类型等;Operations类提供三种基本SNMP操作:GetRequest、GetBulkRequest和SetRequest，这为实现SNMP的基本功能提供了可能;UdpTarget类主要用来构造SNMPPDU，并依据具体操作发送相应SNMP请求报文.
5实验与分析
5.1实验环境和参数
采用VisualStudio2010作为开发平台，编程语言是C#.实验选择了四台机器，一台机器作为基于NETCONF的网络管理端，一台机器作为报文转换器，一台机器作为SNMP代理，一台作为NETCONF代理，SNMP代理端和NETCONF代理端分别通过RS232与汇聚节点相连，通过USB与和RFID读卡器相连，汇聚节点通过ZigBee协议与静态节点相连.实验环境如图7(见下页)所示.
5.2运行实例
本文选取SNMP代理和NETCONF代理进行实验，目标是通过基于NETCONF管理端是获取设备的sysUpTime.点击“importobjectofmanagement”，管理对象以树形结构显示在对象浏览器窗口中选择管理设备.输入代理的IP地址再分别选择操作类型，数据库状态，操作对象，点击“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操作的响应时间比较.测试的响应时间类型分别是响应总时间Tall、管理端到转换器传输时间TMT、转换器处理时间TTR、转换器到代理端响应时间TTA.本文在测试时，第一次响应时间作为特例不考虑，这是因为转换器以Web服务的方式发布，通过TCP三次握手与管理端建立连接，而转换器与代理之间通过UDP通信，UDP不需要建立连接.由图11和图12可知，四种类型响应时间在一个相对稳定的区间内波动，但是Tall和TMT明显高于TTR和TTA.经过分析，这主要是因为两方面原因，首先基于TCP的报文传输时间明显高于基于UDP的报文传输时间，另外在包的大小方面，基于NETCONF的管理端发送的是XML报文，相对于SNMP只需变量绑定要复杂.图12表示的是管理端发送的报文与经过转换后的报文大小的变化比较，实验只考虑TCP或UDP报文段的数据部分.
本文测试用mib-2中前8个基本对象组，对于MIB树中非叶子结点的实例，转换器自动调用GetBulkOperation与代理交互.由图13可知，NETCONF管理端的管理报文大小几乎是稳定不变的，通过转换器转换后的SNMP管理报文大小的变化波动相对较大.通过分析，这主要因为考虑到8个基本对象组中标量对象的个数不尽相同，权衡代理的处理时间和转换后报文数量后，实验将SNMPv2GetBulk报文的NonRepeaters字段设置为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语法复杂和灵活性差等问题，文章提出了面向物联网环境下网络管理消息转换机制，它能够自适应地对各种设备进行管理，特别是将这种转换机制通过WebService的方式提供给管理端，在安全性、可扩展性、配置效率上有很大程度提高.本文还提出了管理端、转换器、代理端的设计架构，通过实验验证了系统对SNMP代理的兼容性，能够对SNMP设备进行有效管理.未来工作中我们将研究重点集中在数据模型、可扩展性、被管设备监控性能优化三个方面，最终实现物联网环境下网络设备的统一高效管理.
【面向物联网环境的网络设备消息转换机制分析】相关文章：