- 相關(guān)推薦
面向物聯(lián)網(wǎng)環(huán)境的網(wǎng)絡(luò)設(shè)備消息轉(zhuǎn)換機(jī)制分析
物聯(lián)網(wǎng)在當(dāng)前互聯(lián)網(wǎng)的基礎(chǔ)上有了許多新的特點(diǎn)，因此對(duì)于物聯(lián)網(wǎng)網(wǎng)絡(luò)管理提出了新的需求，下面是小編搜集的一篇相關(guān)論文范文，歡迎閱讀借鑒。
1引言
ISO定義的網(wǎng)絡(luò)管理5個(gè)系統(tǒng)管理功能在物聯(lián)網(wǎng)時(shí)代難以滿足新的需求，傳統(tǒng)的基于簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議(SNMP，SimpleNetworkManagementPro-tocol)的網(wǎng)絡(luò)管理系統(tǒng)，不管在擴(kuò)展性方面還是管理效率方面的局限性日益突出，因此迫切需要新的網(wǎng)絡(luò)管理系統(tǒng)模型.可擴(kuò)展標(biāo)記語(yǔ)言[1](XML，eXtensibleMarkupLanguage)的出現(xiàn)為構(gòu)建物聯(lián)網(wǎng)環(huán)境下的網(wǎng)絡(luò)管理模型提供了可能.基于XML的網(wǎng)絡(luò)管理系統(tǒng)具有其他網(wǎng)絡(luò)管理系統(tǒng)無(wú)法比擬的特性，這些特性使得它非常適用于物聯(lián)網(wǎng)網(wǎng)絡(luò)管理.基于上述優(yōu)勢(shì)，為了統(tǒng)一規(guī)范基于XML的網(wǎng)絡(luò)管理，IETF在2006年提出了基于XML技術(shù)的NETCONF[3](RFC4741)協(xié)議.NETCONF的提出不僅使基于XML新一代網(wǎng)絡(luò)管理配置方面的功能得以加強(qiáng)，形成了結(jié)構(gòu)明晰的規(guī)范，也使得XML網(wǎng)絡(luò)管理的效率得到顯著提升.基于NETCONF的網(wǎng)絡(luò)管理已經(jīng)得到廣泛認(rèn)可，事實(shí)上一些IT公司也開發(fā)并實(shí)現(xiàn)了支持NETCONF的相關(guān)系統(tǒng)，如Juniper公司的JU-NO[4]產(chǎn)品、Cisco公司的IOS[5]產(chǎn)品，相關(guān)開源產(chǎn)品有en-suite[6]的yencap+manager和yuma[7]等.
對(duì)于物聯(lián)網(wǎng)這種融入各種異構(gòu)網(wǎng)絡(luò)的網(wǎng)絡(luò)系統(tǒng)，更加迫切需要基于NETCONF的網(wǎng)絡(luò)管理系統(tǒng)實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)設(shè)備跨網(wǎng)絡(luò)、跨系統(tǒng)的高效管理.物聯(lián)網(wǎng)相對(duì)于傳統(tǒng)的互聯(lián)網(wǎng)具有自身的一些顯著特征，比如，網(wǎng)絡(luò)拓?fù)渥兓芸?網(wǎng)絡(luò)節(jié)點(diǎn)可以高速移動(dòng);節(jié)點(diǎn)間的鏈路狀態(tài)變化頻繁;節(jié)點(diǎn)能量、計(jì)算能力、存儲(chǔ)能力有限等.NETCONF取代事實(shí)上的工業(yè)標(biāo)準(zhǔn)SNMP協(xié)議將會(huì)是一個(gè)漫長(zhǎng)的過程，有必要通過一種轉(zhuǎn)換機(jī)制，實(shí)現(xiàn)既能管理SNMP的網(wǎng)絡(luò)設(shè)備，又能對(duì)基于其他網(wǎng)絡(luò)協(xié)議的設(shè)備進(jìn)行有效管理.將NETCONF應(yīng)用于物聯(lián)網(wǎng)網(wǎng)絡(luò)管理，首先必須實(shí)現(xiàn)對(duì)SNMP的兼容，能將基于NETCONF的管理報(bào)文轉(zhuǎn)換為SNMP管理報(bào)文.目前，協(xié)議轉(zhuǎn)換研究吸引了許多網(wǎng)絡(luò)管理專家的注意，但是大多數(shù)停留在理論階段，或者研發(fā)的系統(tǒng)擴(kuò)展性較差，針對(duì)物聯(lián)網(wǎng)這一復(fù)雜網(wǎng)絡(luò)環(huán)境下的消息轉(zhuǎn)換方法研究很少.本文設(shè)計(jì)的消息轉(zhuǎn)換機(jī)制可以實(shí)現(xiàn)對(duì)目前廣泛采用的SNMP協(xié)議，非SNMP協(xié)議(比如ANMP，NETCONF)的支持，并且結(jié)合物聯(lián)網(wǎng)特點(diǎn)設(shè)計(jì)NETCONF管理端、代理端，便于今后在物聯(lián)網(wǎng)這個(gè)大環(huán)境下實(shí)現(xiàn)網(wǎng)絡(luò)設(shè)備的統(tǒng)一管理.
2相關(guān)工作
在轉(zhuǎn)換網(wǎng)關(guān)方面，為了彌補(bǔ)SNMP協(xié)議在網(wǎng)絡(luò)管理擴(kuò)展性以及效率上的不足，文獻(xiàn)[8]提出一種SNMPMIB到XML的轉(zhuǎn)換算法，并將轉(zhuǎn)換算法應(yīng)用于SNMP-XML轉(zhuǎn)換網(wǎng)關(guān).文獻(xiàn)[9]重點(diǎn)討論了SNMP-XML翻譯網(wǎng)關(guān)中的MIB轉(zhuǎn)換技術(shù)，并實(shí)現(xiàn)了MIB文件到XML文件的轉(zhuǎn)換.文獻(xiàn)[10]提出一種基于NETCONF的網(wǎng)絡(luò)管理系統(tǒng)對(duì)SNMP和CLI設(shè)備進(jìn)行管理的方法，文章主要分析數(shù)據(jù)模型的轉(zhuǎn)換以及消息映射.文獻(xiàn)[11]提出了一種通用網(wǎng)關(guān)模型，實(shí)現(xiàn)基于XML網(wǎng)絡(luò)管理對(duì)SNMP代理和非SNMP代理的統(tǒng)一管理.在NETCONF協(xié)議的分析和應(yīng)用開發(fā)方面，文獻(xiàn)[12]通過實(shí)驗(yàn)分析證明了NETCONF在復(fù)雜網(wǎng)絡(luò)環(huán)境下的強(qiáng)大性能，實(shí)驗(yàn)結(jié)果顯示了NETCONF相對(duì)于SNMP和CLI，在網(wǎng)絡(luò)管理上更高效、更安全、擴(kuò)展性更強(qiáng)、更容易開發(fā)新的應(yīng)用.文獻(xiàn)[13]對(duì)NETCONF的三種建模語(yǔ)言XMLSchema、RelaxNG和YANG進(jìn)行了對(duì)比分析，得出盡管YANG是專門為NET-CONF設(shè)計(jì)的建模語(yǔ)言，但是仍然有些地方考慮不足，比如轉(zhuǎn)換工具設(shè)計(jì)得并不完善.上述文獻(xiàn)大多數(shù)停留在理論架構(gòu)階段，或者僅僅對(duì)某個(gè)單一功能進(jìn)行實(shí)現(xiàn)，例如文獻(xiàn)[8]提出的轉(zhuǎn)換器安全性不高，數(shù)據(jù)在傳輸過程中容易被劫取，而且使用的XML管理報(bào)文沒有形成統(tǒng)一規(guī)范.文獻(xiàn)[9-10]主要針對(duì)數(shù)據(jù)模型轉(zhuǎn)換，文獻(xiàn)[11]主要停留在管理消息轉(zhuǎn)換的架構(gòu)設(shè)計(jì)上，在實(shí)現(xiàn)方面只做了簡(jiǎn)單的描述.盡管NETCONF有眾多優(yōu)點(diǎn)，但是SNMP作為事實(shí)上的網(wǎng)絡(luò)管理工業(yè)標(biāo)準(zhǔn)有很多不可替代的特性，比如它的簡(jiǎn)易性、實(shí)用性，以及它對(duì)設(shè)備的實(shí)時(shí)監(jiān)控性優(yōu)于NET-CONF協(xié)議，這些決定了未來SNMP協(xié)議將長(zhǎng)期存在于網(wǎng)絡(luò)環(huán)境中，單純地將NETCONF應(yīng)用于物聯(lián)網(wǎng)不切實(shí)際.本文基于NETCONF協(xié)議，提出面向物聯(lián)網(wǎng)網(wǎng)絡(luò)管理的消息轉(zhuǎn)換機(jī)制，實(shí)現(xiàn)對(duì)SNMP的兼容，同時(shí)也考慮了對(duì)其他網(wǎng)絡(luò)管理協(xié)議的支持和系統(tǒng)的擴(kuò)展性，為物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò)設(shè)備的統(tǒng)一管理提供了參考.
3基于NETCONF網(wǎng)絡(luò)管理架構(gòu)
3.1基于NETCONF管理端
管理端一共包含3個(gè)模塊，如圖1所示，分別是交互界面、管理消息處理層、會(huì)話通信層.交互界面負(fù)責(zé)與管理員進(jìn)行信息交互.消息處理層是管理端的核心模塊，負(fù)責(zé)將管理消息封裝成基于NETCONF的管理報(bào)文，并傳送給會(huì)話通信層.另外還負(fù)責(zé)驗(yàn)證收到的報(bào)文格式，解析出操作結(jié)果.內(nèi)容層封裝是根據(jù)采用的數(shù)據(jù)模型對(duì)報(bào)文進(jìn)行封裝.操作層封裝、RPC封裝則根據(jù)用戶選擇的操作類型將報(bào)文封裝到相應(yīng)的RPC報(bào)文中去.會(huì)話通信層對(duì)應(yīng)NETCONF邏輯模型中傳輸層，負(fù)責(zé)將管理消息傳輸給消息轉(zhuǎn)換器，并等待消息轉(zhuǎn)換器的響應(yīng)，將響應(yīng)結(jié)果返回給消息處理層.【1】
3.2消息轉(zhuǎn)換器架構(gòu)
本文的消息轉(zhuǎn)換器基于WebService進(jìn)行通信.基于對(duì)XML的廣泛接受，WebService成為使用標(biāo)準(zhǔn)傳輸、編碼和協(xié)議來交換信息的應(yīng)用程序.選擇WebService作為管理端與消息轉(zhuǎn)換器之間報(bào)文的傳遞，符合在物聯(lián)網(wǎng)下網(wǎng)絡(luò)管理消息傳遞的特性要求，更容易實(shí)現(xiàn)跨平臺(tái)、跨設(shè)備、跨網(wǎng)絡(luò)對(duì)網(wǎng)絡(luò)設(shè)備的監(jiān)管.消息轉(zhuǎn)換器對(duì)發(fā)送過來的管理報(bào)文進(jìn)行相應(yīng)轉(zhuǎn)換，使得網(wǎng)絡(luò)管理端可以與不同類型的代理端進(jìn)行通信，消息轉(zhuǎn)換器以WebService的方式發(fā)布，實(shí)現(xiàn)與管理端交互，并且直接與物聯(lián)網(wǎng)環(huán)境下不同類型的代理進(jìn)行信息交互.消息轉(zhuǎn)換器的整體架構(gòu)如下頁(yè)圖2所示.主要分為三個(gè)功能模塊，即消息分類器SNMP，報(bào)文轉(zhuǎn)換模塊，其它代理報(bào)文轉(zhuǎn)換模塊.
3.2.1NETCONF-SNMP管理消息轉(zhuǎn)換負(fù)責(zé)將NETCONF管理報(bào)文轉(zhuǎn)換為SNMP管理報(bào)文的轉(zhuǎn)換器主要由6個(gè)模塊構(gòu)成，分別是請(qǐng)求分析器、MIB-XML翻譯器、XMLDOM、XML詢問器、trap處理模塊(由trap接收器、trap分析器和trap過濾器組成)以及報(bào)文生成器.請(qǐng)求分析器結(jié)合XMLSchema判斷管理報(bào)文的合法性，并且結(jié)合操作類型映射表提取操作類型.MIB-XML翻譯器負(fù)責(zé)將SMIMIB轉(zhuǎn)換為XML，轉(zhuǎn)換后的XML，可以實(shí)現(xiàn)查找操作對(duì)象對(duì)應(yīng)的OID，和操作對(duì)象的映射.XMLDOM是轉(zhuǎn)換器的核心，對(duì)XML文件進(jìn)行分析，將得到的設(shè)備地址、操作類型，操作對(duì)象OID等，傳給SNMP輪詢器，還負(fù)責(zé)接收trap，實(shí)現(xiàn)trap中參數(shù)映射后，傳遞給XML報(bào)文生成器.SNMP輪詢器將得到的參數(shù)包裝成SNMPPDU傳給SNMP代理，并且接受來自SNMP代理的響應(yīng).為了減少管理端與轉(zhuǎn)換器之間的通信流量，對(duì)SNMPtrap處理上采用過濾機(jī)制，trap處理器由3個(gè)模塊組成，將接收到的trap進(jìn)行分類，并建立分級(jí)制度來判斷緊急程度，最后過濾掉一些重復(fù)或者失效的trap報(bào)文，并傳遞給XMLDOM報(bào)文生成器生成相應(yīng)的響應(yīng)報(bào)文或通知報(bào)文后傳給NETCONF管理端.NETCONF-SNMP轉(zhuǎn)換器也可以實(shí)現(xiàn)對(duì)ANMP代理的兼容性，這在于ANMP使用與SNMP相同的PDU格式，而且同樣使用UDP作為傳輸協(xié)議來發(fā)送ANMP消息，在數(shù)據(jù)收集和控制方面，ANMP擴(kuò)展了SNMPMIB以便記錄AdHoc網(wǎng)絡(luò)特有的信息.若要對(duì)ANMP代理進(jìn)行管理，首先管理端載入對(duì)應(yīng)的MIB文件，消息分類器判斷管理報(bào)文中的IP地址，若對(duì)應(yīng)的是ANMP代理時(shí)，將管理報(bào)文傳給轉(zhuǎn)換器，可以實(shí)現(xiàn)對(duì)ANMP代理對(duì)應(yīng)設(shè)備的有效管理.
3.2.2對(duì)其他網(wǎng)絡(luò)管理協(xié)議的支持考慮到物聯(lián)網(wǎng)環(huán)境下存在少量其他網(wǎng)絡(luò)管理協(xié)議，本文加入了一種支持其他網(wǎng)絡(luò)管理協(xié)議的理論構(gòu)架，下面對(duì)這種架構(gòu)進(jìn)行闡述.如圖2所示，架構(gòu)主要有四部分組成，分別是數(shù)據(jù)表、適配器、消息產(chǎn)生器、Trap接收器.其中三個(gè)數(shù)據(jù)表和三個(gè)適配器是架構(gòu)的關(guān)鍵，設(shè)備信息表記錄代理的相關(guān)信息，用以區(qū)分管理端與哪個(gè)代理通信;私有數(shù)據(jù)表將NETCONF的屬性映射為代理的私有屬性;操作表則將NETCONF的操作類型映射為代理的私有操作類型.報(bào)文適配器實(shí)現(xiàn)報(bào)文格式對(duì)應(yīng);傳輸適配器負(fù)責(zé)轉(zhuǎn)換器與多種代理進(jìn)行通信;trap適配器則負(fù)責(zé)代理如何主動(dòng)與管理端進(jìn)程通信，通知管理進(jìn)程有某些事情發(fā)生.【2】
當(dāng)管理端與代理通信時(shí)，轉(zhuǎn)換器首先載入該代理的XML配置文件，生成三個(gè)數(shù)據(jù)表，分別是設(shè)備信息表、操作類型表、私有數(shù)據(jù)表.通過數(shù)據(jù)表生成上述三個(gè)適配器的具體實(shí)現(xiàn)，適配管理器負(fù)責(zé)初始化適配器并在合適的時(shí)候調(diào)用適配器.在適配管理器的協(xié)調(diào)下，消息產(chǎn)生器就能將管理端傳遞過來的NETCONF配置報(bào)文通過適配器轉(zhuǎn)化為代理能夠識(shí)別的PDU，返回的PDU也能通過管理消息產(chǎn)生器轉(zhuǎn)換為基于NETCONF的響應(yīng)報(bào)文.
3.3代理端架構(gòu)設(shè)計(jì)
目前Cisco，Juniper等網(wǎng)絡(luò)設(shè)備生產(chǎn)商都實(shí)現(xiàn)了基于RFC4741的代理，并嵌入到了它們最新的路由器當(dāng)中.NETCONF采用XML進(jìn)行數(shù)據(jù)傳輸和模塊表達(dá)，具有較強(qiáng)的可擴(kuò)展性，網(wǎng)絡(luò)設(shè)備提供商可以使用此協(xié)議獲取、設(shè)置所有的配置數(shù)據(jù)，適合物聯(lián)網(wǎng)下的不同類型設(shè)備快速添加和高效管理.這些功能很大一部分依賴于代理端的實(shí)現(xiàn)，如何將基1對(duì)其進(jìn)行網(wǎng)絡(luò)管理是一個(gè)迫切需要解決的問題，這關(guān)系到NETCONF在物聯(lián)網(wǎng)網(wǎng)絡(luò)管理的生命力.本文將代理分為三種類型，分別是SNMP代理、NETCONF代理和其他代理.本節(jié)結(jié)合物聯(lián)網(wǎng)的特征分析了NETCONF代理架構(gòu)設(shè)計(jì)，按照RFC4741中規(guī)定，一個(gè)基本的NETCONF代理分四層結(jié)構(gòu)來設(shè)計(jì).另外代理必須完成對(duì)能力特性、三種數(shù)據(jù)庫(kù)狀態(tài)和事件通知的支持，基于NETCONF的代理架構(gòu)如圖3所示.【3】
會(huì)話通信層負(fù)責(zé)與管理端交互，代理端啟動(dòng)后會(huì)監(jiān)聽來自管理端的管理消息.消息處理器接受來自會(huì)話通信層的管理消息后，能夠解析出操作類型和操作對(duì)象并傳給操作處理器，也能將操作處理器操作后的結(jié)果封裝成基于NETCONF的響應(yīng)報(bào)文.操作處理器執(zhí)行消息處理器解析出來的具體操作.管理對(duì)象信息庫(kù)中配置信息狀態(tài)分為3個(gè)階段，對(duì)應(yīng)3種數(shù)據(jù)庫(kù)狀態(tài):運(yùn)行狀態(tài)(running)、啟動(dòng)狀態(tài)(startup)和候選狀態(tài)(candidate).能力(capabilities)是NETCONF的新特性，這種特性允許客戶端發(fā)現(xiàn)服務(wù)端支持的協(xié)議擴(kuò)展集，“能力”的提出豐富了基本操作集，增加新的操作使代理端擴(kuò)展性得到提高.被管理設(shè)備將能力集傳遞給管理數(shù)據(jù)庫(kù)存儲(chǔ)，在管理端發(fā)出“HELLO”報(bào)文后，傳遞給管理端以告知管理端被管設(shè)備支持的協(xié)議擴(kuò)展集.通知(Notification)模塊負(fù)責(zé)將被管理設(shè)備主動(dòng)發(fā)出的消息傳遞給消息處理器，再由消息處理器封裝后，通過會(huì)話通信層傳遞給管理端.本文并沒有將重點(diǎn)放在討論“能力”和“通知”這種兩種特性上，但這兩種特性對(duì)于將NETCONF應(yīng)用到物聯(lián)網(wǎng)環(huán)境中至關(guān)重要，因?yàn)槲锫?lián)網(wǎng)環(huán)境需要“能力”來支持可擴(kuò)展性，“通知”來支持對(duì)被管設(shè)備的實(shí)時(shí)監(jiān)控，這也是我們未來工作討論的重點(diǎn).
4轉(zhuǎn)換算法流程設(shè)計(jì)
4.1數(shù)據(jù)模型分析
與SNMP相比，NETCONF是一個(gè)全新的XML配置管理協(xié)議.NETCONF協(xié)議在概念上分為四層，分別是內(nèi)容層、操作層、RPC層和傳輸協(xié)議層.目前操作層、RPC層、傳輸協(xié)議層都有相應(yīng)的標(biāo)準(zhǔn)和規(guī)范，內(nèi)容層并沒有給出具體要求，允許單獨(dú)定義NETCONF數(shù)據(jù)模型，使得它的靈活性增強(qiáng)，但是另一方面也阻礙了NETCONF的廣泛應(yīng)用，數(shù)據(jù)模型定義與傳統(tǒng)數(shù)據(jù)模型的轉(zhuǎn)換是目前各大國(guó)際化標(biāo)準(zhǔn)研究的重點(diǎn)和熱點(diǎn).2009年，NETMOD工作組提出將YANG[14]作為標(biāo)準(zhǔn)的NET-CONF數(shù)據(jù)建模方法目前還處于討論和驗(yàn)證中.現(xiàn)有的數(shù)據(jù)模型語(yǔ)言，如XMLSchemaDefinition(XSD)和RelaxNG可以用于其數(shù)據(jù)模型.正因?yàn)镹ETCONF基于XML，所以XSD是其一種比較理想的選擇，本文也是采用XSD作為數(shù)據(jù)建模語(yǔ)言來開展實(shí)驗(yàn).IETF組織，特別是NETCONF工作組將XMLSchema列入考慮之中.【4】
德國(guó)開發(fā)的LIBSMI[15]是比較成功的案例，得到了廣泛的認(rèn)可，它將MIB樹轉(zhuǎn)換為公認(rèn)較好的四層結(jié)構(gòu)，如圖4所示.前兩層與具體MIB無(wú)關(guān)，只有下兩層才依賴于具體MIB，第三層為表結(jié)點(diǎn)的ENTRY結(jié)點(diǎn)，或者是標(biāo)量結(jié)點(diǎn)的容器結(jié)點(diǎn)，第四層是葉子結(jié)點(diǎn).對(duì)于非MIB樹形式的管理對(duì)象也可以建立這樣的四層結(jié)構(gòu)模型，這樣統(tǒng)一了網(wǎng)絡(luò)被管對(duì)象的描述.本文在實(shí)驗(yàn)中便采用了該四層結(jié)構(gòu)來規(guī)范管理對(duì)象數(shù)據(jù).
4.2關(guān)鍵類設(shè)計(jì)
為了實(shí)現(xiàn)基于XML的NETCONF報(bào)文到SNMP報(bào)文的轉(zhuǎn)換，需要對(duì)NETCONF報(bào)文進(jìn)行解析.基于第2節(jié)中的轉(zhuǎn)換器架構(gòu)，本文設(shè)計(jì)的關(guān)鍵類有:ParseXML類、XmlDocument類、Oper-ations類以及UdpTarget類，關(guān)鍵類圖如圖5所示.ParseXML類用于對(duì)NETCONF報(bào)文進(jìn)行解析，其實(shí)現(xiàn)依賴于其他三個(gè)關(guān)鍵類;XmlDocument類主要用來提取基于XML的NETCONF報(bào)文的關(guān)鍵信息，如設(shè)備IP地址、操作對(duì)象OID、操作類型等;Operations類提供三種基本SNMP操作:GetRequest、GetBulkRequest和SetRequest，這為實(shí)現(xiàn)SNMP的基本功能提供了可能;UdpTarget類主要用來構(gòu)造SNMPPDU，并依據(jù)具體操作發(fā)送相應(yīng)SNMP請(qǐng)求報(bào)文.
5實(shí)驗(yàn)與分析
5.1實(shí)驗(yàn)環(huán)境和參數(shù)
采用VisualStudio2010作為開發(fā)平臺(tái)，編程語(yǔ)言是C#.實(shí)驗(yàn)選擇了四臺(tái)機(jī)器，一臺(tái)機(jī)器作為基于NETCONF的網(wǎng)絡(luò)管理端，一臺(tái)機(jī)器作為報(bào)文轉(zhuǎn)換器，一臺(tái)機(jī)器作為SNMP代理，一臺(tái)作為NETCONF代理，SNMP代理端和NETCONF代理端分別通過RS232與匯聚節(jié)點(diǎn)相連，通過USB與和RFID讀卡器相連，匯聚節(jié)點(diǎn)通過ZigBee協(xié)議與靜態(tài)節(jié)點(diǎn)相連.實(shí)驗(yàn)環(huán)境如圖7(見下頁(yè))所示.
5.2運(yùn)行實(shí)例
本文選取SNMP代理和NETCONF代理進(jìn)行實(shí)驗(yàn)，目標(biāo)是通過基于NETCONF管理端是獲取設(shè)備的sysUpTime.點(diǎn)擊“importobjectofmanagement”，管理對(duì)象以樹形結(jié)構(gòu)顯示在對(duì)象瀏覽器窗口中選擇管理設(shè)備.輸入代理的IP地址再分別選擇操作類型，數(shù)據(jù)庫(kù)狀態(tài)，操作對(duì)象，點(diǎn)擊“cre-ateMessage”，管理端產(chǎn)生基于NETCONF管理報(bào)文并顯示在發(fā)送窗口中.點(diǎn)擊“sendMessage”，發(fā)送報(bào)文，等待轉(zhuǎn)換器響應(yīng)后，響應(yīng)報(bào)文顯示在報(bào)文接收窗口中.若對(duì)應(yīng)的是SNMP代理，接收窗口直接顯示結(jié)果，發(fā)送報(bào)文以及返回報(bào)文如圖8(見下頁(yè))所示.若對(duì)應(yīng)的是NETCONF代理，接收窗口顯示基于NET-CONF的rpc-reply報(bào)文，發(fā)送報(bào)文及返回報(bào)文如圖9所示.若對(duì)應(yīng)的是NETCONF代理并且發(fā)送報(bào)文缺少message-id，則返回基于NETCONF的rpc-error報(bào)文，封裝在rpc-reply中，發(fā)送和返回的報(bào)文如圖10所示.
5.3實(shí)驗(yàn)分析結(jié)果與改進(jìn)
圖11和圖12分別表示系統(tǒng)測(cè)試20組，每組100次隨機(jī)get-config操作的響應(yīng)時(shí)間比較.測(cè)試的響應(yīng)時(shí)間類型分別是響應(yīng)總時(shí)間Tall、管理端到轉(zhuǎn)換器傳輸時(shí)間TMT、轉(zhuǎn)換器處理時(shí)間TTR、轉(zhuǎn)換器到代理端響應(yīng)時(shí)間TTA.本文在測(cè)試時(shí)，第一次響應(yīng)時(shí)間作為特例不考慮，這是因?yàn)檗D(zhuǎn)換器以Web服務(wù)的方式發(fā)布，通過TCP三次握手與管理端建立連接，而轉(zhuǎn)換器與代理之間通過UDP通信，UDP不需要建立連接.由圖11和圖12可知，四種類型響應(yīng)時(shí)間在一個(gè)相對(duì)穩(wěn)定的區(qū)間內(nèi)波動(dòng)，但是Tall和TMT明顯高于TTR和TTA.經(jīng)過分析，這主要是因?yàn)閮煞矫嬖�，首先基于TCP的報(bào)文傳輸時(shí)間明顯高于基于UDP的報(bào)文傳輸時(shí)間，另外在包的大小方面，基于NETCONF的管理端發(fā)送的是XML報(bào)文，相對(duì)于SNMP只需變量綁定要復(fù)雜.圖12表示的是管理端發(fā)送的報(bào)文與經(jīng)過轉(zhuǎn)換后的報(bào)文大小的變化比較，實(shí)驗(yàn)只考慮TCP或UDP報(bào)文段的數(shù)據(jù)部分.
本文測(cè)試用mib-2中前8個(gè)基本對(duì)象組，對(duì)于MIB樹中非葉子結(jié)點(diǎn)的實(shí)例，轉(zhuǎn)換器自動(dòng)調(diào)用GetBulkOperation與代理交互.由圖13可知，NETCONF管理端的管理報(bào)文大小幾乎是穩(wěn)定不變的，通過轉(zhuǎn)換器轉(zhuǎn)換后的SNMP管理報(bào)文大小的變化波動(dòng)相對(duì)較大.通過分析，這主要因?yàn)榭紤]到8個(gè)基本對(duì)象組中標(biāo)量對(duì)象的個(gè)數(shù)不盡相同，權(quán)衡代理的處理時(shí)間和轉(zhuǎn)換后報(bào)文數(shù)量后，實(shí)驗(yàn)將SNMPv2GetBulk報(bào)文的NonRepeaters字段設(shè)置為0，MaxRepetitions字段設(shè)置為20，對(duì)于標(biāo)量對(duì)象大于20的對(duì)象組需要發(fā)送多個(gè)GetBulk請(qǐng)求.今后這部分可以優(yōu)化，根據(jù)實(shí)際需要自動(dòng)生成這兩個(gè)參數(shù)來減少轉(zhuǎn)換后的報(bào)文大小.測(cè)試轉(zhuǎn)換前后報(bào)文大小變化為今后轉(zhuǎn)化器位置部署提供了參考.圖13(見上頁(yè))表示的是隨機(jī)產(chǎn)生20組，每組10000次管理報(bào)文得到正確響應(yīng)報(bào)文的成功率，失敗的操作將會(huì)返回錯(cuò)誤類型.通過實(shí)驗(yàn)發(fā)現(xiàn)兩種操作的成功率穩(wěn)定在99.4%以上，通過返回的錯(cuò)誤類型發(fā)現(xiàn)，失敗與否主要與當(dāng)前網(wǎng)絡(luò)和系統(tǒng)狀況有關(guān).get-congfig操作的成功率總體上高于edit-config的成功率，這是因?yàn)榕渲貌僮飨鄬?duì)于取值操作受限更多.實(shí)驗(yàn)選擇了響應(yīng)時(shí)間、報(bào)文大小變化、成功率來評(píng)價(jià)系統(tǒng)的性能.實(shí)驗(yàn)主要考慮的是NETCONF管理端與SNMP代理的兼容性，數(shù)據(jù)模型采用的是在4.1節(jié)介紹的基于XML的四層結(jié)構(gòu)，即將MIB-2庫(kù)通過smidump轉(zhuǎn)換成實(shí)驗(yàn)所需要的模型.實(shí)驗(yàn)過程中還發(fā)現(xiàn)，在轉(zhuǎn)換過程中存在MIB樹中間結(jié)點(diǎn)丟失的情況，由此可見轉(zhuǎn)換MIB信息表達(dá)效率不夠精確.
6結(jié)論
為了在物聯(lián)網(wǎng)環(huán)境中部署一種基于NETCONF的統(tǒng)一網(wǎng)絡(luò)管理系統(tǒng)，考慮到當(dāng)前SNMP在配置性能、安全性和擴(kuò)展性方面的不足，以及SMI語(yǔ)法復(fù)雜和靈活性差等問題，文章提出了面向物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò)管理消息轉(zhuǎn)換機(jī)制，它能夠自適應(yīng)地對(duì)各種設(shè)備進(jìn)行管理，特別是將這種轉(zhuǎn)換機(jī)制通過WebService的方式提供給管理端，在安全性、可擴(kuò)展性、配置效率上有很大程度提高.本文還提出了管理端、轉(zhuǎn)換器、代理端的設(shè)計(jì)架構(gòu)，通過實(shí)驗(yàn)驗(yàn)證了系統(tǒng)對(duì)SNMP代理的兼容性，能夠?qū)NMP設(shè)備進(jìn)行有效管理.未來工作中我們將研究重點(diǎn)集中在數(shù)據(jù)模型、可擴(kuò)展性、被管設(shè)備監(jiān)控性能優(yōu)化三個(gè)方面，最終實(shí)現(xiàn)物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò)設(shè)備的統(tǒng)一高效管理.
【面向物聯(lián)網(wǎng)環(huán)境的網(wǎng)絡(luò)設(shè)備消息轉(zhuǎn)換機(jī)制分析】相關(guān)文章：
無(wú)線通信技術(shù)與物聯(lián)網(wǎng)技術(shù)分析論文09-18
聯(lián)網(wǎng)審計(jì)的利弊分析08-24
分析物聯(lián)網(wǎng)技術(shù)在電力智能在線監(jiān)測(cè)的應(yīng)用08-20
MFC中消息映射機(jī)制分析08-18
物聯(lián)網(wǎng)安全機(jī)制淺析09-08
基于物聯(lián)網(wǎng)環(huán)境下的供應(yīng)鏈庫(kù)存管理研究論文10-20
物聯(lián)網(wǎng)營(yíng)銷“未來派”08-04