ONF組織的SDN架構文檔——原理與架構構件(二/一)

4原理和架構構件

這節介紹SDN原理,形成SDN架構的功能實體和組織關係,隨後詳細介紹。

 

4.1原理

ONF從一個較高的視角對SDN進行介紹[1],一些基本的SDN原理在其中有引證,他們的應用在此有簡略的總結,在後續章節中有更詳細的介紹。

*控制器和數據層的分離原理

這個原理要求控制層和數據層可分割,但是也要知道,控制依然能在數據層中被執行。在SDN控制層和NE之間的D-CPI通過此方法定義:SDN控制器可以代理NE重要的功能,同時也能持續瞭解到NE的狀態。clause4.3列出了在SDN控制中哪些NE功能應該被代理和哪些功能應該保留的標準

 

*邏輯上集中控制

與設備自身控制相比,集中式的控制器能從更廣闊的角度來看在它控制下的資源,對於如何部署這些資源可能會作出更好的決策。考慮到網絡資源全球化不斷增加,但是對網絡資源缺少詳盡瞭解,去耦和控制權集中化使得可擴展性得到改善。出於對SDN網絡擴展或安全邊界的考慮,SDN控制器可能被迭代開發,變得擁有豐富的功能,在clause5 中有介紹此問題。

 

*向外部應用開放抽象網絡資源和網絡狀態

在任何抽象水平和粒度下,應用都可能存在,由於北向接口要求抽象程度提高屬性通常被描述成不同的抽象程度。因爲接口是用來公開資源和狀態的,應用和控制器都有接口,所以,應用和控制之間的差異就不明確了。相同的功能接口在不同使用者眼中可能是用處不同的。就像對於控制器而言,各個應用程序可能以對等的方式交互,或者以C/S形式。

 

網絡資源抽象和應用(經由A-CPI的應用)聲明的原理要考慮網絡的可編程性。使用有關資源和狀態的信息,通過SDN控制器,應用可以詳細描述它們的網絡服務需求和要求的變化,也能夠通過編程的對網絡狀態作出反應。

進一步,分層次地迭代應用/控制器層的概念和信任域的概念也讓應用程序得以創造,使應用程序的創建可能變成組件的組合,把組件應用程序組合成一個更全面的服務。

SDN架構通過識別基礎功能實體、定義實體間不同的接口需要交換的信息和操作,來闡明以上提到的原理的含義和影響。這個架構進一步把這些功能實體分解爲最基礎的功能組件集合,這些功能部件基本不能再分解。

該架構引入信任域邊界的概念,這對廣泛的商業化是很重要的。此架構在特定的可信任域中定義組件,並對其他信任域開放自己的參考接口(reference point)。強大的抽象障礙有利於保護相關人的商業利益,同時也有助於識別和適應不同的信任關係。架構的一致性有助於促進安全措施的設計和審覈。

從一個較高的視角看SDN,SDN垂直架構是服務器把信息模型實例公佈給客戶端,基於信息模型實例,客戶可以執行創建-讀取-更新-刪除(CRDU)和規範操作。這也強調了一個通用信息模型的重要性。從這個角度來說,management管理功能的職責是實例化信息模型和開放層間接口的執行力的策略,尤其是在不同的信任域之間的接口能力的開放。Figure4.1闡明瞭,C/S架構(控制器/代理)模型在多個SDN控制器構成層級結構時的環境中是可行的。

等級層次結構有兩個目的:

縮放和模塊化:每個連續的高等級都有可能向更高的抽象和更廣的範圍發展。

安全:在每個不同的信任域中,每個層都可能存在。爲了加強域間的安全,層接口可作爲一個參考點。


在遞歸的層次結構中,一個SDN控制器或一個應用可能把自己當成一個信息模型實例的直接控制器,此信息模型實例代表一個合適抽象的虛擬網絡(VN)。從這個參照中,它支持一個數據控制器層的接口,D-CPI。無論是一個NE(或者虛擬NE),或另一個SDN控制器,或者甚至是個應用,他的下級實體把上級實體看成一個應用,由A-CPI支持。從一個全局視野來看,其中一個或者所有這些接口可能以中間件CPIs(intermediate CPIs ---I-CPIS)的形式出現。於是出現了一個結果是,除了物理NEs以外,一個給定的實體可能佔用數據層或控制層或應用層中的任意一個,這取決於觀點和角度。

所有北向接口會公開管理對象實例供客戶使用,但是出於不同的抽象等級。

在任何一個遞歸層次中,一個資源被理解爲是隻服從一個控制實體的。然而一個SDN控制器可能支持任意數量的D-CPI實例,下層資源是不受一個以上的D-CPI實例支配的,也沒有被某個SDN控制器支配的資源。資源分配到哪個可信域的是mangment的功能。

注:clause4.3.5介紹資源共享

有些應用有原子語義要求,也就是說事務完整性(ACDI的性質 atomicity, consistency, isolation, durability)因此應用引起的全局擴張和抽象的操作也就暗示了事務語義存在於每一個下層,並且一直向下到到硬件。進一步說,失敗的事務不能有滯留的資源。每一個等級都遞歸地精心安排它下層實體的事務語義。

注:分佈式的事務完整性帶來了很大的代價,它可能不是在任何情況下都是必須的。如果事務完整性不被支持,應用者應該考慮使用其他方式從事務失敗中恢復過來,特別是有手工分配的資源的恢復。在一些情況下,內置的超時足以恢復滯留的資源。


4.2數據層

數據層包含直接處理客戶流量的資源,同時含有必要的支撐資源以保證合適的虛擬化、連通性、安全性、可用性和質量。

Figure4.4相較於3.3,對NE資源視圖進行了擴展。


SND關注於流量轉發和流量處理功能,比如QoS(Quality of Service)、過濾、監控或跟蹤。流量通過物理或者邏輯接口進入或離開數據層,可能被導入導出轉發或處理模塊。流量處理過程通過OAM引擎(操作(Operation)、管理(Administration)、維護(Maintenance))、一個加密模塊,一個虛擬網路模塊。可能是SDN控制器來控制流量轉發模塊和流量處理模塊,也可能是實現部署的與一個給定的SDN控制器相關聯的獨立的機制來實現模塊的控制。數據層使用在控制層作出的轉發決策。原則上它不能自主制定轉發決策。但是控制層可能會配置數據層,使得數據層能自動響應網絡事件比如網絡故障,或者使得數據層能支持如LLDP,STP,BFD,或ICMP交付的功能。(鏈路層發現協議(Link Layer Discovery Protocol、Spanning Tree Protocol、BidirectionalForwarding Detection、InternetControl Messages Protocol)

D-CPI包含如下功能:

*實現RDB公開的所以功能的可編程控制

*Capabilities advertisement

*事件報告

數據層代理是在數據層中執行SDN指令的實體。

通過數據層協調器的management模塊來分配數據層資源給不同的客戶代理並建立管理使用資源的策略。

在此架構中各個層的代理和協調器服務於同樣的目的,對此的介紹在Clause5中

在遞歸的最底層,數據層資源如包括軟交換機(soft switches)在內都是物理實體。在更高一級的抽象層,數據層資源不必是物理實體,比如虛擬NEs。就其它層來說,SDN架構運行在一個抽象的數據層模型之上,只要此模型advertised的功能被正確運行,底層的差異對於架構來說是透明的。Clause4.5討論虛擬化。

Management chooses which resourcesin which NEs are to be controlled by a given SDN controller

Management選擇在NEs中被一個SDN控制器控制的資源, 在5.1中介紹相關的操作。這些資源被當成虛擬NEs(VNEs virtual NEs)的集合,這些資源相互連接形成一個子網。在P37中的figure 4.14中介紹了,通過連續的抽象,VNE可能自己就是一個子網。

此架構沒有對數據層的技術強加任何的限制。SND控制器可能使用已經存在達到技術來編寫數據層比如DWDM,OTN,Ethernet IP等,或者在一個新出現的數據層技術上進行編寫。

4.3控制層

儘管在其他層中都存在不同程度的控制現象(這也是爲什麼叫做控制器層而不是控制層的原因),但是SDN控制器層中才是存在控制器的層(含有一個或多個控制器)。本章介紹SDN控制器的功能組件,以及該組件與其他控制器和其他administrative domains 的關係。會面會介紹,不是所有的SDN控制器功能都能分配給特定的功能組件;此架構認爲,分配一些對於本部件來說多餘的功能是沒有意義的。


4.3.1概述

此架構沒有詳細說明SDN控制器的內部設計。全文中提到的控制器中的功能組件只是爲了解釋說明用的。

SDN控制器邏輯上是集中式的

*控制器通常有子網範圍,該子網可能跨越單一物理NE

*與其他實體沒有資源衝突;SDN控制器被認爲是虛擬資源的擁有者,而這些虛擬資源是management分配給SDN控制器的。

功能和服務(服務是控制器外部可觀測行爲的一部分)包括完全可見的信息模型實例。依據環境,可能需要的額外的功能如下:

*拓撲知識和路徑計算(爲了實現這些功能控制器可能調用其他服務)

*通過更高級別的抽象資源創建和抽象資源維護來爲他的應用程序建模,使用的資源被強制執行的策略所限制。資源的虛擬化和控制可能是遞歸的。

SDN控制器應該用於協調大量相關的資源,

並且分佈於大量次級平臺,在此過程中,SDN控制器有時還要保證事務完整性。這就需要精心orchestration了。由於orchestrator自身具有的功能,orchestrator有時被當做一個SDN控制器,但是低級別控制器作用於受限制,於是不排除使用低級別SDN控制器的需要,在SDN控制器自己的控制域內執行orchestration。

 

4.3.2 SDN控制器

此SDN架構沒有詳細說明SDN控制器的內部設計和應用。它可能是一個單一的整體過程,它也可能是一個相同進程的聯合,用來分擔負載,或者用於彼此防止故障發生;可能是一個功能組件的集合,每個組件不相同,各個功能組件相互協調;他也可以爲他得功能訂閱外部服務,如路徑計算。這些可選項的任意組合都允許,SDN控制器被認爲是個黑盒,根據外部可觀察的行爲來定義它。控制器組件可以在任意的計算平臺上任意的執行,包括一個物理NE的本地計算資源。控制器組件也可能在一個分佈式的、可能移動的資源上如在數據中心的虛擬機器上(VMs virtual machines)

此架構從SDN原理中(clause4.1)得到SDN控制器必需的外部行爲。

其中一個原理是實現邏輯上集中控制,下面探究此原理;這裏足可以說明SDN控制器被理解成是擁有全局作用域的,(SDN爲了一些全局性問題存在的)同時也足以說明組件應理解爲用來共享信息和狀態,由此導致沒有其他Block的需要考慮來自控制器的衝突或矛盾的命令。Tothe extent that the OSS affects resources or states, it is subject to the samecoordination requirement with any SDN controllers that may be involved.

多種manager或控制器組件可能有網絡資源的結點寫訪問權限,但是爲了遵循SDN原理,他們必須也要:

a)被配置成能夠控制資源或活動的不相交集合,或者

b)能與其他manager或控制器組件相互同步,使得讓他們不發送前後不一致或矛盾的命令

注1:在對分佈式網絡資源的分佈式計算控制中,嚴格的狀態同步可能會帶來過多性能或複雜性的代價。最終狀態收斂而不是嚴格收斂的應用是未來一個研究的主題

注2從underlying數據層資源來看,控制器的內部一致性假設和狀態一致性的問題相分離。總是希望SDN控制器能處理相關的事件,這些來自基礎結構不同部分事件是異步可見的.

對於自舉,同步,事件遷移,備份,審計,控制器軟件發佈管理等都屬於“黑盒”SDN控制器的內部要做的工作,不是SDN架構的事,於是在本文沒有介紹,而不是忽略他們的重要性。

 

4.3.3 SDN控制器功能模塊

 

雖然SDN控制器是個黑盒,但是在概念化控制器中的一組最小功能組件集合時是很有用的。也就是說DPCF(data plane control function)協調器,仿真器,代理,(原文有介紹這四個概念)。爲了實現邏輯上集中式的要求,SDN控制器可能包含任意附加功能,一個RDB(resource data base)爲現在的信息模型實例和必要的支持功能來建模。clause5詳細介紹RDB和他的劃分。

 

4.3.4控制授權

儘管一個重要的SDN原理是數據層和控制層去耦,但是在數據層中的代理同樣可以行使控制,就像SND控制器一樣,有控制能力,但是沒有把它放在控制層中。進一步講,很多都有控制的模塊都可以考慮在NE中使用運行,如OAM,ICMP,MAC learning,neighbordiscovery,recognition andintegration, protection switching等。

對與去耦原理,一個稍有不同差別的解讀是允許SDN控制器把一部分控制功能下放到數據層,這些功能按照控制器方式運行。這個解釋對於在現實中使用SDN原理很重要。

符合以下條件的是鼓勵控制器把一些控制功能模塊放在數據層的:

*網絡事件需要快速實時響應

*大量流量需要處理

*面向字節或者位的功能,不容易被分包,例如重複性的SDH多路複用段開銷

*低價值、可能不斷重複的,可預測的,容易理解的,完全標準化的行爲,如加密,BIP,AIS嵌入,MAC learning,CCM交換

*控制器出故障或者重新初始化時的生存能力或持續性能力(Survivability or continuity )

*在數據層silion中一般可被訪問的功能如保護開關狀態機,CCM計數器或時鐘

*把功能模塊拆分出來沒有太大作用

假設原始數據可以達到,SDN控制器通常可以選擇不delegate a control function,但是可以選擇自己執行必要的操作。上面的準則會告訴我們如何選擇是具有實用性的。

在決定是否delegate a function時,SDN控制器必須明白delegate function的candidate替代者能不能完全滿足他的需求。這可能需要內置或者配置的知識,並且是/或者是需要查詢candidate的功能和能力。

來自delegatedfunction的通知建議使用publish/subscribe模型。通知的例子:

*被授權的控制功能模塊可能被要求需要做報告

1狀態或屬性值的改變,如端口的開關,操作狀態的使能或禁用

2針對性能監控(performance monitoring (PM) )計數器的TCAs(Threshold crossingalerts 超過閾值報警)

3硬件故障,恢復,初始化,因爲這些活動會影響SDN控制器控制範圍內的資源

4手動或自動保護開關事件和結果

在數據層的授權控制功能模塊可能執行標準的協議,彙報中間結果或最後的結果,異常或狀態改變。

例如:

1 通訊加密,包括密鑰交換和更新

2 CFM: 802.1ag or BFD

3 802.1X authentication agent

4 GMPLS ,提供SDN控制器,使用信號接入方式穿過administrativedomain 域界限,此時SDN可能不再被支持

 

4. 3.5共享資源

 

在圖4.2中的數據層模型中是假設資源是給客戶或者應用使用的,在一個專用的資源模型中,很少有機會增加基礎資源的使用效用。一個解決此問題的方法是約定使用盡最大努力共享資源的方式,可能同時使用優化的並加權的通訊約定。資源共享特徵的擴展是可能實現的,例如,資源的提供者可以儲備一些未授權的資源用於響應用戶請求時分配(同時進行相應的記錄),是按照先來先服務的原則,或者按照預先商定的順序分配。

最大化資源的利用率意味着這些資源可能被超額認購。

一個客戶請求一個非專有的資源,可用的資源可能不足或者根本就申請失敗,所以客戶必須能夠處理這些意外。對於不能獲得共享資源的可接受程度可能事先提供者和客戶達成約定。

另一種資源共享的方式是,每一用戶得到一個資源的一小部分,例如一條連接的20%的帶寬。在一些簡單模型中如用戶需要擁有所有管理目標實例,此時不能使用此方法。在能使用此方法情況下,一些此類資源可能靜態分配,而不是等到有需求請求是才分配。對於上述的超額認購問題可以一定程度避免。

SDN控制器有責任管理分配給多個用戶或應用的資源,無論是動態還是靜態的,對於每個相關用戶使用共同的標準。請求的改變和資源的釋放時會引起一些優化,通過資源提供網絡來實現。此架構沒有把此責任分配給某一個特定的SDN控制器組件。


4.3.6 多管理域(Multiple administrative domains)

在figure4.4中介紹一種情況,每個administration有自己的網絡,這些網路是相互連接的。拓撲和figure2.1相同,但是顏色改變,不同顏色表示不同子網的擁有者。

圖4.5中多個子網組成成了administrative domains,並抽象視圖,並用紅色代表重要的事情。也就是說紅色的能看到它自己NEs的所有細節和端口,但是藍色和綠色被抽象的儘可能簡單。


假設每個administrations都有SDNC(SDN控制器)無論什麼顏色


Figure4.6顯示了紅色SDN控制器聯繫的方式

(a)綠模塊提供一個服務,能夠無縫的包含綠色和藍色。爲了紅色域。藍色的資源租給綠色。紅藍之間沒有業務聯繫,紅藍之間資源相互聯繫只能通過綠色提供的虛擬的方式

(b)沒有特別的理由讓綠色作爲紅色的服務提供者,所以如此圖一樣變換位置

(c)紅色與藍綠都有合約關係

 

第四種選擇,在administrativedomains中紅色可能有個數據層切換點,它和administrativedomains沒有SDN programmaticrelationship(例如藍色沒有對同等域提供SDN控制的可見性)紅色SDNC可能認爲它網絡中的這個模塊靜態不提供連通性,例如作爲一組管道,或者運行傳統的路由和信令協議去學習可達性和建立到達或通過這個域的連通性。

本文其他地方介紹架構時考慮到了下面這種情況:當SDN控制器通過A-CPI提供服務,需要這種服務的客戶卻是另一個SDN控制器。如在4.7中白色表示客戶SDN控制器或是網絡感知應用程序,可能會部署大量服務控制器,When server controllers are orchestrated from a common point,基本上這個SDN控制器不需要同他周圍的控制器交流,在此,如果此客戶服務器爲了使得服務器控制器之間可以進行有限的信息交流而進行一些優化措施是允許的。使用到的原理是邏輯上集中式控制:客戶控制器可以授權控制功能在其他地方,只要他能完全能瞭解到對他們來說有價值的狀態信息就行。


4.3.7Controller-to-controller coordination

 

此小節考慮如下情況:存在大量對等的SDN控制器,但是沒有更高級別的SDN控制器來對他們進行部署。在把SDN控制器分離成不同的對等域時,可能會考慮如下多個方面:

*控制器可能來自不同的提供商,這些提供商之間沒有實現互通性

*控制器或者底層基礎設施可能被多個不同administrative組織使用或擁有

*控制器可能使用不同的技術或服務功能模塊

*網絡節點數或者地理跨度的可延展性,包括廣域網和局域網之間的不同

*等等

在通常情況下,一個通訊服務會橫跨多個數據層NCDs(network control domains),可會又經過某個不在SDN控制器控制之下的域。這些服務就需要在相關的SDN控制器和沒有使用SDN管理、控制或信號傳遞的域之間進行協調。對等信息交換通常被稱爲C2C(controller-to-controller)注意在C/S關係中的控制器之間和有信息聯繫但是不是C2C因爲不是對等網。

Figure4.8中有四個網絡控制域(NCDs)NCD1…NCD4,並畫出他們的SDN控制器了。圖中白色和藍綠有直接的聯繫但是和紅色只是間接聯繫,NCD3是個沒有SDN控制器的域,NCD3中結束或需要跨越NCD3的服務必須使用處在的信號或路由協議或者預先達成的約定。當控制器之間交流信息需要跨過另一個administrative界限(同時也是商業界限)時,安全問題和有關信息隱藏及信任的問題就成爲一個重要的問題。

 

控制器之間信息的交換可能含有如下內容:

*SDN控制器鄰接和能力發現

*數據層鄰接和拓撲發現,達到策略約定程度

*狀態和信息交換,包括狀態訂閱和屬性改變通知的能力。

*與信息轉發相關的信息,如到一個或多個層可達性

*路由計算信息利於路由計算代價,保護或恢復策略

*其他信息例如OAM配置,QoS評估和彙報,有關billing的使用信息

 

在最低軟實時限度內操作要達到同步,例如在一個域中建立loopback point,然後在不同域中調用一個loopback測試,最後釋放loopback point,這些信息交換通常在沒有SDN控制的域中也是相互兼容的,現在的信息交換使用的是已存在的協議。至今,no C2C usecase requirements have been identified that cannot be satisfied with existingprotocols, possibly with minor extensions.進一步的商談和策略交流纔是需要更深的研究。隨着SDN的不斷成熟,爲了更好的實現SDN C2C而開發一個新的協議的需求是未來的一個課題。

注意使用現存的協議實現的C2C關係的安全性被認爲是已存在的規範和best practice的事情,如果新的協議被提議,安全問題就是新協議重要的問題了。


(未完待續……由於此部分內容較多,請看下一篇博文。轉載請註明出處!)
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章