Gather：一種能夠優化這些用于轉發控制流的流表項的方法

? ? ? ? 帶內控制（in-band）的SDN網絡由于有著良好的靈活性以及部署的經濟性，已經受到了越來越多的關注。但是在帶內控制的SDN網絡中，控制流和數據流共用一個一個物理鏈路進行轉發。因此，交換機需要存儲用于轉發控制流的流表項。這在一些大型網絡，例如數據中心網絡中會造成一些接近控制器的SDN交換機流表項過多的問題。大量的流表不僅會帶來管理的復雜，還會占用例如TCAM等網絡資源。所以我們提出了Gather：一種能夠優化這些用于轉發控制流的流表項的方法。

設計介紹

　?。?） 設計根據

　　下圖是傳統帶內控制下的SDN網絡的流表分布圖（本文中只關注一個控制器的情況）：

　　圖表 1：傳統SDN網絡中流表的組織方式

　　在一個網絡拓撲中，如果使用最短路徑算法計算各個交換機到控制器的路徑，可以得到一個樹狀的控制拓撲圖，Gather便是基于這一樹狀的拓撲圖進行優化。從圖可以看出傳統網絡中流表存儲的特點是靠近控制器的交換機需要為之后的子節點存儲控制流的流表項，因此越是靠近樹根（控制器）的交換機需要存儲更多的控制流的流表項。而在交換機數量很多的網絡中，例如數據中心網絡，這會造成靠近控制器的交換機出現一個明顯的流表數量激增的現象。Gather的主要目標是減少這些不必要的流表開銷。

　?。?）設計思路

　　Gather的基本思路是將拓撲中的交換機劃分為一個個組（group）。一個組相當于整個控制樹的一個聯通子集。同時一個組由一個標簽（label or tag）來表示。實現標簽的方式有很多，在本文中，我們使用segment routing來實現標簽系統。下圖是Gather的示意圖：

　　圖表 2：Gather 實現流表項優化示意圖

　　從圖中可以看出S2，S3，S4被分為一組，所有被發往該組的包都被打上X標簽（label）。S2在收到包之后，通過匹配X標簽，就會知道該包是發往組內交換機的數據，之后其會繼續在流表2中匹配該包的流表，決定轉發策略。同時，在對拓撲進行一輪優化之后，仍然可以在現有的分組基礎上進行第二輪優化。具體的做法是將組都視作交換機，進行替換。之后會得到一個縮小的拓撲，可以在該拓撲上繼續重復優化，進一步減少控制流的流表。但同時數據包中的標簽會增加一個。

　?。?）如何找出有效的組（group）？

　　可以找出有效的組的方法有很多，可以根據需求自己設計需要的算法。在介紹算法之前，首先給出其中的一些定義：Node distance指一個節點到控制器的中間節點的個數，S指子節點的集合，G是最終輸出的組的集合，time of optimization是指全拓撲優化的次數，一次optimization之后需要修改拓撲（進行組和交換機的替換）。在本算法中，基本的思路是先利用深度優先算法，從葉子節點開始計算。從算法中可以看出，其使用迭代的思路，一直延伸到一個葉子節點后向上逐個節點進行計算和比較。之后其會根據比較的結果決定組的分布。

設計測試

　　首先，我們對數據包中的label（本論文中使用segment routing實現組的結構）對于轉發延遲的影響進行測試。測試結果如下：

　　圖表 3 Label數量對轉發延遲的測試結果圖

　　從表格中可以看出label對于轉發延遲的影響比較小，即使在3個label的情況下也只比傳統轉發多了4%的延遲。之后我們對優化流表的能力進行測試，結果如下：

　　圖表 4 流表優化結構示意圖

　　在三種拓撲中可以看出第一次優化的結果普遍較好，而第二次，第三次優化的比例下降的特別快。這是因為在一遍優化，將組替換為交換機之后的拓撲會比優化之前的拓撲小很多。因此可以優化的流表項也會少很多。同時，這與算法的設計也會有一定的關系。