中文摘要

　　軟體定義網路(Software-Defined Networking)是近年來很熱門的研究題目，透過中控的網路控制器(Controller)就可以控制底下所有的網路設備，以綜觀的角度進行網路的封包傳遞路徑的優化、或者是網路安全的監控，而本論文提出的ECOE(Ethernet-in-Core OpenFlow-at-Edge)是一種軟體定義網路的網路模型，在整個網路的邊緣佈署OpenFlow交換機，並且在網路的核心部分佈署一般的乙太網路(Ethernet)交換機就可以提供軟體定義網路中大部份重要的功能。

　　本論文說明ECOE架構如何為不同種類的封包任意控制路由路徑， 並且可以彈性的限制廣播和群播範圍、也可以對整體網路進行動態的流量負載平衡的設定，最後還會說明ECOE的架構如何支援網路功能虛擬化(Network Function Virtualization)中服務鏈(Service Chain)的功能。

Abstract

　　Recently, Software-Defined Networking is a popular research field. The controller can centrally control network devices enhancing network throughput and security by its global information. This paper will introduce a new network model which calls ECOE (Ethernet-in-Core OpenFlow-at-Edge). It can support most important functions in Software-Defined Networking (SDN)by deploying Ethernet switch in the core network and deploying OpenFlow switch at the network edge.

　　This paper will introduce how ECOE network model can support flow-based routing,flexible broadcast/multicast domain, dynamic traffic load balancing and service chain in netwo rk function virtualization (NFV).

關鍵詞(Key Words)

軟體定義網路 (Software-Defined Networking；SDN)
混合式軟體定義網路 (Hybrid Software-Defined Networking)
乙太網路 (Ethernet)
網路功能虛擬化 (Network Function Virtualization；NFV)
服務鏈 (Service Chain)

1. 前言

　　軟體定義網路(Software Defined Networking; SDN)是目前熱門的研究主題，透過中控的網路控制中心(Controller)來控制底下的網路設備， 取代以往各個設備使用分散式演算法來決定網路封包流向的行為，可以綜觀的設定每個封包的路徑，提升網路效能，也可以為每個封包決定要經過的網路服務節點，提供網路服務鏈的功能。

　　目前SDN的大趨勢是在Controller上面開發網路控制軟體， 然後透過OpenFlow[1]協定設定OpenFlow交換機， 來達成SDN的需求。OpenFlow是Controller與網路設備溝通的一種協定，OpenFlow的協定讓網路設備可以根據網路封包第二層到第四層的資訊進行封包內容的修改及轉送， 比起一般的交換機和路由器只看第二層和第三層的封包轉送來的更有彈性，大大提升網路的可操控性。透過OpenFlow協定，Controller可以對網路設備下達許多規則， 網路設備會按照這些規則對封包進行對應的動作， 因此就能做到由中控的Controller控制整個網路的目標。

　　雖然OpenFlow的設備對封包的處理具備更大的彈性， 但是目前現有的網路設備還是以Ethernet設備為大宗，如果為了要使用SDN而將所有設備更換成OpenFlow的設備會使成本變得過於高昂。其實現存的Ethernet設備在封包的傳遞能力上已經有非常良好的效能，只要好好利用OpenFlow 設備的高度彈性與Ethernet設備快速的封包傳遞能力，就可以在現有的環境中享受SDN所帶來的好處。

　　在這篇論文中，我們提出一種混合式網路架構Ethernet-in-Core OpenFlow-at-Edge(ECOE)網路模型，在核心網路的部分使用傳統的Ethernet 交換器， 在網路的邊緣使用OpenFlow的設備， 就可以提供在軟體定義網路中絕大部份重要的功能。

2. 相關研究

2.1 Ethernet SDN

　　工研院雲端中心在OpenFlow開始被熱烈討論前， 就已經著手研究Ethernet 的SDN：Peregrine[2,3,4]，使用Ethernet的環境開發了網路虛擬化(Network Virtualization)、動態流量規劃(Dynamic Traffic Engineering)以及快速容錯修復機制(Fast Failover) ， 所以證明在Ethernet的環境中也是可以做到SDN的功能，而OpenFlow只是達成SDN的一種方法，但是並不是唯一的方法，不過不可否認的是OpenFlow的確大大提升網路控制中心對於網路設備的控制能力，因此如何結OpenFlow的彈性以及現存的Ethernet是個重要的研究議題。

2.2 SDN Controller

　　當OpenFlow推出的時候，開始有許多OpenFlow 的controller陸續出現，如NOX[5] 、Floodlight[6]… 等，不過這controller主要還是以控制OpenFlow的設備為主，但是在2013年的四月，Cisco主導推出的OpenDaylight controller[7]，標榜controller 除了透過OpenFlow 協定控制OpenFlow交換機之外，應該也可以透過其他協定控制底層的網路設備，此想法與工研院雲端中心的研究不謀而合，因此2013年八月工研院雲端中心就在OpenDaylight 提出了SNMP4SDN[8]這個計畫，透過SNMP以及CLI的指令控制Ethernet設備，讓Ethernet設備也能加入SDN控制的一環。 　　圖1是OpenDaylight 的架構圖，controller的網路服務程式會透過SAL控制層控制底層的網路設備，SAL層依據底下的設備是OpenFlow設備或是Ethernet設備而使用不同的協定去設定網路設備，如此一來就可以讓OpenFlow 設備和Ethernet 設備同時被controller管理，一起提供SDN的功能。

圖 2 ECOE架構圖

3. ECOE網路架構

3.1 ECOE架構

　　ECOE的架構如圖2所示，在網路的邊緣使用具備OpenFlow能力的設備，例如：OpenFlow的路由器、OpenFlow的無線基地台或者是一般的x86主機裡面安裝Open vSwitch (軟體的虛擬交換器，支援OpenFlow協定)，而核心網路的部分使用一般的Ethernet交換機。controller會控制核心網路的Ethernet交換器以及邊緣網路的OpenFlow設備提供SDN的功能。

3.2 ECOE技術特點及理論基礎

　　在ECOE的環境中，網路的邊緣均使用具備OpenFlow能力的設備，所有封包在通過ECOE網路環境時，都會經過兩個OpenFlow的設備，一個是封包進入點的OpenFlow設備我們稱為來源端的OpenFlow設備， 另一個是封包離開點的OpenFlow設備我們稱為終點端的OpenFlow設備，封包通ECOE環境時會有三個階段，第一階段是封包送進ECOE環境時會先經過來源端的OpenFlow設備，第二階段是封包從來源端的OpenFlow設備流向核心網路的傳統Ethernet設備，封包會在數個Ethernet設備上傳遞直到另一端的OpenFlow設備，第三階段是封包從傳統Ethernet設備流向終點端的OpenFlow設備，以下會詳細介紹這三個階段的運作情形。 　　在第一階段中，封包送到ECOE的環境中，會先經過來源端的OpenFlow設備，OpenFlow設備比起傳統Ethernet的設備可以看到更多封包的標頭， 並且可以修改封包的內容，因此可以在來源端的OpenFlow設備上設定非常彈性的配對規則，然後在ECOE的設計中，會針對這個配對的規則賦予一個獨特的ID並將這個ID設定到封包的目標MAC位址中，然後將封包送入核心網路的Ethernet中。例如： 看到TCP目標埠數等於5601這種類型的封包，就將目標MAC位址設定為flow 1，然後將封包送入核心網路。 　　在第二階段中，核心網路收到來源端OpenFlow設備送過來的封包， 這個封包的目標MAC位址已經被修改成某一個flow ID，而這個ID會符合單點傳播的MAC格式，因為核心網路是傳統的Ethernet交換機，傳統Ethernet交換機會根據目標MAC位址來轉送封包，controller可以以這個flow ID為MAC位址設定Ethernet 交換機的靜態轉送表(Static Forwarding Table)，所以核心網路的Ethernet交換機可以根據靜態轉送表中這個flow ID對應的埠將封包送出， controller只要將核心網路沿途的Ethernet 交換機的靜態轉送表設定好，就能控制封包的傳送路徑，最終送達終點端的OpenFlow設備。在這過程中雖然Ethernet 交換機是根據目標MAC來轉送封包，但是因為目標MAC已經被取代成某個flow ID，而flow ID又代表著某一種OpenFlow配對規則，所以看起來就好像Ethernet交換機能根據某種OpenFlow配對規則進行封包的傳遞，讓Ethernet能直接被運用到SDN的環境中。 　　在第三階段中，終點端的OpenFlow設備收到Ethernet交換機轉送過來目標MAC位址是某個flow ID 的封包， 這時候終點端的OpenFlow設備上的規則會根據收到的封包的目標MAC位址是屬於哪個flow ID來將封包還原成原本的目標MAC內容並將封包送出。

　　整個封包的格式轉換如圖3所示，VM1要送封包給VM2，是一條TCP連線，TCP目標埠數為5601，因為封包是要送給VM2，因此目標MAC位址是VM2的MAC位址，當封包到了來源端的OpenFlow設備，這個OpenFlow設備上面會有一個配對規則，當遇到封包的TCP目標埠數為5601的封包，就將封包的目標MAC位址修改成flow 1並將封包送到核心網路中，而核心網路的Ethernet交換機會根據設定好的靜態封包轉送表將封包送到終點端的OpenFlow設備中，終點端的OpenFlow上面會有一個配對規則，如果遇到目標MAC位址是flow 1的封包，需要將目標MAC位址改成VM2的MAC位址，然後將封包往VM2所在的埠送出，之後VM2就可以收到這個封包，但是VM2並不知道封包經過ECOE環境是封包內容的轉換以及傳遞的過程。

　　雖然傳統的Ethernet交換器只能根據目標MAC位址來轉送封包，但是只要使用上述的方式，擷取OpenFlow設備能下達非常彈性的配對規則的優點，將配對過的封包的目標MAC位址代換成某個ID再送入Ethernet的環境中，就可以讓傳統的Ethernet交換器也能根據這條配對規則進行封包的傳遞，就好像具備了OpenFlow這種根據不同的配對規則進行轉送的能力。

以下將更詳細的示範ECOE如何提供OpenFlow SDN中所能提供的功能。

3.3 ECOE SDN功能

3.3.1 Unicast Flow Routing

　　圖4是傳統Ethernet交換機的封包轉送的示範圖，VM1與VM2有兩條TCP連線，分別為TCP目標埠數為5601與9002，因為傳統Ethernet交換機是根據目標MAC位址來傳送封包，所以儘管VM1送往VM2的封包TCP目標埠數不同，但是目標MAC位址都是VM2的MAC，所以Ethernet交換機只能根據VM2的MAC位址轉送封包，因此這兩種類型的封包都只能走同一條路徑，Ethernet交換機無法識別這兩類封包並將這兩類的封包分流。

　　圖5是使用OpenFlow的設備來進行封包分流傳遞的能力，因為OpenFlow的交換機可以看到封包更多的欄位，因此可以下OpenFlow規則來根據TCP目標埠5601與9002兩種不同的封包種類進行分流，圖5中，左邊的OVS(Open vSwitch一種軟體的OpenFlow設備)上面有兩條規則，第一條是，看到TCP目標埠數為5601的封包， 往交換機的埠2送出。第二條是，看到TCP目標埠數為9002的封包，往交換機的埠3 送出。而核心網路的其它OpenFlow設備也是根據TCP目標埠數來轉送封包， 最終將封包送達VM2，因為每個OpenFlow設備都能識別TCP 目標埠5601 和9002兩種封包，所以能進行不同路徑的傳遞，達到封包傳遞分流的功能。

　　圖6是使用ECOE的環境來達成封包分流傳遞的能力，在ECOE的環境中會利用網路邊緣的OpenFlow設備進行規則的配對並賦予每條規則一個唯一的識別碼也就是flow ID，在圖6中，左邊的OVS上面有兩條規則，第一條是，看到TCP目標埠數為5601的封包，修改目標MAC位址為flow1，然後往交換機的埠2送出。第二條是，看到TCP目標埠數為9002的封包，修改目標MAC位址為flow2，然後往交換機的埠3送出。之後核心網路Ethernet交換機可以根據目標MAC位址為flow1或者是flow2進行不同路徑的傳遞，達到封包傳遞分流的功能，但是在右邊的OVS，也就是終點端的OpenFlow設備還必須將此flow ID轉換回原本的目標MAC位址，所以在右邊的OVS上也有兩條規則，第一條是，看到目標MAC位址為flow1的封包， 將目標MAC位址改成VM2的MAC位址並往交換機的埠3送出。第二條是，看到目標MAC位址為flow2的封包，將目標MAC位址改成VM2的MAC位址並往交換機的埠3送出。

3.3.2動態流量負載平衡

　　動態流量負載平衡是SDN中重要的一項功能，在ECOE的架構中也能達到這項功能，圖7是兩條不同的連線，分別為TCP目標埠5601與9002，這兩條連現的封包原本都經過同一台Ethernet交換機，當這兩條連線同時進行大量的封包傳遞，會彼此競爭有限的頻寬，網路效能的瓶頸在交會的Ethernet交換機上。

　　此時controller就需要進行流量負載平衡的設定，在ECOE的環境中因為TCP目標埠5601和9002的封包，其目標MAC位址已經被代換成flow1 和flow2，因此controller 只要設定Ethernet 交換機上對於flow1 和flow2的靜態轉送表的內容，如圖8所示，就能夠將此兩條TCP連線分流，提升網路傳輸效能。

3.3.3 廣播/群播範圍控制

　　在ECOE的網路中，也能設定多種廣播/群播的群組，在圖9中VM1、VM2和VM4屬於同一個群播群組，而VM3不屬於這個群播群組，在ECOE的邊緣OpenFlow設備上，會設定關於此群播的規則，第一條規則是看到此群播網路位址226.139.1.2就將對應的VLAN(Virtual LAN)ID加入封包當中，所以此封包送到Ethernet的環境中就會帶有VLAN ID，所以Ethernet交換機只要在對應的交換機埠上設定此VLAN ID，則這個封包就會群播到對應的交換機埠，當封包群播送到每一台對應的OpenFlow設備時，會有第二條規則來處理這個封包，第二條規則是，如果收到帶有VLAN ID的封包，則移除VLAN ID並將此封包轉送到屬於該群播群組的VM所屬的埠，如此一來，屬於同一個群播群組的VM們，就能透過這個群播網路位址彼此溝通，而其他VM不會收到此群播封包。這功能是利用Ethernet本身看到群播的MAC封包就會從所有相同VLAN ID的埠群播出去的特性，只要將所有廣播/群播的封包都對應到一個所屬的VLAN ID上，再配合每個Ethernet上的VLAN設定，就可以達到自由控制廣播/群播封包範圍控制的功能，然而，整個環境只能使用到4095個VLAN ID是比較大的限制。

4. 網路功能虛擬化與服務鏈

4.1 網路功能虛擬化

　　在電信業者的機房中，需要許多不同網路功能(Network Function)的設備，將各個網路功能設備提供的服務串聯起來提供使用者一整套的服務就是網路服務鏈(Service Chain)的概念。在網路功能虛擬化(Network Function Virtualization)的議題中，希望將這些設備從硬體設備轉而運行到虛擬主機上，而以往寫在硬體設備中的服務鏈轉送規則希望可以分離出來，讓SDN來處理所有封包轉送，如此一來，提供網路服務的業者就可以專心開發虛擬網路服務，讓SDN來負責封包的傳遞以及服務鏈的配置。

4.2 網路功能服務鏈

　　圖10 是虛擬網路功能轉送表(Virtualization Network Function Forwarding Graph)，裡面每個VNF就代表一個虛擬網路功能(Virtual Network Function)，電信業者可以替每個用戶的連線決定要經過哪些網路功能來提供服務，圖8中不同顏色的折線會經過不同的虛擬網路功能，這些串起來的網路功能會形成一個服務鏈。

　　圖11是服務鏈中的封包傳送行為，如果虛擬網路功能轉送表描述了這個連線必須要經過由VNF-A,VNF-B,VNF-C,VNF-D1 四個虛擬網路功能組成的服務鏈，並且順序是封包必須先經過VNF-A，再經過VNF-B，再送到VNF-C，再送到VNF-D1， 那實際網路的傳遞就必須將封包一站一站送到每個虛擬網路功能，最終再將封包送出去給使用者，這部分就需要仰賴SDN去設定網路設備，因應上層定義的服務鏈的需求， 將特定種類的封包按照服務鏈定義的順序， 依序將封包送達每個虛擬網路服務結點，完成服務鏈的串聯後再將封包送出。其中每個虛擬網路服務結點可能同時服務好幾個服務鏈，也可能是某個服務鏈中的開頭或結尾，這部份必需要能夠很彈性的增減服務鏈，很彈性的修改任意一個虛擬網路功能在每個服務鏈中的順序。

4.3 ECOE 服務鏈

　　圖12是在ECOE的環境中，實現服務鏈的方式，我們假設這個服務鏈是鎖定要服務TCP目標埠為5601的這種封包，並且要依序經過VM1、VM2、VM4、VM3，我們可以將這個服務鏈接成三個部分，第一部分是VM1到VM2，第二部分是VM2到VM4，第三部分是VM4到VM3，我們使用ECOE第在第三章節描述的方法，在每一站的來源端OpenFlow設備上設定規則，規則內容是只要看到TCP目標埠為5601並且是從特定VM送出來的封包，就給他一個flow ID然後往下一站送，例如是從VM1送出來並且TCP 目標埠為5601 的封包就設定為flow1 ，而從VM2送出來並且TCP目標埠為5601的封包設定為flow2，VM4送出來TCP目標埠為5601的封包設定為flow3，將每個flow ID對應的靜態轉送表都設定到對應的Ethernet交換機中，就能將封包一站一站的送到對應的VM，完成整個服務鏈的串聯。

5. 結論

　　在這篇論文中，我們提出了ECOE的網路模型，只需要在網路的周圍使用OpenFlow的設備，再配合核心網路現存的Ethernet設備就能提供SDN的功能，這個網路模型的應用，可有效的幫助Ethernet轉型成軟體定義網路。目前漸漸有種趨勢認為軟體定義網路的智能盡量做到網路的周圍，而網路的核心部分應該只要高速的傳送封包就好，因此把功能強大的OpenFlow放到網路周圍，而網路的核心使用高速的Ethernet交換機，其實是非常符合這種趨勢，而且現在Mellanox[11]也推出了俱備OpenFlow功能的網路卡，未來每台主機都能使用OpenFlow的話，可以在不更換現存所有的Ethernet 設備就能提供SDN的功能，所以ECOE的架構是我覺得未來非常有可能使用的SDN網路模型。

參考文獻

1. N. McKeown, T. Anderson, H. Balakrishnan, G.Parulkar, L. Peterson, J. Rexford, S. Shenker, andJ. Turner, “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM Computer Communication Review, USA, Aug. 2008.us networks
2. C. C. Tu, P. W. Wang, T. C. Chiueh,“In-Band Control for an Ethernet-Based Software-Defined Network,” ACM SYSTOR, USA, 2014.
3. T. C. Chiueh, C. C. Tu, Y. C. Wang, P. W. Wang, K. W. Li, and Y. M. Huang,“Peregrine: An All-Layer-2 Container Computer Network,” in Proc. IEEE Int.Conf. Cloud Computing, USA, Jun. 2012.
4. C. Y. Lee, Y. W. Lee, C. C. Tu, P. W. Wang,Y. C. Wang, C. Y. Lin, and T. C. Chiueh,“Autonomic Fail-over for a Software-Defined Container Computer Network,” in Proc. Int. Conf. Autonomic Computing, USA, Jun. 2013.
5. N. Gude, T. Koponen, J. Pettit, “NOX:Towards an Operating System for Networks,” ACM SIGCOMM Computer Communication Review, USA, Jul, 2008.
6. Floodlight OpenFlow controller [Online].Available:http://www.projectfloodlight.org/floodlight/

7. OpenDaylight, OpenDaylight Controller [Online].Available: http://www.opendaylight.org/

8. ITRI, ITRI Contribution to OpenDaylight:SNMP4SDN [Online]. Available:
   https://wiki.opendaylight.org/view/Project_Proposals:SNMP4SDN

9. OpenDaylight, Technical Overview[Online]. Available:
   http://www.opendaylight.org/project/techni cal-overview

10. "Network Functions Virtualisation (NFV);Use Cases" [Online]. Available:
    http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v01010 1p.pdf

11. Mellanox Technologies [Online]. Available:http://www.mellanox.com/

李育緯

於2011年取得交通大學資訊科學與工程研究所碩士，現任工研院雲端中心系統硬體與管理組副工程師，專長為軟體定義網路、雲端網路、網路虛擬化技術。 E-mail:rayinlee@itri.org.tw