1 引 言

物聯網在當前互聯網的基礎上有了許多新的特點，因此對于物聯網網絡管理提出了新的需求． ISO 定義的網絡管理 5個系統管理功能在物聯網時代難以滿足新的需求，傳統的基于簡單網絡管理協議\\( SNMP，Simple Network Management Pro-tocol\\) 的網絡管理系統，不管在擴展性方面還是管理效率方面的局限性日益突出，因此迫切需要新的網絡管理系統模型．可擴展標記語言［1］\\( XML，eXtensible Markup Language\\)的出現為構建物聯網環境下的網絡管理模型提供了可能． 基于 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］提出一種 SNMP MIB 到 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 的三種建模語言 XML Schema、Relax NG和 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 消息轉換器架構

本文的消息轉換器基 于 Web Service進 行 通 信． 基 于 對XML 的 廣 泛 接 受，Web Service 成 為 使用標準傳輸、編碼和協議來交換信息的應用 程 序． 選 擇 WebService 作為管理端與消息轉換器之間報文的傳遞，符合在物聯網下網絡管理消息傳遞的特性要求，更容易實現跨平臺、跨設備、跨網絡對網絡設備的監管．消息轉換器對發送過來的管理報文進行相應轉換，使得網絡管理端可以與不同類型的代理端進行通信，消息轉換器以 Web Service 的方式發布，實現與管理端交互，并且直接與物聯網環境下不同類型的代理進行信息交互．消息轉換器的整體架構如下頁圖 2 所示． 主要分為三個功能模塊，即消息分類器 SNMP，報文轉換模塊，其它代理報文轉換模塊．

3． 2． 1 NETCONF-SNMP 管理消息轉換負責將 NETCONF 管理報文轉換為 SNMP 管理報文的轉換器主要由 6 個模塊構成，分別是請求分析器、MIB-XML 翻譯器、XML DOM、XML 詢問器、trap 處理模塊\\( 由 trap 接收器、trap 分析器和 trap 過濾器組成\\) 以及報文生成器．請求分析器結合 XML Schema 判斷管理報文的合法性，并且結合操作類型映射表提取操作類型． MIB-XML 翻譯器負責將 SMI MIB 轉換為 XML，轉換后的 XML，可以實現查找操作對象對應的 OID，和操作對象的映射． XML DOM 是轉換器的核心，對 XML 文件進行分析，將得到的設備地址、操作類型，操作對象 OID 等，傳給 SNMP 輪詢器，還負責接收 trap，實現 trap 中參數映射后，傳遞給 XML 報文生成器． SNMP 輪詢器將得到的參數包裝成 SNMP PDU 傳給 SNMP 代理，并且接受來自 SNMP 代理的響應． 為了減少管理端與轉換器之間的通信流量，對 SNMP trap 處理上采用過濾機制，trap 處理器由3 個模塊組成，將接收到的 trap 進行分類，并建立分級制度來判斷緊急程度，最后過濾掉一些重復或者失效的 trap 報文，并傳遞給 XML DOM 報文生成器生成相應的響應報文或通知報文后傳給 NETCONF 管理端．NETCONF-SNMP 轉換器也可以實現對 ANMP 代理的兼容性，這在于 ANMP 使用與 SNMP 相同的 PDU 格式，而且同樣使用 UDP 作為傳輸協議來發送 ANMP 消息，在數據收集和控制方面，ANMP 擴展了 SNMP MIB 以便記錄 Ad Hoc 網絡特有的信息． 若要對 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\\) 、啟動狀態\\( start up\\) 和候選狀態\\( candidate\\) ． 能力\\( capabilities\\) 是 NETCONF 的新特性，這種特性允許客戶端發現服務端支持的協議擴展集，“能力”的提出豐富了基本操作集，增加新的操作使代理端擴展性得到提高． 被管理設備將能力集傳遞給管理數據庫存儲，在管理端發出“HELLO”報文后，傳遞給管理端以告知管理端被管設備支持的協議擴展集． 通知\\( Notification\\) 模塊負責將被管理設備主動發出的消息傳遞給消息處理器，再由消息處理器封裝后，通過會話通信層傳遞給管理端．本文并沒有將重點放在討論“能力”和“通知”這種兩種特性上，但這兩種特性對于將 NETCONF 應用到物聯網環境中至關重要，因為物聯網環境需要“能力”來支持可擴展性，“通知”來支持對被管設備的實時監控，這也是我們未來工作討論的重點．

4 轉換算法流程設計

4． 1 數據模型分析

與 SNMP 相比，NETCONF 是一個全新的 XML 配置管理協議． NETCONF 協議在概念上分為四層，分別是內容層、操作層、RPC 層和傳輸協議層． 目前操作層、RPC 層、傳輸協議層都有相應的標準和規范，內容層并沒有給出具體要求，允許單獨定義 NETCONF 數據模型，使得它的靈活性增強，但是另一方面也阻礙了 NETCONF 的廣泛應用，數據模型定義與傳統數據模型的轉換是目前各大國際化標準研究的重點和熱點．2009 年，NETMOD 工作組提出將 YANG［14］作為標準的 NET-CONF 數據建模方法目前還處于討論和驗證中． 現有的數據模型語言，如 XML Schema Definition\\( XSD\\) 和 Relax NG 可以用于其數據模型． 正因為 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 請求報文．

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”，管理對象以樹形結構顯示在對象瀏覽器窗口中選擇管理設備． 輸入代理的 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 個基本對象組中標量對象的個數不盡相同，權衡代理的處理時間和轉換后報文數量后，實驗將 SNMPv2 GetBulk 報文的 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 設備進行有效管理．未來工作中我們將研究重點集中在數據模型、可擴展性、被管設備監控性能優化三個方面，最終實現物聯網環境下網絡設備的統一高效管理．