軟件定義網絡框架：OpenDaylight
OpenDaylight是一套以社區為主導的開源框架，旨在推動創新實施以及軟件定義網絡（簡稱SDN）透明化。面對SDN型 網絡，大家需要合適的工具幫助自己管理基礎設施，這正是OpenDaylight的專長。作為項目核心，OpenDaylight擁有一套模塊化、可插拔 且極為靈活的控制器，這使其能夠被部署在任何支持Java的平臺之上。這款控制器中還包含一套模塊合集，能夠執行需要快速完成的網絡任務。
SDN無疑是當前網絡業界最熱門的研究課題之一，SDN體現了控制和轉發相分離的原則，為網絡和業務的創新帶來了蓬勃的生機和活力。本文通過構建 OpenDayLight控制器與Mininet交換模擬器相結合的測試環境，研究了SDN環境下二/三層網絡交換的轉發機制和特性，并對SDN在網絡中 的應用提出了設想。
一.SDN實驗環境的選擇和建立
軟件定義網絡(Software Defined Network, SDN)最早由斯坦福大學clean slate研究組提出。SDN的核心是控制與承載相分離，實現網絡開放，使流量可以被靈活控制，從而為上層的業務和應用提供更優化的服務。SDN的概念提 出后，迅速得到了各方面的響應，在IT界、網絡屆掀起了一股熱潮。2010年，開放網絡基金會ONF成立，ONF致力于開發OpenFlow協議，以規范 控制器與交換機之間南向接口標準化，目前最新發布的版本為1.4。
在控制器方面，借鑒在IT和互聯網上的成功經驗，開源成為一股不可抵擋的趨勢。NOX，POX，Floodlight等均采用公開源代碼的形式，任 何人都可以學習SDN，只要有相應的IT編程能力，都可以為SDN的控制器的完善做出貢獻。各大設備廠商也正視SDN的挑戰，2013年4月IBM、 Cisco、微軟、NEC、Juniper、BigSwitch(后退出)等多家IT巨頭合作啟動了OpenDayLight項目。 OpenDayLight采用JAVA開發，是一套開源的SDN框架。其初期版本已經發布，本次實驗使用的就是這個版本。該版本支持簡單轉發應用 (Simple Forwarding)，可以支持二/三層轉發。
光有控制器還不能構成完整SDN網，但當前硬件SDN交換機還很少，也很難找到。幸好有Mininet推出了基于軟件模擬的交換機。Mininet 項目也是開源的軟件，通過Mininet，在一臺Linux主機內可以構造并模擬多臺SDN交換機和終端。使用Python腳本，使用者還可以配置較為復 雜的SDN網絡拓撲結構。同時Mininet還配備了WireShark抓包軟件，方便SDN開發者和學習者進行開發和研究。
二.OpenDayLight SDN二/三層轉發機制分析
1)創建和啟動SDN網絡拓撲結構
在測試中我們創建了如下的網絡拓撲結構，1臺OpenDayLight控制器(簡稱Controller，版本為0.1版)，2臺交換機(SW)， 每臺SW分別連接2臺主機(Host)，一共4臺主機，這些主機分屬于2個不同的網段，交換機與控制器之間采用OpenFlow協議(簡稱OF)。拓撲結 構如圖所示：
圖1：測試拓撲結構
首先在測試機(Windows XP系統)上安裝和運行OpenDayliht(具體可參考https://wiki.opendaylight.org/view /OpenDaylight_Controller:Installation)，然后在VirtualBox[4]中載入Mininet虛擬機映像并運 行(具體可參考http://mininet.org/download/)。測試網絡的拓撲結構由Python腳本生成，可將配置文件保存于虛擬機 /mnt/shared目錄下的topo2_2.py文件內：
啟動測試環境，使用以下命令生成測試拓撲結構： sudo mn –custom /mnt/shared/topo2_2.py –topo mytopo,–controller=remote ip=192.168.56.1。
通過啟動抓包軟件WireShark可以看到SW向Controller的注冊過程。在注冊過程中，Controller會要求SW提供 OpenFlow版本號，設備連接的端口等狀態等信息。如圖所示：SW1將自己所連接的4個端口情況上報給Controller(其中包括與 Controller相連的端口)，同樣SW2也會上報自己的狀態。
圖2：SW通過OF:Stats Relay向Controller上報自身的狀態和接口
當SW 設備完成設備注冊后，Controller將進行網絡拓撲結構的發現或更新。當網絡中有一臺新的SW接入后，Controller通過OF Packet Out 指令要求SW1在其所有端口上發出LLDP(Link Layer Discovery Protocol，EEE802.1ab)鏈路探測包。LLDP的源MAC為Controller分配，這里為00:00:00:00:00:01(對每 一個交換機，Controller都會分配一個這樣的MAC作為SW標識)，LLDP目的MAC地址為組播地址。相鄰的SW2將接收到LLDP，SW2由 于無法識別這條流，會將OF協議再發到Controller上。通過LLDP的發送和接收，Controller可計算出交換機之間的拓撲關系，網絡的拓 撲關系可作為轉發流表生成和實現網絡可視化的基礎。(注：與交換機SW相鄰的主機也會收到LLDP，但并不會處理)
圖3：基于LLDP探測的網絡拓撲發現與計算
2)SDN網絡二轉發機制
生成網絡拓撲后，還要在Controller上為每一個三層網段設置一個網關地址(即使是二層轉發也必須設置)，然后將交換機的接口與三層網關相關 聯。這里將SW1的2號(連接h1)和SW3的2號口(連接h2)分別與網關10.0.0.254關聯，將SW1的3號(連接h3)和SW3的3號口(連 接h4)分別與網關20.0.0.254關聯。這一過程好比在SDN內劃分了不的三層網段，并將設備物理接口與三層對應，類似為以太網劃分VLAN和增加 三層虛接口的過程。
圖4：在OpenDayLight Web界面將交換機的端口與三層網關相關聯
然后對各個Host的主機IP地址、子網掩碼和默認網關進行逐一設置，在Mininet提示符mininet>下如下設置：
接著讓Host1 PING Host2，輸入h1 ping h2，同時使用抓包軟件可得到如下的過程：
圖5：OpenDayLight SDN二層轉發機制圖解
在SDN網絡中，處于末端的主機Host并不會知道其連接的網絡是SDN，某臺主機要發送數據包到另一臺主機，仍然需要進行IP到MAC地址的ARP解析。但SDN的處理機制與普通二層以太交換機洪泛+MAC地址學習機制存在卻存在很大的差異，其過程如下：
當源主機h1(10.0.0.1)發出ARP解析h2(10.0.0.2)后，交換機SW1并不知道如何轉發該包，因此將其通過OF消息發送到Controller處理。
Controller發現這個ARP消息是h1(10,0,0.1)發出，它也同時得到了h1的位置信息(OF包中會指出是哪個交換機的哪個端口發 出了數據包)。此時Controller可以計算網絡拓撲，得到全網各節點到10.0.0.1的轉發路徑，并將轉發流表通過OF Flow Modify消息推送到每一臺交換機上。
由于收到了ARP，Controller會要求每一臺SW所對應10.0.0.0/8網段的非SW互聯端口(只有這些端口是連接主機或傳統網絡的) 發出ARP來請求10.0.0.2的MAC地址。這里Controller并不是簡單的將收到ARP原封不動的發出，而是將源IP改為 10.0.0.254，也就是前面我們在Controller上配置的網關IP地址，然后發出。
只有h3(10.0.0.2)才會響應ARP，它將ARP Response發送到SW2。SW2也不知道如何處理，因此將ARP封裝在OF協議中發送到Controller。Controller發現這是ARP 響應，而之前正是10.0.0.1發送的ARP請求，因此它會將該ARP通過OF協議發到SW1，同時指示SW1將其送出的端口(也就是h1對應的端 口)。SW1執行這一操作。
Controller在收到h3的ARP后也得知了10.0.0.2的位置，它根據網絡拓撲計算，可以得到全網到達10.0.0.2的轉發路徑，并將流表通過OF Flow Modify消息推送到每一臺交換機上。
h1 收到ARP Response后完成ARP解析過程，然后它構造ICMG PING Request數據包，其中源和目MAC分別為h1和h2的MAC，源和目IP分別為h1和h2的IP。由于SW1和SW2都已經成功的裝載了到 h2(10.0.0.2)的流表，因此該數據包將被順利發送到h2。
h2發現是ICMP PING Request，源是h1，但是此時它尚未有h1的MAC，于是還要進行一次ARP解析，SW2再次將ARP發送 Controller，Controller已經得知h1的MAC，可直接響應，并通過OF向SW2返回ARP結果和所需要送出的端口(h2接入的端 口)。
h2學到ARP后，即可構造ICMP Response包，發送到SW2，SW2根據h1目的地址匹配轉發表將其轉發到SW1，SW1根據h1目的地址匹配轉發表將其發送到h1對應的端口。h1到h2的雙向通道至此完全打通。
3)SDN網絡三層轉發機制
在分析完二層轉發機制后，我們重新啟動拓撲結構，回到初始狀態(交換機上無任何流表)，測試一下SDN如何實現兩個不同網段主機之間的轉發。輸入h1 ping h4，同時使用WireShark抓包，可發現如下結果：
對于三層轉發，主機首先判斷目的IP與自己不在同一網段內，因此要將數據包發向默認網關，在此之前它必須解析網關的MAC。h1發出 ARP，請求網關10.0.0.254的MAC。SW1不知道如何處理，將其通過OF協議發送到Controller。
Controller上配置了網關地址10.0.0.254，它即以自己的MAC地址回應ARP，并指示SW1將ARP響應發送到與h1相連的接 口。同時Controller也知道了h1的存在，通過路徑計算，得到每一臺交換機去往10.0.0.1的路徑，并通過OF Flow Modify將流表推送到每一臺交換機上。
主機h1收到網關的ARP，它構造ICMP PING Request數據包，其中源和目MAC分別為h1和網關10.0.0.254的MAC，源和目IP分別為h1和h4的IP，此包發向SW1。
SW1上并沒有到達20.0.0.2的流表，因此將緩存這個數據包。同時SW1則也會將該包通過OF協議發送到 Controller，Controlller發現該包是要去向20.0.0.2，而此目的主機位置未知。因此Controller會要求每一臺SW的對 應20.0.0.0/8網段的非SW互聯端口發出ARP來請求20.0.0.2的MAC地址，其中ARP的源IP為20.0.0.0/8的網關地址 20.0.0.254。
只有h4(20.0.0.2)才會響應ARP，它將ARP Response發送到SW2。SW2不知道如何處理，因此將ARP封裝在OF協議中發送到Controller。Controller接到這個ARP響 應，也同時得到了h4的位置是處于SW2的某一端口之下。Controller通過路徑計算，得到每一臺交換機去往20.0.0.2的流表，并通過OF Flow Modify消息推流表到每一臺交換機上。
SW1在裝載流表后可向正確的接口上轉發之前緩存的ICMP數據包，當然SW2也可順利轉發。SW2還會該ICMP包的目的MAC地址修改為h4的MAC，以確保主機正確接收(之前Controller下發的目的地址10.0.0.1流表中已指出這個操作)。
圖6：對20.0.0.2目的地址的流表下發
注：對與主機相鄰的交換機SW不僅要指該主機所對應流的出端口，還需要對目的MAC地址進行改寫以匹配主機MAC，因此下發的流表內有2個動作(Action)，對于二層轉發亦然
此時h4會收到ICMP Request，它發現是不同網段主機發出的ICMP請求，因此仍要通過ARP解析出自己的默認網關。此請求發送到SW2后仍要通過OF協議轉發到 Controller，Controller用自己的MAC進行響應，然后通過OF協議發往SW2，并最終發送到h4。
主機h4收到ARP后可構造ICMP PING Response，其中源和目MAC分別為h4和網關20.0.0.254的MAC，源和目IP分別為h4和h1的IP。此包發向SW2，然后經過 SW1，同樣SW1在將其轉發到目的端口前會將目的MAC地址修改為h1的MAC。之后h1和h4之間的通道被完全打通。
圖7：OpenDayLight SDN三層轉發機制圖解
當網絡的所有主機都完成一次的通信后，SDN控制器就感知了所有網絡節點的狀態。通過控制器提供的界面，可以看到網絡的可視化視圖(http://192.168.56.1:8080)，與我們之前給出的網絡拓撲完全一致!
圖8：SDN的網絡拓撲，由OpenDayLight SDN控制界面繪出
讓我們觀察一下各交換機上的流表，可見每個交換機裝載了正確的流表。隨后SW將定期向Controller匯報流的狀態，如匹配流的數量，轉發的字節數量、生存時間等。這些流和它們的狀態在OpenDayLight的控制臺上都可以看到：
SDN內網絡交換機的轉發流表
4)特殊網絡結構下SDN的轉發能力分析
在傳統的以太網中，是不能存在環路的，即使有環路，網絡設備也將通過生成樹協議Spanning Tree進行屏蔽。OpenDayLight控制器具有網絡拓撲的發現功能，在其算法中也能避免環路的產生(使用的是最短路徑優先算法，但在測試中仍無法 支持等價路徑負載均衡)。
如圖在測試中構建了5臺交換機(SW1-SW5)和5臺主機(h1-h5)，連成環形拓撲。通過測試表明，主機之間流量轉發正常，并沒有廣播風暴和環路出現，查看各交換機的流表，均顯示到目的地址采用的是最短路徑。
圖9：OpenDayLight SDN支持有環路的二層網絡拓撲結構
此外，OpenDayLight控制下的SDN網絡還可支持以靜態路由方式與外部網絡互通，但由于本次測試是基于軟件交換機的模擬，因此無法測試該功能。
三、總結
基于對OpenDayLight控制下SDN網絡轉發行為分析可以看到：
OpenDayLight的簡單轉發功能以整網的拓撲結構為基礎，Controller通過處理主機之間、主機與網關之間的ARP報文來獲得每一臺主機的位置，并采用最短路徑優先算法計算到達目的主機的流表，并下發到網絡內的各個交換機上。
在OpenDayLight的簡單轉發功能中，流僅僅基于目的IP地址進行配，而不是所有的5元組字段以及優先級字段(當然也可以選擇5元組)，這點更貼近傳統三層設備，可以大大減小了流表的規模，更為貼近實際生產環境。
OpenDayLight不僅可以支持二層轉發還可支持三層轉發，避免了環路和廣播風暴，優于目前其它類型開源SDN控制器所能提供的轉發功能。
OpenDayLight實現了控制和承載相分離，網絡上已經沒有二/三層設備之分，網絡充分扁平化。因此在同一SDN內，理論上可以在允許的地址 范圍內為主機分配任意可用的IP地址。這種做法解除了主機位置與IP網段物理位置的緊耦合(有點類似LISP，Location-ID Separation Protocol)，避免了IP地址段的碎片不能得到利用的尷尬。同時交換機與交換機之間也無需配置大量互聯IP地址，又節約了地址空間。
OpenDayLight支持與外部非SDN網絡的二/三層互通。
綜上所述，OpenDayLight的基本版已經實現了傳統二/三層交換機的基本轉發功能，并支持任意網絡拓撲和最優路徑轉發，達到了實用階段。 2013年年底，OpenDayLight的完整版本將發布，屆時將提供更好的多租戶支持(Tenant)，更好的網絡可視化(Network Virtualization)能力，實現LISP、BGP、Firewall等網絡應用，成為一款控制能力足以與傳統網絡設備匹敵的SDN控制器。
未來網絡軟件化的趨勢將不可阻擋，SDN將在支持數據中心虛擬化、城域網二/三層轉發和V*N、網絡安全和流量清洗方面大放異彩。