SDN最新研究進展
自SDN出現以來，關於SDN的研究一直沒有停止，只是不同的階段關於SDN的研究的重點不同。比如最開始的時候，探討最多的是SDN的可行性，以及如何將SDN應用到對應的網絡場景中。本文是筆者在最近閱讀2015年至今的若干SDN論文後總結的SDN最新研究進展，希望對讀者提供一些幫助。
SDN/NFVSDN和NFV都是當下網絡界研究的熱點，而如何將兩者整合部署，也是研究的熱點之一。設計SDN/NFV整合部署框架的研究是這個研究方向的主要研究切入點之一，比如參考文獻[1]中就提出了一個SDN/NFV的整體架構。框架中的NFV協調器可以和雲管理平臺配合使用，SDN控制器也支持與雲平臺結合。由於此類方案是SDN與其他技術/框架的集合，本身沒有太多創新性，論文中也僅僅介紹了其實現方案，所以此處不加贅述。
SDN/NFV結合還可以部署在很多場景，比如WiFi場景。OpenSDWN[2]就是一種軟件定義的家庭/企業WiFi架構框架。 將SDN與其他技術結合並應用在特定網絡場景是一種主要的研究方向之一。
流表優化OpenFlow所支持的細粒度流管理是SDN最大的優勢之一，但是細粒度的管理是需要付出代價的。爲滿足細粒度的管理，則需要更粒度的流表項。但是像OpenFlow協議這種細粒度的管理會帶來一定的時延，對於實驗敏感的短流業務而言，這個時延帶來的影響是不可忽視的，這很可能會抵消了SDN帶來的好處。所以如何通過流表來匹配流，從而減少流表項下發次數，是降低時延影響的有利手段。
此外，當網絡流數目過多時，交換機的流表空間就無法滿足需求。當流表滿時，爲了下發新的流表項，就需要將其他活躍的流表項刪除，這會讓更多的數據包轉發給控制器，從而增加了控制器的負擔，還也帶來了更大的時延，也會發生數據包丟棄現象。對於大象流而言，等待下發流表項的時延並沒有太大的影響。但是，對於短流而言，特別是對時間敏感的短流而言，時延的影響就很明顯。爲了避免這種情況出現，很有必要對流表項進行聚合優化。
OpenFlow協議支持通過通配符的方式來將數據流進行聚合，從而將多條流聚合成一條流來進行處理，比如交換機可以將目的IP爲10.0.3.0/16的數據包都統一處理，發送到端口1，而不是對每一個IP都下發一條流表項。這種通配符的方式大大減少了流表項的數目。但是，通配的方式也存在問題，比如使用通配符會提高編程複雜度。爲了降低使用通配流表項的難度，也爲了提高性能，ReWiFlow[3]提出了限制型通配符。限制型通配符定義了完整的匹配域排序規則，使得匹配域不能任意搭配，必須按照順序搭配。低優先級的匹配域需要在高優先級的匹配域被填充使用時纔可以被使用。這樣的排序限制了匹配域組合的自由度，但是卻讓管理流表項更容易。由於匹配域是固定順序的，所以可以通過前綴屬性來更簡單地管理流表項集合。
此外，爲滿足更多的流表項需求，ReWiFlow還支持使用多維度、不同匹配域優先序列的流表項。在實驗中，可以通過5組ReWiFlow的規則就可以描述超過1600條的ACL表項。這樣的流表空間壓縮率是非常可觀的。
關於流表項的優化一直都是SDN/OpenFlow領域研究的熱點和重點，讀者可以通過ReWiFlow的參考文獻順藤摸瓜進行深入研究。
數據分類/流表查找本質上，交換機將數據分類的過程也就是流表查找的過程。目前的OpenFlow支持的匹配域已經超過了40個，所以數據分類是一個漫長的過程。而且隨着新技術的出現，這個匹配域將會繼續增加。所以如何設計一個更高效、更具有可拓展性的分類算法來解決數據分類過程中的問題是下一階段SDN領域的研究方向之一。
數據分類的關鍵問題在於提升數據查找的速度。面對超過40維度的查找，如果簡單的逐維度，順序匹配，那會帶來十分高的時間複雜度。許多網絡業務對時延很敏感，這種低效率的做法無法適應網絡設備的要求。從算法的角度來講，通過多次模糊查找，逐漸分類並縮小查找範圍，最後再精確查找是一種可行的思路。
」Many-Field Packet Classification for Software-Defined Networking Switches「[4]論文就提出了一種可拓展的多域數據分類算法，其由選擇性位連接的多維度劃分來實現數據分類算法（A scalable many-field packet
classification algorithm using multidimensional-cutting via selective bit-concatenation (MC-SBC) for OpenFlow-based SDN switches）。其核心的思路是通過獲取多個域的不同比特位，並將其連到一起作爲key，然後具體有相同key的流規則放在一個集合中。不同的比特位選取的結果左右不同的樣本空間，從而形成多維度的樣本空間。在查找時，通過取不同比特位組合的key可以快速地找到樣本空間，然後取樣本空間的交集即爲對應的分類，也就是對應的流表項。
圖1. 分類器架構圖
Policies Composition/Consistency網絡中存在着許多網絡策略，比如ACL和SFC。同時，網絡中的策略往往是由不同人羣制定的，他們可能是網絡的管理員或用戶，也可能是虛擬租戶網的租戶。不同網絡使用者的決策是相互獨立的，也是動態的，所以很多時候不同的策略之間會產生策略衝突。目前的策略衝突解決方案僅僅實現了運行態的衝突檢測，即只有當策略被部署之後，網絡在運行時發生故障，性能出現惡化時，安全漏洞等問題才暴露出來。而這只是一種衝突檢測，其無法實現衝突的預防，更不能實現策略的編排，解決策略衝突。
爲解決這個問題，PGA（Policy Graph Abstraction）[5]提出了使用圖結構來檢測來自多個用戶之間的策略衝突，並實現衝突解除。PGA支持在策略下發到底層設備之前完成策略衝突檢測和衝突解除，且其提供的抽象模型實現了策略與底層網絡之間的解耦合，從而降低了用戶在制定網絡策略時的壓力。PGA支持ACL以及SFC等多種策略的衝突檢測和協調，其關注點只是部署策略前的檢測和協調，並不關注運行態的衝突檢測。通過使用大型企業網數據的測試，驗證了PGA其可行性，證明了PGA不僅支持大量數據的處理，同時時延表現還很好。
此外，多控制器在協同工作的時候，還需要對數據進行同步。在沒有數據同步的情況下，相互獨立的控制器對交換機安裝的策略都是沒有經過沖突檢測的，可能存在競爭和衝突，所以多控制器系統的信息同步非常有必要。交換機上發生策略衝突主要是因爲控制器沒有辦法獲取到交換機上的策略狀況，無法進行策略衝突檢測，所以如果能在交換機上進行策略衝突檢測，就可以解決這個問題。相比通過帶外方式實現的控制平面的數據同步和策略衝突檢測，在交換機上實現衝突檢測的辦法更簡單，消耗的資源更少。
「In-Band Synchronization for Distributed SDN Control Planes」[6]論文提出了通過帶內方式實現的分佈式控制平面的同步機制。其核心的思想是使用交換機的部分配置內存來做衝突檢測，然後保證所有的事務都是原子操作，從而保障數據的一致性。當多控制器同時併發給交換機寫入策略時，很可能帶來競爭和衝突，所以很有必要通過加鎖來實現策略寫入的原子性，從而保障數據讀取和修改的一致性。論文中提出了使用部分交換機的內存作爲衝突檢測所需的內存，用於存儲那些等待執行的指令。論文還設計了「compare and set」原語集，支持命令執行的衝突檢測等行爲。在安裝FlowMod等操作時，需要檢測是否有策略衝突，若無衝突，則可以安裝，否則放棄。控制器也可以通過讀取狀態原語來獲取交換機上的配置信息，以便作出沒有衝突的策略。本質上，這是一種在數據平面上保證數據一致性的解決方案。
但是，就算控制器策略計算正確，多控制器之間操作也沒有衝突，也無法保證數據包在數據平面按照控制器制定的策略去處理。目前關注於控制器平面的策略正確性的研究已經很多，他們普遍努力於如何解決策略衝突，但是控制平面的正確策略不能保障數據平面的正確，所以還需要對數據平面進行監控，來保證數據平面的策略一致性。
VeriDP[7]提出了監控數據平面策略一致性的解決方案。其核心思想十分簡單：控制器在計算數據轉發路徑的時候，將數據包頭和轉發路徑信息映射關係存儲起來；在數據平面上，交換機需要對轉發的數據打標籤，從而記錄數據轉發的路徑；當數據離開網絡之前，將數據包頭和標籤上報給VeriDP服務器；VeriDP服務器可以將報頭信息和控制器存儲的映射關係進行對比，若匹配成功則說明數據平面的實際表現和策略一致，否則數據平面出現了故障。選擇集中式的服務器進行檢驗是因爲單節點的交換機無法感知全局的策略，所以在數據包丟失等情況時，並不知道這是策略指導還是發生了故障，但集中的控制器掌握全局的策略，所以它的信息可以用來進行判斷策略一致性。
當然，除了以上的問題，流表一致性問題也是值得研究的課題。控制器給多個交換機下發新流表時，沒有辦法做到同時修改，所以必然存在一個時間段，使得有的交換機的流表項已經更新，而其他的交換機還保留了原有的流表項，這就可能造成環路或者丟包的現象。爲解決這一問題，「Monitoring Dynamic Modification of Routing Information in OpenFlow Networks」[8]論文提出了一種監控和分析解決方案，可以對路由信息改變時網絡的行爲進行監控，並對其行爲進行系統整合分析，從而進行優化，減少丟包率等現象。
安全相關SDN的集中控制給解決網絡安全問題提供了很多方便。一直以來，網絡安全都是研究的課題，當SDN出現之後，如何利用SDN去更好地解決網絡安全問題成爲了新的研究課題。此外，SDN本身的安全成爲了新的研究課題。比如攻擊者可以通過數據包返回的時間來獲取到什麼樣的數據包會上交控制器，進而利用這一信息攻擊控制器[9]。
Debugging/Trouble Shooting網絡與軟件不同，其調試和故障排查十分複雜，所以SDN的調試和故障排查一直是研究熱點。
「One Tool to Rule Them All」[10]這篇論文主要提出的是一個輕量級的框架，可以靈活組合現有的故障排查工具來實現複雜而多樣的故障排查功能。由於計算機網絡的分佈和異構，在網絡中進行故障排查一直以來都是非常困難的事情。而SDN的到來也帶來了更多的問題，不僅需要檢查網絡的故障，控制器/VNF/交換機等軟件的實現是否存在BUG也成爲新的需要解決的問題。
面對這麼多的問題需要排查，目前已經有了許多解決方案，比如NICE[11]等。但是這些解決方案都是針對特定的網絡問題，無法全面地解決網絡故障。然而在解決一個網絡故障時，往往需要到多個軟件組合才能完成。所以還需要一個整合平臺來實現多個工具之間的靈活組合，這就是「One Tool to Rule Them All」論文的主要切入點和貢獻。論文中設計了故障排除的圖（Trouble Shooting Graph）來給故障排除建模。然後針對故障模型，可以配置對應的故障排除信息，從而通過調用多個工具來實現複雜的網絡故障排除。
在很多網絡業務場景中，需要掌握數據包的轉發路徑信息，從而更好地診斷網絡。原有的轉發路徑跟蹤解決方案的思路主要有帶外和帶內兩種。基於帶外的解決方案需要消耗大量的流表空間，也產生大量的帶外數據，但是帶外方式節省了報頭的空間，沒有對數據包進行額外的修改。基於帶內的解決方案則對數據包頭進行了修改，從而節省了大量的流表空間，也不會產生帶外的開銷。極端的帶內解決方案是給網絡中的鏈路獨立的編號，然後將編號插入到數據包的報頭，從而實現數據包轉發路徑的追蹤，但是這樣產生了過大的報頭開銷。
CherryPickp[12]則在現有帶內解決方案的基礎上進行了改進。由於數據中心網絡Fattree拓撲的規律性，可以通過計算關鍵鏈路來映射出完整的轉發路徑，從而節省報頭開銷。CherryPick的主要貢獻是設計了一套算法，從而將報頭開銷降到最小，其規則如下：
ToR: 如果ToR收到了Agg發來的數據包，而且數據包的源地址與目的地址都在同一個pod內，則ToR記錄連到Agg的入口鏈路的ID。如果源地址和目的地址都在同一個pod內，而且不經過Agg,也即在一個ToR上，將忽略入端口。其他情況下，均不記錄鏈路。Agg: 如果Agg從ToR收到數據包，且數據包的終點在同一個pod內，則入鏈路被選中，其他情況將不記錄鏈路。（有的時候，數據包會在ToR和Agg中轉圈，然後再到達真正的目的地）Core: 核心層交換機始終只挑選入鏈路。在此算法之下，可以通過記錄路徑上的關鍵鏈路來映射出完整的數據包的轉發路徑，從而將報頭開銷降到最小。
圖2.CheeryPick選取關鍵鏈路示意圖
SDN應用到WiFi無線場景， IOT，ADHOC等場景SDN作爲一種新的網絡模式，目前正在被用於如5G網絡，IOT，Ad-Hoc等網絡場景，也產出了OpenSDWN等研究成果[2]。將新技術框架放在不同場景的做法是研究中最常見的做法之一，但這和SDN本身的研究並沒有太大關係，所以此處不再展開，有興趣的讀者可以自行研究。
SDN Large Scale ScalabilitySDN的控制平面能力是有限的，當SDN的規模擴展到足夠大的時候，就需要對其進行分域治理。而且出於業務場景的要求，許多大的網絡的子網絡分別使用着不同的網絡技術，使用着不同的控制平面，所以就需要實現多控制器之間的合作。多域控制器的協同工作一直是SDN研究領域的一個大方向，但同時也是一個很艱難的方向。
STRAUSS[13]項目提出了一個解決方案。其設計了一個「控制器的控制器」作爲Domain控制器的協調者，從而實現跨域端到端的通信。由於各個域採用的技術不同，所以這些異構的域在相互協同時就需要進行抽象，從而消除具體技術帶來的差異性，進而讓網絡編排控制器統一管理。爲實現控制器之間的通信，論文設計了一種COP協議（Control Orchestration Protocol）。
同樣的解決思路還有OXP協議，其協議內容目前還無法公開。OXP實現的多域異構控制器之間的協調工作，提升了SDN的可拓展性。此外，其還提供了多種模式，可適應多種網絡場景的具體需求。
更多的關於SDN可拓展行的研究[14]，讀者可以閱讀相關調研[15]。
Fault Tolerance/Consistency由於SDN是一種集中式的架構，所以單節點的控制器成爲了整個網絡的中心。當控制器產生故障或者錯誤時，網絡就會癱瘓。爲了解決控制器故障給網絡帶來的故障，分佈式控制器等多控制器方案早就已經被提出。相比單控制器而言，多控制器可以保證高可用性(High Availability)，從而使得在某個控制器實例發生故障時，不影響整體網絡的運行。另外，爲保障業務不終端、不衝突，多控制器之間信息還需要保持一致性，才能實現Fault Tolerance。
當故障發生時，多控制器之間的信息一致性能爲接管的控制器提供正確管理交換機的基礎。然而，當前的一致性研究內容還僅僅關於控制器狀態信息方面，而沒有考慮到交換機的狀態信息，這將導致交換機重複執行命令等問題。然而，許多操作並非冪等操作，多次操作將帶來更多問題，所以不能忽略命令重新執行的問題。而且由於沒有關於交換機狀態的記錄，交換機也無法回退到一個安全的狀態起點，所以簡單狀態回退也是不可取的。更好的辦法是記錄接收事件的順序以及處理信息的順序及其狀態。此外，還需要利用分佈式系統保持全局的log信息一致性，才能讓交換機在切換控制器時不會重複執行命令。
因此Jennifer教授團隊提出了Ravana[16]，設計了一個擁有兩個階段的協議，用於記錄事件接收順序和事件處理順序。當事件從交換機上報給主控制器時，主控制器會將這個事件的順序信息記錄下來，然後與從控制器同步。當交換機執行完事件的處理命令時，會返回執行完成信號給主控制器。主控制器從而結束整個事件/事務處理的週期，並將處理完成的狀態信息同步給所有的從控制器，從而完成數據同步。通過這種方式，控制器可以收集到事件處理的具體狀態，從而使得當控制器發生故障時，其他控制器可以精確地瞭解到事件處理的狀態，從而繼續完成事件處理。這種設計不但保障了控制器狀態的一致性，也同步了交換機的狀態數據，使得無論控制器還是交換機發生故障時，都不會影響到業務的正常進行，從而實現無故障的應用運行。
SDN與大數據SDN與大數據等其他技術的結合也是一個研究方向。當大數據和SDN[17]結合時，SDN可以提高大數據網絡的性能，而大數據的數據處理能力也可以給SDN決策提供更好的指導。由於這種研究屬於應用範疇，不加贅述。
總結在筆者閱讀論文的時候，發現目前主要的SDN研究方向有：多控制器協同的可拓展性問題，網絡調試和故障排查，策略編排，流表優化等方向。當然SDN與NFV、大數據等其他技術的結合也是一個研究方向。此外，SDN應用在各種網絡場景中的研究依然層出不窮。在2015年到2016年這段時間內，還沒有更多關於SDN數據平面可編程性的研究成果，其主要原因在與2014年左右的POF和P4已經走在前列，而更多的研究還來不及發表。但筆者堅信，SDN數據平面可編程性以及SDN編程語言等研究將是未來研究的一個大方向。但是這個方向門檻較高，所以研究的人員比其他方向少一些。本文是筆者最近調研成果，希望可以給讀者帶來一些幫助。
作者簡介：
李呈，2014/09-至今，北京郵電大學信息與通信工程學院未來網絡理論與應用實驗室（FNL實驗室）攻讀碩士研究生。
本文轉自d1net（轉載）