摘要:首先介紹了ForCES體系結構,然后給出了一種ForCES體系結構中基于AgentX的網管代理方案,最后詳細研究了若干實現機制,并給出了測試結果#65377;
關鍵詞:轉發件和控制件分離; 網絡管理; 可擴展代理
中圖分類號:TP393.07文獻標志碼:A
文章編號:1001-3695(2007)10-0292-03
下一代網絡(next generation network,NGN)要解決服務質量問題#65377;在NGN的研究中,開放可編程的網絡結構思想得到了廣泛重視,開放可編程網絡的研究主要分兩個方面,即體系結構和接口標準(協議)#65377;ForCES就是目前已經提出并正在制定過程中的一種開放可編程的體系結構以及相應的管理協議#65377;ForCES體系結構必須支持標準的網絡管理#65377;如何在ForCES開放架構中實現基于SNMP的網絡管理代理,是ForCES必須考慮的問題,這也正是本文的出發點#65377;
1ForCES體系結構
一個網絡部件(network element,NE)如路由器#65380;防火墻等由兩部分組成,即控制件(control element,CE)和轉發件(forwarding element,FE)#65377;ForCES的基本思想是把IP路由器分成轉發件和控制件,認為IP路由器可由多個(可達幾百個)FE#65380;多個CE和連接它們的ForCES協議構成#65377;IETF ForCES工作組已經完成了ForCES需求和ForCES框架,當前的工作重點是ForCES協議和ForCES FE模型#65377;ForCES協議正在完善過程中,目前協議草案已經更新至第8版[1]#65377;圖1表示了在ForCES體系結構中各個邏輯部件以及它們之間的關系#65377;ForCES NE包含多個CE和多個FE#65377;其中Fp是CE和FE之間的接口#65377;ForCES協議就是在該參考點Fp定義的通信協議#65377;
2ForCES體系結構基于AgentX的網絡管理方案
2.1SNMP及AgentX
SNMP以其簡單性成為目前廣泛使用的網絡管理標準#65377;其體系結構包含三部分,即管理者#65380;代理以及管理者與代理之間通信所遵循的SNMP協議#65377;SNMP代理負責與網管者進行SNMP消息通信的任務,同時也負責維護MIB(management information base,管理信息庫)#65377;當駐留在網絡設備上的代理所支持的MIB需要擴展時,在SNMP體系結構下,必須重新構造代理,即無法在不改變原有代理的情況下擴展MIB,也就是不能實現動態擴展#65377;許多分布式設備或者由許多獨立模塊組成的復雜設備上的代理都有動態擴展MIB的需求#65377;為了解決這一矛盾,出現了AgentX協議[2]#65377;
AgentX協議定義了一個可擴展SNMP代理的標準體系結構#65377;AgentX體系結構將SNMP協議處理和MIB訪問這兩個功能進行分解,從結構上將代理劃分為主代理和子代理兩個部分#65377;AgentX結構通過子代理向主代理的注冊實現了代理靈活的動態擴展功能#65377;
1)一個主代理主代理負責處理SNMP 協議消息,與管理者進行交互#65377;
2)若干子代理子代理負責訪問MIB對象#65377;對于SNMP 協議來說,子代理是透明的#65377;
3)主代理與子代理交互的協議即AgentX 協議,實現主代理與子代理之間的通信#65377;
2.2ForCES原型機結構
為了研究ForCES協議,筆者搭建了如圖2所示結構的ForCES原型機#65377;由于CE承擔了控制整個ForCES路由器的任務,其任務繁重#65377;為了負載均衡,筆者將CE分為CE控制器和CE服務器,分別由兩臺主機實現#65377;其中CE控制器主要負責處理ForCES協議;CE服務器負責路由和SNMP服務#65377;FE用Intel的網絡處理器來實現,原型機中共設了三個FE#65377;SNMP網管者可與任意FE的任意接口相連,繼而進行SNMP網管#65377;
2.3ForCES網管需求
ForCES需求[3]和ForCES框架[4]共同要求ForCES路由器必須支持SNMP管理#65377;它們指出,絕大多數的管理任務應當通過與CE交互來實現#65377;基于ForCES的網絡管理必須遵循以下兩點:
a)應當支持用SNMP等網絡管理工具讀(但不改變)FE的狀態;
b)決不能不通知CE而改變FE的某些狀態(FE上的這些狀態的改變會影響整個NE的狀態)#65377;
2.4ForCES網管方案
根據ForCES體系結構對網管的要求,結合ForCES原型機結構,采用基于AgenX的代理機制來實現ForCES路由器的網管代理#65377;方案如圖3所示#65377;由CE服務器作為AgentX主代理,主要負責SNMP接收#65380;解析和發送;CE控制器上駐留AgentX子代理,主要負責與主代理間的AgentX協議包的交互#65377;CE控制器中的重定向處理模塊負責網管重定向包的處理,服務API模塊負責MIB取值#65377;CE服務器與CE控制器之間的IP隧道則是為CE服務器與CE控制器之間的消息傳遞提供了數據傳輸通道#65377;該方案讀寫FE的操作必然先經過CE,滿足ForCES需求#65377;具體相關實現機制在后面將作詳細介紹#65377;
方案中采用基于AgentX的代理機制的原因在于:
a)適合于ForCES的分布式體系架構#65377;ForCES體系結構本身就是一個分布式的體系結構,管理信息也是分布式的#65377;這種分布式結構的復雜設備必然有動態擴展MIB的需求,而AgentX正好能適用于分布式的環境,滿足動態擴展MIB的要求#65377;
b)適合于多個CE以及分布式CE的結構#65377;ForCES體系結構由多個CE和多個FE組成#65377;目前ForCES工作組一般認為多個CE是備份關系,以后將會考慮多個協同關系的CE的情況#65377;在多個CE的情況下,如果使用單一的SNMP代理顯然就違背了ForCES路由器對外呈現為單一設備的原則#65377;而若讓一個CE扮演AgnetX主代理,其他CE扮演AgentX子代理就可以很好地解決問題#65377;另外,CE常常承擔繁重的任務#65377;為了負載均衡,可以將CE分成控制器和服務器兩部分#65377;在這種分布式CE的情況下,則可以讓CE服務器作為AgentX主代理,而讓CE控制器作為子代理#65377;
c)有利于MIB模塊的動態擴展#65377;一個復雜的分布式設備的MIB往往由許多MIB模塊組成,并且各MIB模塊分布在該設備的不同組件上#65377;若采用SNMP單一代理,則不可能做到MIB模塊的動態加載和卸載,而AgentX靈活地解決了MIB模塊動態擴展的問題#65377;筆者也可以用多個AgentX子代理來維護不同的MIB模塊#65377;
3若干機制研究
3.1MIB的分布式維護
整個路由器由CE和FE組成#65377;CE由控制器和服務器組成,服務器負責SNMP服務和路由服務#65377;結合ForCES原型機結構,同時根據MIB的分布位置,按照就近原則進行MIB維護,這樣可以提高MIB操作的有效性#65377;
MIB細分為如下幾類,分別由不同的AgentX實體負責維護:
a)與SNMP服務有關的MIB,如MIBII中的系統組#65377;為避免通信復雜性,由駐留在CE服務器上的子代理維護#65377;
b)與路由服務有關的MIB,如MIBII中的IP組#65377;由于路由服務器上可以取得整個ForCES結構路由器的路由信息,根據就近原則,也由駐留在CE服務器上的子代理維護#65377;
c)與CE有關的MIB,如ForCES MIB(目前也是工作組討論的熱點內容之一)#65377;由駐留在CE上的子代理維護,也可以在CE上駐留多個子代理來維護多個MIB模塊#65377;
d)與FE有關的MIB,如MIBII中的接口組#65377;為了不增加方案和實現的復雜性,筆者不在FE上駐留子代理,這些MIB還是由駐留在CE上的子代理維護#65377;在這種情況下,CE通過ForCES協議來實現MIB值的維護#65377;
3.2FE MIB到FE屬性的映射
與FE有關系的管理信息,其抽象的MIB維護由CE控制器維護#65377;CE控制器為了維護這類MIB,需要通過ForCES查詢和配置來實現#65377;CE控制器必須將FE MIB映射成FE屬性#65377;
SNMP體系結構中的管理對象被抽象為MIB,并通過樹狀結構組織成抽象的數據庫#65377;MIB通過對象標志符OID(object identifier)來惟一標志#65377;例如表示接口的接收單播數據包數目的統計信息對應的MIB節點標志為iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInUcastPkts#65377;若第一個接口的ifIndex值為0,則表示第一個接口的接收單播數據包統計數目的MIB的完整OID表示為iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInUcastPkts.0#65377;用數值表示為1.3.6.1.2.1.2.2.1.11.0#65377;
ForCES中的管理對象必須被表示為屬性,并用pathdata來標志#65377;關于FE的屬性,目前已經有定義的是FE協議類屬性和FE對象類屬性#65377;在屬性定義中,給每個具體的屬性分配了惟一的IDs,而IDs就是構成path的主要部分#65377;可以根據需要自定義屬性,但是目前ForCES協議還沒有規定ID值的哪個范圍是可以由自定義屬性使用的[1]#65377;為了得到接口的接收單播數據包數目的統計信息,在FEObject這個LFB下定義了statistics屬性#65377;若要訪問接口的statistic屬性,需要指明pathdata#65377;其中path中的IDs指明為LFB.ports.FEPort.statistic,用數值表示是0.40.41.55#65377;同時需要指明LFB的key為name,keydata為FEObject;FEPort的key為portID,keydata為0#65377;這樣就可以惟一地定位到FEObject這個LFB的第0端口的statistic屬性了#65377;CE控制器提供的service API完成以上的映射機制#65377;
3.3網管消息傳遞及處理
數據通道的解決方案如下;利用ForCES重定向消息傳遞SNMP消息,利用ForCES查詢和配置消息來查詢和配置FE MIB#65377;下面以SNMP 查詢與FE相關的MIB操作為例,說明典型消息傳遞處理流程,如圖4所示#65377;
消息傳遞處理步驟如下:
a)SNMP管理者發送SNMP請求包給FE;
b)FE將該SNMP請求通過ForCES協議重定到CE控制器;
c)CE控制器利用IP隧道將該SNMP請求包傳遞給CE服務器(主代理);
d)CE服務器(主代理)接收解析該SNMP請求,并轉換成AgentX請求,發送給CE控制器(子代理);
e)CE控制器上的子代理接收解析該AgentX請求包,進行MIB映射,調用CE提供的MIB接口函數,向相應的FE發送查詢相應屬性的ForCES查詢消息;
f)FE返回ForCES查詢的響應消息給CE控制器;
g)CE控制器(子代理)解析ForCES響應,得到屬性值,同時映射成MIB值,然后構造AgentX響應包返回給CE服務器(主代理);
h)CE服務器(主代理)將AgentX響應包轉換成SNMP響應包,通過IP隧道交給CE控制器;
i)CE控制器再通過ForCES重定向消息交給FE;
j)FE將SNMP消息轉發給SNMP管理者#65377;
4結束語
在ForCES原型機上實現了基于AgentX的網管代理#65377;測試表明,該網管代理能支持標準的SNMP的GET#65380;SET和TRAP操作;表明網管方案可行,各機制有效#65377;
參考文獻:
[1]DORIA A, HAAS R, SALIM H J, et al. ForCES protocol specification[EB/OL].[2006].http://bgp.potaroo.net/ietf/ids/draftietfforcesprotocol08.txt.
[2]DANIELE M, WIJNEN B, ELLISON M, et al. RFC 2741, Agent extensibility(AgentX) protocol version 1[S/OL].(2000).http://www.faqs.org/rfcs/rfc2741.html.
[3]KHOSRAVI H, ANDERSON T. RFC 3654, Requirements for separation of IP control and forwarding[S/OL].(2003-11).http://www.ietf.org/rfc/rfc3654.txt?number=3654.
[4]YANG L,DANTU R.RFC 3746, Forwarding and control element separation(ForCES) framework[S/OL].(2004-04).http://www.faqs.org/rfcs/rfc3746.html.
“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”