ONF組織的SDN架構文檔——四個架構(三/二)

5.3提供虛擬網絡,非遞歸式的SDN提供商

在第5.2章節,每一個NE都有一個相關的客戶agent。它包含着從自身NE中虛擬出來的虛擬資源。概念上的資源是跨度多個物理NEs的,由SDN控制器對其進行擴展。這個章節與5.2章節的主要不同是:這一章節的控制器client可以約定跨越多個物理NEs的虛擬資源;這樣,資源在控制器server中是可擴展的。提供商通過在SDN控制器server中定位客戶環境需求的完整表現形式,爲客戶提供了一個完整的虛擬網絡視圖;並且也避免了server的NEs直接暴露給客戶信任域。


一個虛擬網絡至少包含一個虛擬NE(VNE)。一個VNE是子網的一個抽象,被控制器視作物理NE來對待。一種極端的情況是(5.2章節),VNE與底層的物理NE是一對一映射的;另一種極端情況是,整個VN被視作一個NE(如圖4.15中的Green-1)。在VNE-subnetwork中的鏈路是隱蔽的,而外部的端口是暴露的。類似VNE上的端口,連接是不受限制的(或者不當成端口,而是通過適配手段連接),都沒必要去爲它們做擔保。VNE上的端口可能最終被追溯到不同的物理NE上。圖片5.3中I-CPI顯示的I-CPI實例代表了一種中間立場。

“綠”SDN控制器期望虛擬網絡看起來像真實的網絡,就像5.2章節中的一樣。“綠”期望管理常用的操作,像發送簡單的轉發流規則到NE端口。這個命令實際上是跨度整個子網的。“藍”通過創建一系列的轉發規則來實施這些命令。這些流規則被髮送到與“綠”相關的設備上(圖4.13);或者映射這些命令到已存在的或動態建立的隧道中(或是兩者的結合)。

因爲“綠”VNE在物理上可能跨度多個“藍”的NEs,因此當“綠”要擴展自己的抽象資源時,可能在同一個地點上就沒有物理NE。處於較低層的SDN控制器,爲上層提供了跨度多個網絡的抽象,就需要對上層的擴展需求負責。因此,agent G的環境必然要從“藍”NEs移動到“藍”SDN控制器SDNCB中;在控制器中,它的表現形式是一個由虛擬器支持的,代表着整個“綠”VN的 RDB。反過來,這些代理環境也會向擴展的“藍”NEs發送必要的命令。和從“綠”控制器擴展南向接口的命令範圍一樣,“藍”虛擬器有責任綜合來自底層網絡的信息,其綜合的形式對“綠”的虛擬網絡要有意義。圖5.3顯示了這種情況。

圖5.3也現實了第二個客戶“紅”,它有自己完全擁有的獨立VN資源數據庫,策略和虛擬器。一般來說,“綠”SDN控制器是自己的NEs的一個協調管理者,同樣的,還有來自“藍”的可見NEs。

“藍”只在SDNCB上規定與客戶相關的信息,而不是在“藍”NEs中。“藍”NEs上所有的動作是由SDNCB的DPCF在NE agents0上來執行的。具體是由SDNCB的虛擬器和策略實施者通過一個可信任的D-CPI來將客戶信息和動作發送的。對於NEs,這與第5.1章節所描述的是一樣的情形。


“藍”OSS爲“綠”執行以下的任務,並且也會爲其它客戶執行同樣的流程:

1.在控制器SDNCB上實例化客戶指定的代理,例如agent G。這個過程包括創建主RDB,起碼也要創建一個RDB的空架子。

2.在控制器SDNCB上,“藍”從主RDB分配資源到agent G是通過協協調器功能組件的方式實現的。

作爲資源分配功能的一部分,“藍”可能需要通過SDNCB agent0來建立必要的隧道或者其它隱藏的網絡服務,不僅如此,還需要控制合適的瓶頸(OAM,保護,PM)。這些都爲“綠”呈現了簡單的鏈路端點資源,但是對於“藍”來說這些是連通性的服務。

3.爲agent相應地實例化一個虛擬器,並且安裝策略。虛擬器爲底層的DPCF功能和客戶RDB操作做翻譯工作。虛擬器向“綠”SDN控制器暴露“綠”agent的RDB,也可能是暴露出比第2步形成的資源集合更抽象、更不具體的資源,就像圖中所示的I-CPI。這個抽象的不同是:它是來自agent G完整的RDB但是,是受限制的抽象。

虛擬器也是一個策略執行點(PEP)。策略可以保證“綠”得到合同約定的服務,同夥私也可以避免“藍”的資源被錯誤使用,惡意使用或者其它的問題。策略也指定了“綠”可以使用的動作(actions)的子集:什麼信息可以查詢,什麼通知信息可以訂閱。策略定義了“綠”和“藍”之間指定的標識符如何翻譯。另外,如果有必要隔離多個客戶的地址空間,策略也將指定如何將客戶流量包裝和轉換。同之前一樣,策略在圖中顯示爲一個加粗的線條,連接着“藍”的虛擬器和“綠”的代理環境。這個線條的顏色也意味着服務部分被(藍)擁有,藍具有加強策略的實權。

4. 建立 IP連接,安全證書等等,允許SDNCG和處於SDNCB中它的代理通信,與此同時還有它的RDB。

“綠”OSS在控制器SDNCG上執行補充操作。除去一個安全關聯(note)之外,這個和第5.2節的描述一樣。

Note – 如果“綠”SDN控制器在自己的會話中控制個人的NEs,那麼很自然地,它就需要和每一個“綠”VNEs建立完整的安全會話(如圖5.2所示),不需要知道和關心他們是否存在於agent RDB中。把這些會話通過多路複用技術放到一個單獨的容器會話中,只需要單獨的安全連接即可。

5.SDNCB可能會爲SDNCG的動態查詢提供響應附加值的特性,以此來聲明或發佈額外的資源。這樣的查詢是與agent G直接有關的,因爲在“綠”環境與“藍”環境間再無其他連接。

訪問額外資源仍然需要受到策略的約束,但是策略沒必要必須處在SDNCB中。策略也可能是保存在OSS中的元策略,也可能是有各自的OSS根據需要來決定的。在這種情況下,SDNCB會在收到這樣請求的時候去查詢“藍”OSS來做決策。當“藍”授予或回收再利用資源時,需要相應地去更新SDNCB的主RDB和agentG RDB。

或許可以通過用戶下載式的特徵包來使SDNCB可以用假設問題的形式來響應“綠”的查詢,例如要求“藍”提供價值的,或其他數字資源的選項,因爲可能受到“綠”的最大可接受屬性的限制。

圖5.3顯示了“藍”SDN控制器的一個agent0,它代表着“藍”的興趣和“藍”可直接控制資源的能力,或者代表着“藍”自己的用途,或者代表着服務“藍”客戶的代理(例如,上面的第二步建立隧道),與此代理相關的虛擬器和策略都會比普通agent的操作域廣,且擁有特權。

另外,“藍”可以通過一個或多個app服務代理支持應用程序,這些程序直接來自SDN控制器,每一個應用是更具RDB和策略定義的。

第5.2章節的結構部署是在特殊條件下推薦的。總結5.3章節的結構優點,可以總結爲以下幾點:

*“藍”OSS不需要反反覆覆地重配置它的NEs爲它的客戶部分。“藍”NEs的所有活動是由“藍”NEs的agents0來決定的,而此時,SDNCB協調所有由“藍”發放給客戶們的服務。客戶指定的開通服務只出現在SDNCB

* “藍”虛擬網絡現在完全可以是任意粒度的。

*NEs不再直接暴露給客戶SDN控制器,也不在需要爲客戶提供代理和策略。(數據層的相互連接當然是必須的,但是承擔更少的安全風險)

** 從安全方面看,攻擊視野變窄了。

** 整體的複雜性基本沒變,但是複雜性遷移到了SDN控制器上。NE的燃盡部分變得簡單了。

** 競爭有限的物理資源,例如端口、隊列、轉發表都直接對控制器SDNCB可見,這樣可以由控制器仲裁,使網絡最優化。

**非SDN NEs 可以只支持少量的SDN原則,如果有任何的變動,因爲多數SDN的特性都是在控制器上實現。

**可以用現存的EMS或OSSs來作爲SDN控制器與NEs之間的協調角色(調製器),但這樣可能會帶來性能和靈活性的缺陷。這樣有利於融合現存網絡到SDN領域中。

 

在我們討論的控制器章節裏,第5.3章節是最重要的一章,因爲它將虛擬網絡本地化(或集中化)到了SDN控制器中。第5.4章節繼續展覽一種遞歸式的控制器虛擬化。

 

5.4提供遞歸式的虛擬網絡的SDN提供商

第4.1章節解釋了遞歸式的控制器接口的必要性。這種遞歸的實現說明在層次結構中每一個層次的兩側都是相似的視圖。需要認識到,特殊的考慮可能實現在最底層(物理層)D-CPI,也可能實現在不做中間商的最終A-CPI的接口處。對遞歸的支持自然地遵從這樣的範式:客戶端通過CPI來操作一個由服務器實例化的通用信息模型。

遞歸的虛擬化實現意味着任意的SDN控制器的本地視圖在它的南向顯示爲D-CPI,但是從更廣的視角看視圖也可能是I-CPI(中間控制層接口)。圖5.4顯示,如何從一個全局的,多層次的角度形成接口。需要意識到,給定的VN可能包含物理資源和虛擬資源,例如,如果提供商從自己的物理網絡中爲用戶提供一些服務,但是轉發包隧道來自自己的網絡。這樣,接口指定了一個本質上任意的D-CPI,但部分物理,部分虛擬的網絡。


圖5.4顯示了一個遞歸的客戶-服務模型。”藍”有一些資源,在圖中顯示在最低層次,但是這些資源並不都是100%的物理網絡。“藍”將虛擬網絡服務向一個或幾個客戶提供,例如“綠”或“粉”。但是與第5.3章節相反,“紅”現在是中間商“綠”的客戶,而不是直接作爲“藍”的客戶。

“綠”0SS和SDN控制器與前幾個章節述說的“藍”服務器表現相同;同樣的,“紅”SDN控制器和“綠”服務器也很相似。客戶端(例如,SDNCR)看不到下面層次對服務(例如,SDNCG)的迭代,並且服務(例如,SDNCB)也不知道自己的客戶(例如,SDNCG)提供什麼應用。

 

5.5總結

通過OSS,一個提供商可以爲它的客戶和應用分配資源和建立環境。

總的來說,一個SDN控制器扮演着一個服務器的角色,應用程序扮演着客戶端的角色;控制器向它的應用程序暴露受管理對象的實例集合,並且滿足那些應用程序對受管理實例的需求,這些受管理的實例來自數據層的基礎設施。應用程序和數據層平面都可以是虛擬的,其最高表現形式就是迭代的層級結構。

在專用資源模型中,服務器分配一個預先協商好的資源集合(受管理的資源)給客戶。這個資源的集合是不會改變的,除非商業關係發生變化。

專用資源模型可能需要被擴展爲允許共享資源。在可共享資源的擴展中,提供商的策略可以允許客戶創建額外的受管理對象實例(代表資源),或者對已有資源設置屬性來增強性能。客戶也可以放棄花費不合理的資源。

在各自的控制域內,根據需求,客戶與服務器都需要保證事務的完整性。

服務器和它的客戶們在不同的信任域。有共同的信任域是一種特殊情況。

服務器執行“保證約定服務”的策略,同時保護自己和其他的客戶免受流氓攻擊。

服務器有責任去隔離用戶之間的流量。根據協議,服務器可能爲客戶提供底層網絡的服務,例如隧道和防護。這些功能對於客戶是不可見的。

客戶代碼不可以在服務器的信任域中執行。然而,是允許客戶下載應用程序到系統平臺上的,這個系統平臺也支持服務器SDN控制器的部分和全部功能。因爲SDN控制器需要的信息和狀態同步無法滿足,這樣的客戶代碼將被視爲在SDN控制器外部。這樣的代碼將會通過控制器的A-CPI接入點來與SDN控制器連接。A-CPI的信任域邊界在服務器信任域中識別不需要的可執行客戶代碼。


(未完待續……請看下一篇。轉載請註明出處!)



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章