支持網絡動態重構的可信構件模型

袁博，汪斌強，馬東超

(1. 國家數字交換系統工程技術研究中心，河南 鄭州 450002；2. 北方工業大學 信息工程學院，北京 100041)

1 引言

隨著網絡規模不斷擴大，大量的個性化業務應用向規模化應用轉化，傳統的網絡體系結構已不能很好地適應這種發展趨勢。可重構柔性網絡是解決此類問題的一個重要方法，它的理論根源在于動態地改變網絡的服務能力使之追隨用戶業務需求的變化，通過將網絡基礎設施的物理資源服務能力和服務提供商的業務承載能力相分離，以構建可重構服務承載網的形式，快速、靈活和高效地為用戶提供網絡服務。物理網絡為可重構服務承載網提供網絡資源，不同的可重構服務承載網具有不同的服務能力，從而在共享由不同基礎設施提供商提供的底層物理網絡資源的基礎上，能同時支持多個服務特征不同的異質網絡體系結構并存，為用戶提供多樣化的網絡服務[1,2]。這種網絡得以實現的關鍵是將底層網絡服務與用戶業務松耦合，網絡節點的軟硬件資源也需要被合理的分割。節點設備構件化便是上述機制的一種物理映射，為此需要一種支持重構的構件模型。因為軟件和硬件在重構機制的實現上存在區別，本文主要研究的是節點設備控制平面軟件領域的構件模型。

傳統的構件模型設計時考慮的軟件運行環境是靜態的，即使考慮到運行環境變化也是基于對未來的預測，不能夠支持可重構環境中大量未知構件的動態植入和卸載。要支持構件的靈活重構，軟件工程層面應該提供一種便于構件重構的構件模型和管理機制，構件模型應該具有感知、決策和執行的能力。即在感知到運行環境或構件發生變化后，構件模型做出相應決策，進而執行方法調用、參數改變或者結構調整等動作。可重構環境中構件的動態植入和卸載會帶來很多安全方面的不確定性因素，為保證軟件系統的安全性，構件模型還必須為外來構件提供可信交互機制，對構件交互信息進行可信封裝，保證任意一個構件的行為和數據不會影響到其他構件和系統環境。在構件重構后還應保證新結構下構件間的可信交互。

針對上述挑戰，本文提出了一種可信構件模型(TCM, trustworthy component model)。TCM包括構件代理、容器和行為構件，使用構件代理(CA,component agent)可完成決策和重構部署，利用AC(agent client)可完成構件間的可信交互。在構件組裝層面引入具有感知功能的容器可隔離底層操作系統的影響，從而實現感知、決策和執行這3個功能的獨立表達和封裝，同時在容器中實現構件數據的可信封裝。在此基礎上，TCM使用動態軟件體系結構(DSA, dynamic software architecture)技術[3]實現構件連接關系的重構。上述機制一方面使第三方構件可以通過AC實現與軟件體系結構的松耦合而被靈活地植入和卸載，另一方面構件代理可以對模型下的構件進行管理，保證軟件構件系統的靈活重構和可信。

2 相關研究工作

構件的插拔與替換是基于構件的軟件工程(CBSE, component based software engineering)中的基本手段之一。在基于構件的軟件設計階段，設計的逐步求精可視為抽象度高的構件不斷被更細化的構件替換的過程；在構件的獲取階段，構件的檢索可視為檢索者所需的構件由構件庫中的具體構件所替換的過程；在構件的組裝階段，通過構件的替換可支持系統的靈活重構；在軟件運行階段，構件替換是支持系統升級、維護和演化的主要手段[4]。近年來興起的網構軟件，可通過服務構件的動態替換和編排機制實現網上服務的按需計算，呈現更強的動態性和演化性[5]。構件的替換已成為CBSE領域近年來研究的核心和熱點問題之一，但是目前還未提出可以支持構件靈活重構的構件模型。

軟件適應領域[6]的研究者已經認識到構件接口的功能分離原則在軟件適應能力調整中的重要性。較為常見的實現方法是使用策略、規則等手段來單獨描述軟件適應的決策邏輯，然后通過對決策邏輯的更新來調整適應能力。文獻[7]給出了一個實現軟件自適應的規則模型。Chisel[8]面向完全不可預期的動態變化，使用策略來描述適應邏輯，通過對策略的動態更新來為軟件添加新的適應能力；K-Component通過適應契約描述語言(ACDL)來描述適應邏輯，實現體系結構在線變化過程中的功能點分離[9]；MADAM區分功能實現和適應性行為使能2個功能點，通過構件的附加屬性、效用函數等來支持軟件的適應動作[10]。上述方法均只強調決策邏輯從軟件功能實現中分離，而本文強調感知、決策、執行三者功能的分離和在線重構，如引言中所做分析，感知能力的獨立表達和在線重構對于構件適應能力的調整是十分必要的。此外，上述方法僅強調功能分離，沒有考慮開發時帶來的設計和編程實現代價，本文則進一步給出了構件模型和使用 DSA技術來實現構件靈活重構的方法。

與本文工作密切相關的另一研究是基于體系結構的軟件自適應。早在1999年文獻[11]提出了一種基于體系結構的軟件自適應模型，該模型由描述適應過程的適應管理和實現體系結構在線變化的演化管理2部分組成。除了前面已提及的K-Component，MADAM 等模型外，Rainbow 研究了軟件體系結構在線修改過程中的軟件重用問題[12]；FORMAware強調對體系結構重配置時需要保證功能的完整性和遵守體系結構的約束[13]；Fractal構件模型要求在設計時就要考慮體系結構配置的變化[14]等。網構軟件運行平臺[15]也是基于軟件體系結構來支持軟件的自適應調整，通過自主構件來實現構件內部從感知到行為執行的功能適應[16]。文獻[17]提出了一種以“環境信息顯式化、互動方式層次化、體系結構可演化”為特征的環境驅動模型。上述工作研究了基于軟件體系結構的模型，通過可演化的體系結構來支持軟件自適應調整。但是這種調整能力還是依賴軟件體系結構的設計，這種設計方式在封閉的軟件架構中是有效的，一旦應用到開放的環境中就暴露出體系結構過于緊耦合的缺點。而本文工作則關注如何在運行時實現軟件構件的在線重構。例如構件間拓撲關系改變和通過增加或替換構件來引入新的功能等。本文提出的構件模型，將決策和執行功能交予模型框架實現，構件只專注功能的實現，減少了第三方開發構件的難度，有利于軟件在開放異構環境中的應用。

對于運行大量外來構件的軟件系統，如何保證軟件系統的安全和外來構件的可信是必須要解決的問題。第三方構件主要依靠數據的交互影響其他構件，因此保證構件數據的安全是一種提高構件模型可信性的解決方案。數據的安全封裝最早出現在虛擬機研究中[18]。Tal Garfinkel和Ben Pfaff等提出了一種稱為Terra的可信計算體系結構[19]，它的目標是支持具有不同安全需求的應用同時運行在同一硬件平臺之上。Terra利用虛擬機技術在一個硬件平臺上構建多個具有不同安全特性的可信計算系統。通過嚴格保證虛擬機間的隔離，使得具有較低安全級別的“開放式”系統和具有較高安全級別的“封閉式”計算機系統能夠并發地執行在同一硬件之上。但是Terra并沒有使用安全硬件，而且只為平臺上的各種應用提供基本安全保障，并沒有建立高等級的信任保證，也沒有采用KVM[20]或VaxVMM[21,22]的安全共享方法。IBM公司的vTPM系統[23]也是基于Xen實現，它能夠利用底層硬件的TPM模塊為上層的多個虛擬機提供可信平臺模塊服務，從而實現了信息流在虛擬機監視器中的安全傳遞。HP也在TPM虛擬化方面做了類似的研究工作[24]。但是這些技術面對的是應用復雜多變和易遭受攻擊的計算機系統，對于可重構網絡中的節點設備，可以利用上述研究的數據安全隔離或封裝的思想，不需要開發獨立的可信計算平臺。

與前人不同，本文提出了一種支持網絡重構的可信構件模型，并從構件數據的可信性出發，對構件交互的數據進行安全封裝，阻止構件進行惡意操作，提高了整個構件模型的可信性。本文創新點在于提出了一種支持重構的可信構件模型，并闡述了模型的重構機制，組裝機制和可信機制，除了應用于可重構柔性網絡的節點中，任何需要軟件自適應調整的場合均可使用本文提出的構件模型。

3 TCM構件模型

一般說來，軟件構件的結構模型決定了構件的基本形態，它是軟件方法學的核心。為建立面向可重構環境的軟件構件模型，本節針對經典軟件結構模型存在的“預定的環境、緊耦合的結構、集中式的開發和重編程的應變方式”等問題，提出以“松耦合結構、分布式聚合、動態化重構、可信化保障”為特征的軟件構件模型。其中開放協同是基礎，主要特征是“松耦合結構與分布式聚合”，它將突破傳統封閉可控模型的限制，使得軟件在結構上能夠適應可重構環境對各類資源的多模式協同的要求。外界驅動的特征是“感知環境變化與動態重構”，其中外界環境變化也包括人為發布的重構指令，在此基礎上，建立開放協同模型與環境模型的交互計算模式，從而形成環境驅動的動態化重構。更進一步，可信化保障主要指“數據的安全交互”，它是在環境驅動模型的基礎上引入安全封裝，解決開放環境下構件的可信性問題，最終形成一個安全可信的軟件模型。

構件模型由構件和容器組成，構件分為構件代理和行為構件2種類型。容器負責外界環境的感知為構件提供運行環境，構件代理具有決策功能，構件模型中只含有一個構件代理，行為構件負責實現具體的功能。宏觀上構件模型如圖1所示。構件植入到容器后，首先向構件代理(CA,component agent)注冊，由CA記錄構件的屬性信息并分配構件一個在容器內唯一的通信地址。構件間的交互是通過 AC(agent client)進行的，AC利用容器提供的通信服務將構件的信息在構件間按需地進行傳遞。

圖1 構件模型與外界環境關系

3.1 感知、決策和執行分離機制

為了適應可重構環境的環境多變和重構特性，本文提出了構件模型中感知、決策和執行分離的機制，如圖2所示。感知功能包括對環境變化的檢測和接收人為發出的重構指令，與外界環境交互密切所以交由容器實現，以建立環境模型和觸發重構決策。本文將環境的變化抽象為軟件運行的上下文變化，上下文是構件模型中一個重要概念，將在后文中詳細闡述，它為形式化描述環境變化提供了方法和工具，便于容器感知功能的實現。容器除了具有感知功能，還負責完成構件對外信息的交互和對底層資源的調用，這點與軟件中間件功能類似。

圖2 感知、決策和執行分離機制

決策功能是構件模型的中樞部分，是執行軟件重構過程中決策邏輯的構件，因此本文使用一種特殊的構件實現決策功能，稱為構件代理(CA)。本身這種實現方式也是一種功能分離機制，當構件模型決策機制變化時只需修改其中的構件代理，這樣做可以使構件模型達到最大程度的前向兼容效果。構件代理的動作可以分為修改構件功能描述與修改構件連接拓撲：前者指構件代理可以對行為構件的語義進行調整，具體表現為構件屬性描述信息的變化；后者則是指構件代理能夠對行為構件間連接拓撲進行調整，如增刪、替換構件和連接關系等，具體表現為構件代理修改容器所提供的AC服務。

行為構件用來在容器中實現軟件的功能，大多數構件由第三方開發，需要考慮行為構件的安全性和標準化。因此后文重點關注行為構件接口的標準化和可信數據傳遞。行為構件是可重構操作的對象，本文正是通過行為構件的增刪與替換實現軟件整體功能的重構。

3.2 軟件構件模型支持的重構機制

可重構柔性網絡的特點是按照用戶需求構建具有不同業務屬性的可重構服務承載網，不同的服務承載網對應一系列不同的構件。服務承載網的構建和重構一方面涉及數據平面轉發和交換部件的重構，另一方面涉及控制平面中軟件構件的替換和增刪。重構過程中兩者相互配合，數據平面提供構件模型與外界交互的通道，控制平面借助構件模型完成軟件構件的部署和替換，啟用適應數據平面的控制構件。網絡節點的重構過程涉及到節點內的構件代理、容器和行為構件，還需要節點外構件庫的支持，執行過程如圖3所示。服務承載網重構反映的是構件模型接收重構指令進行重構操作的過程，除此之外構件模型還可根據感知環境的變化進行構件重構，兩者相比區別僅在于驅動重構的來源不同，本文對前者進行詳細描述，后者不再贅述。

圖3 構件模型支持的重構機制

結合前文的描述，用戶負責下發重構方案，重構方案中包含了預先定義便于構件代理識別的重構指令。構件庫中提前存有第三方遵循構件模型標準開發的構件，構件代理根據重構指令下載合適的構件。

構件運行時，首先向構件代理注冊，構件代理為每個構件分配通信地址，并告知當前構件的通信對象。每個構件將與自己通信的構件分為上游構件和下游構件，接收對方消息時標記對方為上游構件，向對方發送消息時標記對方為下游構件。分別在各自AC中保持上、下游構件通信列表。當通信對象發生變化時只需更新AC中的通信列表。

當需要添加構件時，構件代理為新構件分配地址，同時廣播新構件的地址，各構件AC根據廣播消息更新自己的通信列表；刪除構件時，構件代理將原有構件地址宣布為無效地址，各構件AC將自己通信列表中的相同地址標記為無效；替換構件時，只需將被替換構件AC中的信息遷移到新構件中。上述重構機制在實際場景中有多種實現方式，可根據編程語言選擇合適通信機制和編程實現。

4 TCM的構件類型和構造方法

構件模型是基于構件的軟件開發方法的核心，它由構件語義、構件語法和構件組裝3部分組成。構件語義說明了構件到底是什么；構件語法規定了構件是如何被定義、構造和表示的；構件組裝則說明構件是如何被靜態和動態組裝的。

上下文是環境某一個維度(如可用內存、溫度、位置等)，其定義可以來源于相應的上下文本體，上下文的值代表了環境在該維度的狀態，上下文事件代表的則是該維度狀態的變化。在上述定義的基礎上，可以區分構件的上下文端口和服務接口；前者可以定義上下文事件，用來更新容器內部的環境模型等；后者則是一般意義上包括方法、屬性等的接口。

定義1 上下文E可定義為三元組 ＜ name, t p ye,value＞，其中，name是上下文的名稱，type是上下文的類型，上下文E在任一確定的時刻均有一個類型為type的值value。

定義 2 容器 C可以定義為三元組 , ,In Out＜service＞，其中，In表示容器用來接收構件消息的端口集合，端口的類型決定了容器中可以植入構件的類型，Out表示容器輸出消息的端口集合，service表示容器可以提供的服務類型的集合，一般service都會與一組In和Out端口綁定。

容器C是構件運行的環境，在軟件生存周期內屏蔽環境變化造成的影響，它提供了豐富的供構件調用的服務接口，完成構件間基本的信息交互和對底層資源的調用，如內存分配和時鐘管理等。容器C定義的端口和服務是第三方開發構件時參照的重要標準，容器C的實現方式決定了構件植入方式。

4.1 構件類型

構件代理是一類特殊構件，它不參與軟件功能的處理，是對軟件決策邏輯手段的封裝，執行重構操作。構件代理負責接收用戶制訂的重構方案，按照預先約定的語義解析方案，根據方案進行構件重構，可以控制構件的加載，激活，配置和卸載。構件代理還可根據環境變化調整構件之間的連接關系。

對于行為構件引用傳統意義的定義，即具有相對獨立功能、可以明確辨識、接口由契約指定、可獨立部署、和語義有明顯依賴關系、且多由第三方提供的可組合軟件實體[25]。它對具體業務處理行為進行封裝，通過AC對外提供多個服務接口，并可以依賴其他接口。

4.2 構件構造方法

在已有的構件模型中，構件外部特征的定義方法可以分為兩大類：直接使用具體的編程語言(如Java)或使用專門的構件定義語言(如CCM，COM/DCOM)。后者一方面有助于實現不同語言、不同平臺間的互操作，更重要的是，它們可以顯式地表示構件類型信息，從而有助于對軟件體系結構的后續修改。因此，本文在TCM中引入了XML語言來定義構件。

本文對XML語言進行了擴展，主要的擴展內容包括：引入component，id等關鍵字及相關語法來定義構件；引入event關鍵字及相關語法來定義上下文事件；引入 in_port，in_port_num，in_message_type, out_port等關鍵字來描述接口；引入state關鍵字來定義構件組裝類型等。

通過專門設計的編譯器可以將XML構件定義映射為Java、C等具體編程語言下的構件框架，構件開發者可以填寫構件實現并生成構件分組。構件模型的接口中包括了普通服務、事件處理和構件映射3 類方法，其中，普通服務和事件處理由XML定義直接映射生成，構件映射方法則需要向構件代理注冊構件類型、當前運行狀態等基本信息，由構件代理決定誰來具體完成該請求。TCM構件的構造方法如圖4所示。

圖4 構件構造方法

4.3 構件組裝機制

組裝是構件模型應用的核心，構件模型可對行為構件按照滿足應用需求的方案進行組裝來實現軟件功能。

在構件的組裝過程中，涉及到不同構件之間的連接拓撲，而且不同構件的連接拓撲也決定了構件間信息流的傳輸路徑。根據信息流在互連構件間的流向，從復雜的構件連接方式中提取出順序組裝、聚合組裝和分支組裝3種最基本的構件組裝方式，如圖5所示，圖中省略了連接拓撲的實現細節。任何復雜的構件組裝均以這3種組裝關系為基礎。從軟件體系結構描述角度出發，可在基本構件的形式化描述基礎上，推導出基于以上3種方式組裝的復合構件的形式化描述。若以推導出的復合構件為基礎構件，可進一步推導出更高層次的復合構件，如此反復，最終可推導出整個復雜軟件系統的體系結構描述。TCM模型從軟件體系結構的角度實施構件的組裝，通過AC的連接拓撲變化來實現構件間的組裝，可以用XML語言描述構件間接口關系的改變來描述構件的組裝藍圖。圖 6展示了使用 XML語言描述簡單的順序組裝和聚合組裝。

圖5 構件組裝機制

圖6 XML語言描述的構件組裝

5 TCM模型的可信機制

可重構柔性網絡節點中運行著大量第三方構件，其中，多個構件在容器中組裝成為更復雜的軟件構件。構件模型的可信機制應既要保證單個構件的可信，也要保證組裝后構件系統的可信性。

構件在構件模型中通過AC調用容器提供的接口進行消息通信，在TCM模型中提出了一種構件接口數據的安全封裝機制，防止構件進行違反約束的訪問和操作。容器是將構件和底層操作系統隔離的一種構件運行環境，操作系統默認容器與自己進行的操作都是高安全級別的可信操作，構件進行的操作都是低安全級別的操作。低安全級別的操作可以依賴高安全級別的操作，若高安全級別的操作依賴于低安全級別的操作則認為這是不可信的。可信機制中涉及的對象包含CA代表的構件代理, C代表的容器，AC代表的構件接口。本文在容器中對構件的接口數據進行安全屬性劃分和封裝。

定義 3 安全級別、安全操作和安全操作集函數。利用安全級別對 CA、C、AC進行劃分。CA和C之間交互的數據屬于高安全級別，記為 d ataH，AC之間交互的數據屬于低安全級別，記為 d ataL。CA和 C進行的操作屬于高安全級別操作，記為ActH，AC進行的操作屬于低安全級別操作，記為ActL。函數 g et_ Acts( d: d ata) → 2Acts表示由數據安全級別得到執行該數據安全操作的集合。

定義 4 安全屬性和安全屬性映射函數。安全屬性記為prop，安全映射函數記為 fp rop( p: p rop)→data。

在容器C中，將存儲空間劃分為相互隔離的區域使用安全屬性標記，為了保證構件傳遞數據的安全，使用安全映射函數將構件的數據保存在不同的存儲空間。當發生構件組裝后，將組裝在一起的構件數據映射到安全屬性相同的存儲空間，如圖7所示。

構件代理為相互通信的構件分配相同 security property值，AC將構件的數據與此security property值綁定。容器根據構件數據的security property值將數據存儲在特定的安全存儲空間。當其他構件讀取此數據時，只有security property值一致時才能獲取數據。構件組裝后，構件代理為被組裝的構件分配同一個security property值，構件只能使用此security property與參與組裝的構件通信。這種機制可以保證構件代理對構件間通信的管理，避免惡意構件自主通信。security property值由構件代理分配，取值來自Hdata和Ldata構件無權修改，AC負責綁定security property值和數據，惡意構件無法偽造security property值欺騙AC。另外還可以使用加密算法保證security property值不被惡意構件獲取。

6 原型驗證及實驗

本節描述在可重構路由器中實現的TCM容器原型，并基于容器開發的構件實例來驗證TCM模型的有效性。

6.1 支持ATCM的容器原型

容器除了提供構件運行的環境外，也是實現重構的場所和提供可信機制的基礎設施。基于Quagga路由軟件的Zebra平臺[26]實現了一個TCM的容器原型，其主要部件如圖8所示。構件管理引擎負載構件的加載、激活和卸載等操作。通信引擎負責支持構件的數據通信和轉發構件的服務接口的訪問請求，提供數據報文的傳遞。可信存儲提供數據安全存儲機制，隔離構件低安全級別的操作。構件組裝引擎負責執行和維護構件的組裝，并將組裝結果反饋給可信存儲。環境模型提供外界環境變化的表征，保存當前影響構件的環境維度的屬性值，構件屬性描述信息等。日志記錄負責保存重構操作記錄，容器架構信息等。系統接口與操作系統交互，為容器提供操作系統的支撐服務。

圖7 容器C安全存儲資源分布

Zebra容器運行時需要維護系統內部狀態的一致性，如構件重構時的狀態遷移等。當構件模型發生變化時，構件管理引擎負責映射構件相關的變化，環境模型負責映射容器體系結構的變化。當發生如構件意外失效的特殊情況時，構件管理引擎通過輪詢構件AC反射接口獲知情況變化，相應的狀態會被反饋到環境模型中。Zebra容器目前可以運行在Linux和其他Unix變體系統上，符合GNU的GPL標準并提供了支持C語言編譯器等開發工具。

除了上述構件重構和管理部分的功能外，Zebra容器本身對路由軟件提供了非常豐富的操作支持。它支持 BGP-4、BGP-4+、OSPFv2、OSPFv3、RIPv1、RIPv2和RIPng等協議的標準接口和數據操作，對外提供類似Cisco IOS管理操作接口。第三方開發者可以按照構件AC和容器接口規范開發路由協議構件，在6.2節將介紹構件AC接口的使用。

6.2 構件模型重構實例

圖8 ATCM容器原型

圖9 路由協議構件運行示意

以OSPFv2協議構件和路由管理構件為例介紹構件的重構過程，圖9中是OSPFv2協議的一種實現實例。第三方開發OSPFv2構件時首先滿足協議處理功能需求，其次根據構件模型規范，開發與構件模型需要交互的接口，開發時使用3類AC，AC1負責為網絡管理員提供一個通過指令配置、干預、查看OSPFv2運轉狀況的通道；AC2提供函數可獲取底層接口信息和重分配路由信息，同時將 OSPF路由信息交給路由管理構件；AC3主要實現OSPFv2協議構件與操作系統的TCP/IP協議棧的連接，以接收和發送數據分組，并提供對協議模塊運行過程中的內存和定時器管理。

通過如下場景驗證構件模型對構件重構的支持。

1) 構件的加載。初始情況下路由設備中只啟動Zebra容器。構件代理發布命令下載和啟動OSPFv2構件(component 1)，OSPFv2構件可以進行正常的協議報文收發，并且將協議處理的路由信息下發給底層路由查表模塊。如圖9路徑A所示。圖10顯示了構件的端口信息和構件代理打印的構件拓撲連接信息。其中，路由查表構件(component 3)屬于硬件構件，雖然不在Zebra容器中運行但可以接收構件代理的消息。

2) 構件間連接關系的重構。隨著路由設備的運行，陸續加載RIP，BGP等構件，此時需要路由管理構件來統一管理各個路由協議的路由信息，此時需要改變OSPFv2構件路由信息的傳輸路徑，如圖9路徑B所示。構件代理下發重構命令，修改構件的通信關系同時更改構件的security property值。圖11顯示了構件代理打印的構件注冊信息和構件拓撲連接信息，以及各個構件間的消息傳遞。此時構件都被設置使用端口1傳遞消息。

3) 構件的卸載。構件運行中如果需要對構件進行替換，需要將舊的構件卸載，通過構件代理發布命令卸載路由管理構件(component2)。構件顯示的信息如圖12所示。可以發現，構件代理發布命令，注銷component 2，同時將此消息通知component 1和component 3，隨后通知component 1和component 3改變通信對象，從而實現了構件連接拓撲關系的改變。

圖10 構件間拓撲連接

圖11 重構構件時消息傳遞顯示

圖12 卸載構件過程中的信息顯示

6.3 構件模型可信機制評估

構件模型在Zebra容器中內嵌安全存儲機制來實現構件交互數據的安全可信。設計2個場景評估可信機制的效果，一個是安全存儲對可重構路由器的構件性能的影響，即對單位時間內報文交互時延的影響。另一個場景是測試可信機制對惡意行為檢測效果。

場景1 使用路由器R1將真實路由分別廣播給啟用安全存儲的可重構路由器R2和不啟用安全存儲的可重構路由器R3，待R2和R3學得路由后再分別廣播給路由器R4。在R1和R4的鏈路中抓取路由廣播分組，抓取分組軟件使用Etheral 0.10.14，計算分組時延并進行比較，觀察可信存儲機制造成的時延。普通路由器 R1和 R4使用的是中興ZXR10，路由表數據來自 routing information service(RIS)[27]。測試網絡拓撲如圖13所示。

路由器處理每條路由的時間較短，選擇真實路由表中前綴為25的路由信息10 000條，每100條統計一次均值，并且設置OSPFv2構件每5s廣播一次路由信息，分別用c、a點的時間戳差值和d、b點的時間戳差值比較。

可重構路由器中使用最多的是路由協議構件，OSPFv2構件可以設置廣播路由消息的時間間隔，固定的時間間隔削弱了路由信息的實時處理性，為消息的安全封裝和讀寫提供了時間保證。從圖 14中可以發現雖然路由信息的處理時延存在抖動但是控制在1s之內，2個路由器的處理時延平均值相差不到0.4s，這個時間差主要產生于從安全數據存儲區域取出數據廣播路由信息這個過程。構件模型的數據安全存儲機制對路由信息報文交互的處理時延影響較小，不會影響路由協議的性能。

圖14 R2和R3路由信息處理時延比較

場景2 構件惡意行為檢測。

使用rip構件充當惡意構件，修改rip構件的協議報文發送函數，使它冒充OSPFv2構件調用AC提供的接口函數進行報文收發。下面的這些回調函數的賦值用來完成構件代理對 OSPFv2構件的控制，原來包含在OSPFv2構件中。OSPF協議中使用的是raw socket，所以修改時重點替換的是socket創建和setsockopt函數(如圖15所示)。篇幅所限不在此一一列舉。

Zebra容器運行過程中，原本發送給 OSPFv2構件的數據被惡意的rip構件調用AC接口函數進行讀寫，雖然此時AC接口函數可以被調用，但是當惡意構件在安全存儲區讀取數據時，無法獲得正確的security property值，讀取操作被拒絕，并在反饋給構件代理警告信息，運行結果如圖16所示。

圖15 構件代碼修改示例

圖16 構件惡意行為檢測

從結果中可以發現，構件注冊時構件代理把惡意rip構件認為是OSPFv2構件，所以惡意構件注冊成功并運行，但是當構件開始讀取數據時被發現為惡意構件，結果被存入日志并且上報構件代理，構件代理將其打印顯示，同時暫停惡意構件的運行待管理人員進行處理。其他構件不受此影響正常運行。

7 結束語

構件化的路由設備是可重構柔性網絡的重要節點支撐設備。本文以路由設備控制平面支持可重構為背景，兼顧軟件系統對環境變化的適應。基于構件間連接關系的調整和構件數據的安全存儲提出了一種可信構件模型 TCM。構件模型從環境感知、決策、執行三者相分離的思想出發，使用構件代理完成決策功能，使用容器感知環境和隔離底層操作系統影響，使用行為構件實現軟件系統功能，通過在容器中內嵌安全存儲機制提高構件的可信性。根據本文構件模型開發的Zebra容器和在其中實現的構件實例已經應用到了可重構路由器的開發中。后續工作將對深層次的構件重構機制和構件的可信評估展開研究。

[1] 汪斌強, 鄔江興. 下一代互聯網的發展趨勢及相應對策分析[J].信息工程大學學報, 2009, 10(3):1-6.WANG B Q, WU J X. Development trends and associated countermeasures analysis for NGN[J]. Journal of Information Engineering University, 2009, 10(3):1-6.

[2] 袁博, 汪斌強, 張博. 綠色網絡的實例——可重構柔性網絡[J]. 電信科學, 2011, 27(10A):200-207.YUAN B, WANG B Q, ZHANG B, A case study of green network——reconfigurable flexible network[J]. Telecommunications Science,2011, 27(10A):200-207.

[3] MEI H, SHEN J R. Progress of research on software architecture[J].Journal of Software, 2006, 17(6):1257-1275.

[4] VALLECILLO A, HERNANDEZ J, TROYA J M. Component Interoperability[R]. ITI200037, Universidad de Málaga, 2000.

[5] YANG F Q. Thinking on the development of software engineering technology[J]. Journal of Software, 2005,16(1):1-7.

[6] SALEHIE M, TAHVILDARI L. Self-Adaptive software: landscape and research challenges[J]. ACM Trans on Autonomous and Adaptive Systems, 2009,4(2):1-42.

[7] WANG Q X. Towards a rule model for self-adaptive software[J].Sigsoft Software Engineering Notes, 2005, 30(1):1-5.

[8] KEENEY J. Completely Unanticipated Dynamic Adaptation of Software[D]. Dublin: Trinity College, University of Dublin, 2004.

[9] DOWLING J, CAHILL V. The K-component architecture meta-model for self-adaptive software[A]. Proc of the Int’l Conf on Meta level Architectures and Separation of Crosscutting Concerns[C]. Kyoto, Japan,2001. 81-88.

[10] PASPALLIS N, PAPADOPOULOS G A. An approach for developing adaptive, mobile applications with separation of concerns[A]. Proc of the 30th Annual Int’l Computer Software and Applications Conf(COMPSAC)[C]. Chicago, USA, 2006. 299-306.

[11] OREIZY P, GORLICK M M, TAYLOR R N, et al. An architecture-based approach to self-adaptive software[J]. IEEE Intelligent Systems, 1999, 14(3):54-62.

[12] GARLAN D, CHENG S W, HUANG A C, et al. Rainbow: architecture-based self-adaptation with reusable infrastructure[J]. IEEE Computer, 2004, 37(10):46-54.

[13] MOREIRA R, BLAIR G, CARRAPATOSO E. FORMAware: framework of reflective components for managing architecture adaptation[A]. Proc of the 3rd Int’l Workshop on Software Engineering and Middleware[C]. Orlando, USA, 2002.

[14] BRUNETON E, COUPAYE T, STEFANI J B. Recursive and dynamic software composition with sharing[A]. Proc of the 7th Int’l Workshop on Component-Oriented Programming (WCOP)[C]. Malaga, Spain, 2002.

[15] YANG F Q, LV J, MEI H. Technical framework for Internetware: an architecture centric approach[J]. Science in China (Series E), 2008,38(6):818-828.

[16] MEI H, HUANG G, ZHAO H Y, et al. A software architecture centric engineering approach for Internetware[J]. Science in China (Series E),2006, 36(10):1100-1126.

[17] LU J, MA X X, TAO X P, et al. On environment-driven software model for internetware[J]. Science in China (Series E), 2008, 38(6):864-900.

[18] VMware, Inc VMware virtual machine technology[EB/OL]. http://www.vmware.com, 2006.

[19] GARFINKEL T, PFAFF B, CHOW J, et al. Terra: a virtual machine-based platform for trusted computing[A]. Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP'03)[C].New York, USA, 2003. 193-206.

[20] KARGER P A. Multi-level security requirements for hypervisors[A].Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC'05)[C]. Tucson, Arizona, USA, 2005. 267-275.

[21] JAEGER T, SAILER R, SREENIVASAN Y. Managing the risk of covert information flows in virtual machine systems[A]. Proceedings of the 12th ACM Symposium on Access Control Models and Technologies (SACMAT'07)[C]. Sophia Antipolis, France, 2007. 81-90.

[22] CABUK S, DALTON C I, RAMASAMY H G, et al. Towards automated provisioning of secure virtualized networks[A]. Proceedings of the 14th ACM Conference on Computer and Communications Security(CCS'07)[C]. Alexandria, VA, USA, 2007. 235-245.

[23] STEFAN B, RAMON C, KENNETH A G, et al. vTPM: virtualizing the trusted platform module[A]. Proceedings of 15th USENIX Security Symposium[C]. Vancouver, Canada, 2006. 305-320.

[24] MELVIN J A, MICHA M, CHRIS I D. Towards trustworthy virtualization environments: Xen library OS security service infrastructure[EB/OL]. http://www .hpl.hp.com/techreports/2007/HPL- 2007-69.html, 2007.

[25] 楊芙清，梅宏，李克勤. 軟件復用與軟件構件技術[J]. 電子學報，1999, 27(2):68-75.YANG F Q, MEI H, LI K Q. Software reuse and software component technology[J]. Acta Electronica Sinica, 1999, 27(2):68-75.

[26] QUAGGA guide[DB/OL]. http://quagga.net.

[27] RIS raw data[DB/OL]. http://data.ris.ripe.net.