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)容層并沒(mé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)的NETCONF數(shù)據(jù)建模方法目前還處于討論和驗(yàn)證中.現(xiàn)有的數(shù)據(jù)模型語(yǔ)言,如XML Schema Definition(XSD)和Relax NG可以用于其數(shù)據(jù)模型.正因?yàn)镹ETCONF基于XML,所以XSD是其一種比較理想的選擇,本文也是采用XSD作為數(shù)據(jù)建模語(yǔ)言來(lái)開(kāi)展實(shí)驗(yàn).IETF組織,特別是NETCONF工作。

ParseXML類(lèi)用于對(duì)NETCONF報(bào)文進(jìn)行解析,其實(shí)現(xiàn)依賴于其他三個(gè)關(guān)鍵類(lèi);XmlDocument類(lèi)主要用來(lái)提取基于XML的 NETCONF報(bào)文的關(guān)鍵信息,如設(shè)備P地址.操作對(duì)象OID、操作類(lèi)型等;Operations類(lèi)提供三種基本SNMP操作:GetRequest、GetBulkRequest和SetRequest，這為實(shí)現(xiàn)SNMP的基本功能提供了可能;UdpTarget類(lèi)主要用來(lái)構(gòu)造SNMP PDU,并依據(jù)具體操作發(fā)送相應(yīng)SNMP請(qǐng)求報(bào)文.4.3轉(zhuǎn)換算法流程設(shè)計(jì)

轉(zhuǎn)換流程如圖6(見(jiàn)下頁(yè))所示.5實(shí)驗(yàn)與分析

5.1實(shí)驗(yàn)環(huán)境和參數(shù)

采用Visual Studio 2010作為開(kāi)發(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代理端分別通過(guò)RS232與匯聚節(jié)點(diǎn)相連,通過(guò)USB與和RFID讀卡器相連,匯聚節(jié)點(diǎn)通過(guò)ZigBee 協(xié)議與靜態(tài)節(jié)點(diǎn)相連.實(shí)驗(yàn)環(huán)境如圖7(見(jiàn)下頁(yè))所示.

5.2運(yùn)行實(shí)例

本文選取SNMP代理和NETCONF代理進(jìn)行實(shí)驗(yàn),目標(biāo)是通過(guò)基于NETCONF管理端是獲取設(shè)備的sysUpTime.

點(diǎn)擊“ import object of management”,管理對(duì)象以樹(shù)形結(jié)構(gòu)顯示在對(duì)象瀏覽器窗口中選擇管理設(shè)備.輸入代理的P地址再分別選擇操作類(lèi)型,數(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(見(jiàn)下頁(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ā)物聯(lián)網(wǎng)網(wǎng)關(guān)

送和返回的報(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í)間類(lèi)型分別是響應(yīng)總時(shí)間Ta﹑管理端到轉(zhuǎn)換器傳輸時(shí)間工轉(zhuǎn)換器處理時(shí)可知,四種類(lèi)型響應(yīng)時(shí)間在一個(gè)相對(duì)穩(wěn)定的區(qū)間內(nèi)波動(dòng),但是間TR 、轉(zhuǎn)換器到代理端響應(yīng)時(shí)間TTA.本文在測(cè)試時(shí),第一次Tan和Tan明顯高于Tn和TT,.經(jīng)過(guò)分析,這主要是因?yàn)閮煞矫骓憫?yīng)時(shí)間作為特例不考慮,這是因?yàn)檗D(zhuǎn)換器以Web服務(wù)的方原因,首先基于TCP的報(bào)文傳輸時(shí)間明顯高于基于UDP的報(bào)式發(fā)布,通過(guò)TCP三次握手與管理端建立連接,而轉(zhuǎn)換器與代文傳輸時(shí)間,另外在包的大小方面,基于NETCONF的管理端理之間通過(guò)UDP通信,UDP不需要建立連接.由圖11和圖12發(fā)送的是XML報(bào)文,相對(duì)于SNMP只需變量綁定要復(fù)雜。

圖12表示的是管理端發(fā)送的報(bào)文與經(jīng)過(guò)轉(zhuǎn)換后的報(bào)文葉子結(jié)點(diǎn)的實(shí)例,轉(zhuǎn)換器自動(dòng)調(diào)用GetBulkOperation與代理大小的變化比較,實(shí)驗(yàn)只考慮TCP或UDP報(bào)文段的數(shù)據(jù)部交互.由圖13可知, NETCONF管理端的管理報(bào)文大小幾乎分.本文測(cè)試用mib-2中前8個(gè)基本對(duì)象組,對(duì)于MIB樹(shù)中非是穩(wěn)定不變的,通過(guò)轉(zhuǎn)換器轉(zhuǎn)換后的SNMP管理報(bào)文大小的

變化波動(dòng)相對(duì)較大.通過(guò)分析,這主要因?yàn)榭紤]到8個(gè)基本對(duì)象組中標(biāo)量對(duì)象的個(gè)數(shù)不盡相同,權(quán)衡代理的處理時(shí)間和轉(zhuǎn)換后報(bào)文數(shù)量后,實(shí)驗(yàn)將SNMPv2 GetBulk報(bào)文的NonRe-peaters字段設(shè)置為0, MaxRepetitions字段設(shè)置為20,對(duì)于標(biāo)量對(duì)象大于20的對(duì)象組需要發(fā)送多個(gè)GetBulk請(qǐng)求.今后這部分可以優(yōu)化,根據(jù)實(shí)際需要自動(dòng)生成這兩個(gè)參數(shù)來(lái)減少轉(zhuǎn)換后的報(bào)文大小.測(cè)試轉(zhuǎn)換前后報(bào)文大小變化為今后轉(zhuǎn)化器位置部署提供了參考.

圖13(見(jiàn)上頁(yè))表示的是隨機(jī)產(chǎn)生20組,每組10000次管理報(bào)文得到正確響應(yīng)報(bào)文的成功率,失敗的操作將會(huì)返回錯(cuò)誤類(lèi)型.通過(guò)實(shí)驗(yàn)發(fā)現(xiàn)兩種操作的成功率穩(wěn)定在99.4%以上,通過(guò)返回的錯(cuò)誤類(lèi)型發(fā)現(xiàn),失敗與否主要與當(dāng)前網(wǎng)絡(luò)和系統(tǒng)狀況有關(guān). get-congfig 操作的成功率總體上高于edit-config的成功率,這是因?yàn)榕渲貌僮飨鄬?duì)于取值操作受限更多.物聯(lián)網(wǎng)網(wǎng)關(guān)

實(shí)驗(yàn)選擇了響應(yīng)時(shí)間、報(bào)文大小變化、成功率來(lái)評(píng)價(jià)系統(tǒng)的性能.實(shí)驗(yàn)主要考慮的是NETCONF管理端與SNMP代理的兼容性,數(shù)據(jù)模型采用的是在4.1節(jié)介紹的基于XML的四層結(jié)構(gòu),即將MIB-2庫(kù)通過(guò)smidump轉(zhuǎn)換成實(shí)驗(yàn)所需要的模型.實(shí)驗(yàn)過(guò)程中還發(fā)現(xiàn),在轉(zhuǎn)換過(guò)程中存在MIB樹(shù)中間結(jié)點(diǎn)丟失的情況,由此可見(jià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ù)雜和靈活性差等問(wèn)題,文章提出了面向物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò)管理消息轉(zhuǎn)換機(jī)制,它能夠自適應(yīng)地對(duì)各種設(shè)備進(jìn)行管理,特別是將這種轉(zhuǎn)換機(jī)制通過(guò)web Service的方式提供給管理端,在安全性、可擴(kuò)展性﹑配置效率上有很大程度提高.本文還提出了管理端、轉(zhuǎn)換器、代理端的設(shè)計(jì)架構(gòu),通過(guò)實(shí)驗(yàn)驗(yàn)證了系統(tǒng)對(duì)SNMP代理的兼容性,能夠?qū)NMP設(shè)備進(jìn)行有效管理.

未來(lái)工作中我們將研究重點(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)一高效管理.

關(guān)鍵詞：物聯(lián)網(wǎng)網(wǎng)關(guān)