精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

ODL和ONOS等雖然在拓撲性能和應用開發便利度上有了很大進步，但是它們的靈活性、工作速度和效率仍有待提高。因此，隨著大數據浪潮的到來，我們迫切需要可面向云計算數據中心的性能更完善、開發更便利、效率更突出的SDN控制器。

為了解決上述問題，我們設計了一款面向云計算數據中心開源SDN控制器——DCFabric，其從上至下依次可分為五層（見圖1）：第一層是控制器支持的Web應用層，第二層是北向接口層，第三層是包含SFabric模塊的系統應用（System APP）層，第四層是為上層應用的正常運行提供保障的基礎服務層，最后是基于OpenFlow等協議的南向接口層。

DCFabric可支持的Web應用主要包括Web GUI、Neutron接口、流量工程、防火墻、負載均衡、DDoS防御等。因此，DCFabric可為數據中心在網絡管理、網絡虛擬化、網絡安全、網絡流量控制等方面提供一系列支持。

Restful API是DCFabric向上層應用開發者提供的北向接口，它能將網絡應用和網絡細節彼此隔離，使得網絡中的各種設備、事件（如鏈路中斷）和具體操作對應用程序而言都是透明的。因此，數據中心可通過各種靈活的網絡應用來提升用戶的體驗，實現網絡的智能化和安全化。

相比較已有的其它SDN控制器，DCFabric主要有兩點不同：

考慮到單個控制器的工作能力畢竟有限，為了應對數據中心不斷增長的網絡規模以及保證其健壯性，DCFabric還支持控制器的集群化（Cluster）部署。如果某個控制器出現問題，則SDN交換機可馬上連接另一個控制器。并且多個控制器通過協同工作表現為一個邏輯實體，使得數據平面對應用程序而言是透明的。因此，DCFabric的集群化對于實現高吞吐量、低時延、好的靈活性以及強穩定度的數據中心是非常有益的。

SDN控制器雖有利于網絡資源利用率的提升，但隨著數據中心規模的擴大，SDN控制器仍面臨著一個主要問題：交換機和用戶主機數目的增長，使得每個交換機需存儲的流表內容也在相應增加（理論上每臺交換機上的流表最多需覆蓋到網絡中的所有主機），這不僅需要每臺交換機有更大的存儲容量和更快的查詢速度，也對SDN控制器的工作效率提出了更高的要求。

我們對現有的SDN控制器進行了改進，設計了新穎的SFabric架構，使得SDN控制器的工作負載大大減少，從而有效地提高了控制器的工作效率。

在SFabric中，每個交換機都會向其所有的端口發送鏈路層發現協議包（Link Layer Disvovery Protocol, LLDP）。由于主機會自動忽略LLDP包，所以之后每個交換機就可知道到底哪些交換機是和其直接相連的。當DCFabric從各個交換機獲取了一定信息后，就可知道整個網絡的交換機拓撲情況。接下來，DCFabric會為每對交換機之間設置一條通信路徑（出于流量均衡等考慮，該路徑并不一定是最短路徑），并且為所有目的交換機（與目的主機直接相連的交換機）相同的路徑設置一個專門的標簽（目的交換機的ID）。然后，DCFabric會把路徑信息裝載到交換機的流表項中，這樣交換機就能根據標簽來轉發數據包。以圖3為例，假設交換機1到交換機2、3、4、6的路徑分別為1→2，1→3，1→2→5→4，1→3→4→6，則交換機1的路由表將如圖3底部的表格所示。例如，第四個流表項表示標簽為6（目的交換機為交換機6）的數據包將從交換機1的端口2輸出。因此，SFabric可幫助DCFabric實時迅速地構建好交換機級別的路由規劃，從而為后續數據包的端到端單播路徑建立預先做好準備。

當然，考慮到與其它現有OpenFlow交換機的兼容性，SFabric也允許用VLAN ID或MPLS Label替代目的交換機ID。由于OpenFlow從1.1版開始就可支持多流表，所以SFabric在每個交換機中都建立了四個流表來實現流水線式處理，具體如圖4所示。假設在流表中使用VLAN ID作為路由標簽，四個流表的具體結構和工作過程如下。

Table 0用于包的預處理。它包含p+2個流表項，其中p表示與當前交換機直接相連的交換機的個數。p個流表項的格式為“port=i, ip, actions=goto table:2”，其中1≤i≤p，表示將來自其它交換機的IP包送往Table 2。剩下的2個流表項格式為“ip, actions=goto table:1”和“arp, actions=Controller”，表示將來自當前交換機下的本地主機的IP包和ARP包分別送往Table 1和DCFabric。

本地主機的數據包在發送前需要在當前交換機被打標簽，而Table 1則負責存儲執行相應操作的流表項。因此，Table 1在初始化后是空的，需要在后續的網絡會話通信中逐漸豐富其中的流表項。

Table 2則根據目的交換機的ID來轉發數據包，它最多可包含s個流表項， s表示網絡中的交換機總數目。其中s-1個流表項的格式為“dl vlan=i, actions=output:j”，表示將VLAN ID為i的數據包通過當前交換機的端口j被發送出去。最后1個流表項的格式為“dl vlan=k, actions=pop vlan, goto table:3”，其中k為當前交換機的ID號，表示若當前的交換機下就是目的交換機時，則數據包應發往Table 3。

Table 3根據數據包的MAC或IP地址，將收到的數據包發往當前交換機下的某個目的主機。所以Table 3在初始化后也是空的，每當當前交換機下的某個主機被發現時，就在Table 3中建立一個相應的流表項。

因為交換機級別的網絡拓撲已被預先建立，DCFabric才可對數據包路徑建立的流程進行優化，即DCFabric對目的主機相同的通信需求只需進行一次處理，從而使網絡流的表數目和DCFabric的工作負載都大幅降低。

當DCFabric收到一條來自交換機的packet-in信息時（比如ARP請求），它需要首先確定源主機和目的主機的地址。如果DCFabric的數據庫中暫時沒有目的主機地址的信息，那么DCFabric將會把該ARP請求以泛洪的方式發送到所有交換機的每個端口。無論是獲得ARP請求或ARP響應，一旦DCFabric捕獲到一臺新主機的信息，它就會在與新主機直接相連的交換機的Table 3中添加一個新的流表項。圖5描繪了源主機A（與交換機1直連）和目的主機B（與交換機6直連）之間的單播路徑建立過程。step1和step2是將ARP請求傳遞到DCFabric。當DCFabric收到來自目的主機B的ARP響應后，它會分別向交換機1和6的Table 3各下發一個流表項（step 3和step4），它們的格式分別為“ip, nw_dst=IP_A, actions=output:3”和“ip, nw_dst=IP_B, actions=output:1”。前者表示主機A與交換機1的端口3直連，后者表示主機B與交換機6的端口1直連。

接下來，DCFabric向源主機A發送一條ARP響應消息，并分別在交換機1和6的Table 1中各裝載一條流表項，如圖5底部所示（step 3和step4）。以交換機1中的Table 1為例，前往目的主機B的數據包會被打上目的交換機6的ID標簽（step 5和step6）。單播路徑沿途的交換機則會根據目的交換機的ID對數據包進行轉發。當數據包到達目的交換機6后VLAN ID會被清除，然后該數據包會被轉發到目的主機B。反向傳遞也是如此，不同的是標簽變成了交換機1的ID。

因此，在網絡運行時，DCFabric可實時感知交換機的狀態是否發生任何改變（比如新交換機的加入或舊交換機的退出等），并以增量更新的方式通過對網絡的局部調整來快速構建新的網絡拓撲和交換機路徑。

SFabric具有良好的可擴展性，尤其適用于包含大量交換機和主機的超大型數據中心。一般來說，網絡中的交換機和主機數量越多，往往意味著一個交換機中需要維護的TCAM表也就越大，相應地會造成查找表的成本上升和效率下降。因此，網絡中的流表項數目便成為評估一套SDN方案是否具備良好可擴展性的重要依據。在SFabric中，假設單個核心層交換機中最多含有s′個流表項（s′是接入層交換機的數目），和網絡中的主機數量無關。對于接入層的任何一個交換機來說，其中的Table 2的流表項上限為s′；Table 1的流表項個數H等于和當前交換機下所有主機有會話通信關系的主機數目。假設單個主機最多會和α個主機通信，則H = p α，其中p為當前交換機下的主機數目。因此，網絡中流表項數目N的最大值如式（1）所示，其中s為核心層和接入層中所有的交換機數目。

(1)又因為網絡中的主機數目遠遠大于交換機的數目，因此s + p α ≈ p α，則N ≈ s′ p α。然而，在大多數其它SDN方案（比如OpenDayLight和Ryu）中，每個交換機需要為網絡中的每對主機至少配置一個流表項，因而造成網絡中的流表項數目N′如式（2）所示，其中β為每條路徑平均包含的交換機數目。

(2)因為N/N′ ≈ s′/s/β < 1/β，所以網絡的拓撲越寬廣（β越大），表明SFabric對降低網絡中流表項數目的效果越明顯。
在傳統的以太網或其它SDN方案中，核心層的交換機往往因為需要維護大量的信息而導致TCAM過于龐大，因此限制了網絡的規模。然而在SFabric中，接入層的交換機可以是軟件虛擬機，因而相對物理交換機而言可維護更多的流表項；并且由于核心層交換機是面向接入層交換機的，所以每個核心交換機中的流表項數目可以是一個和主機數目無關的較小的固定值(s- s′) s′。交換機中流表數目的降低，不僅使SFabric具有非常良好的可擴展性，而且同時意味著控制器的工作負載（包括流表信息維護以及與交換機之間的溝通交互操作等）和成本也相應有所減少，所以SFabric有著更好的工作效率、速度和吞吐量。如表1所示，相對傳統網絡或已有的SDN技術而言，SFabric能幫助DCFabric在同一網絡中控制更多的交換機和主機，并且擁有更快的工作速度。

由于DCFabric可向OpenStack提供可支持最新Juno版本Neutron API接口，所以OpenStack可通過該接口與控制器進行網絡和地址管理方面的交互。作為OpenStack和下層網絡轉發設備（SDN交換機）的中間媒介，DCFabric兼具傳統轉發設備中的網關、路由和NAT等功能，可對網絡資源進行集中控制，并支持物理/虛擬交換機的混合組網。因此，如圖6所示，DCFabric可以與云計算平臺OpenStack實現無縫融合，對網絡資源實現集中管控、資源池化、多租戶共享和在二層網絡的安全隔離，提升面向公有云資源的服務體驗（比如虛擬私有云（Virtual Private Cloud, VPC）），為大型數據中心的大吞吐量數據交換提供有力的技術保障，促進云計算產業的發展。

5、總結
DCFabric是我國第一款基于SDN的開源控制器，目標是為大規模云計算數據中心提供一套切實可行的SDN開源技術方案，主要具備以下優點：
1）與已有的其它SDN控制器相比，DCFabric的靈活度強、可靠性高、智能化高、吞吐量大、延遲低。

2）其北向接口可與云計算平臺OpenStack無縫融合，支持各種網絡應用，降低創建新服務的難度，為網絡應用開發帶來敏捷性。

3）其南向接口支持OpenFlow協議的轉發設備，并且具備可與傳統網絡設備兼容的特性。

該項工作有利于促進我國SDN技術在自主創新方面的快速進步，以及云計算產業和數據中心業務的發展。

作者簡介：
蔣暕青@上海寬帶技術及應用工程研究中心：SDN技術實踐者，大四北上思博倫實習半年，現工作地點上海