面向物聯網環境的網絡設備消息轉換機制分析

面向物聯網環境的網絡設備消息轉換機制分析

　　物聯網在當前互聯網的基礎上有了許多新的特點，因此對于物聯網網絡管理提出了新的需求，下面是小編搜集的一篇相關論文范文，歡迎閱讀借鑒。

　　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設備進行有效管理.未來工作中我們將研究重點集中在數據模型、可擴展性、被管設備監控性能優化三個方面，最終實現物聯網環境下網絡設備的統一高效管理.

【面向物聯網環境的網絡設備消息轉換機制分析】相關文章：

無線通信技術與物聯網技術分析論文09-18

聯網審計的利弊分析08-24

分析物聯網技術在電力智能在線監測的應用08-20

MFC中消息映射機制分析08-18

物聯網安全機制淺析09-08

基于物聯網環境下的供應鏈庫存管理研究論文10-20

物聯網營銷“未來派”08-04

面向對象的液壓系統分析研究09-13

互聯網電視技術與運營分析08-06

DSP技術推動智能物聯網發展09-28