中文摘要

　　近年來，虛擬化技術(Virtualization)帶來諸多好處的同時，亦帶來了許多新的挑戰。當網路越複雜，設定也越繁瑣，尤其是隨著雲端運算(Cloud Computing)等新應用的普及，這類應用必定需要一個龐大的網路環境來支撐其大量的封包傳遞，而這種網路設定已超越傳統人工設定所能負擔的範圍。基於此，軟體定義網路(Software-Defined Networking)的概念被提出。近幾個月來，工研院雲端中心針對傳統的乙太網路(Ethernet)，開發一套基於VLAN 之軟體定義網路解決方案：Peregrine，其主要提供三項核心技術，分別為網路虛擬化(Network Virtualization)、動態路徑規劃(Dynamic Traffic Engineering)及快速故障移轉(Fast Failover)。與其它軟體定義網路技術相比，Peregrine 無需使用實體的OpenFlow交換機(Switch)， 僅需使用目前主流的Ethernet 交換機即可佈建一個軟體定義網路的環境。如此，可幫助Peregrine 的使用者大幅降低汰換網路設備的硬體成本。此外，Peregrine 亦整合OpenStack Icehouse，故可支援Neutron APIs。測試結果顯示，Peregrine 具有良好的效能。

Abstract

　　Recently, virtualization technologies have introduced new challenges. A complicated network is always associated with a set of complicated configurations on network devices, thus increasing manipulation workload significantly.To this end, a new concept of the Software-Defined Networking (SDN) has been proposed. In recent months, ITRI CCMA has been working on a VLAN-Based SDN Solution called Peregrine.It mainly offers three core technologies:NetworkVirtualization,Dynamic Traffic Engineering,and Fast Failover.Compared to other existing SDN solutions,physical OpenFlow switches are not necessary for Peregrine. Instead, Peregrine builds a SDN network environment through common Ethernet switches. Based on this,users interested in Peregrine are able to save a lot of expenses on purchasing new hardware devices, such as physical OpenFlow switches. In addition, ITRI CCMA has integrated Peregrine with OpenStack Icehouse.Therefore, Peregrine also supports Neutron APIs.Experimental results revealed that Peregrine has good performance.

關鍵詞(Key Words)

軟體定義網路 (Software-Defined Networking；SDN)
網路虛擬化(Network Virtualization)
動態路徑規劃(Dynamic Traffic Engineering)
快速故障移轉(Fast Failover)

1. 前言

　　近年來，隨著虛擬化技術的成熟，在現代化資料中心裡， 已開始大量的採用虛擬化技術，用以動態的根據使用者需求，自動化部署、移除或移動虛擬裝置，降低繁雜的處理程序，並提高能源使用效率。

　　然而，在虛擬化技術帶來諸多好處的同時，亦帶來了許多新的挑戰。在傳統的網路中，網路管理人員可規劃多個 Virtual Local Area Network (VLAN)， 來隔離不同群組之間的封包，也可在交換機(Switch)上設定存取控制機制(Access Control List)，來達到過濾封包的目的。以往， 這些設定都是經由網路管理人員，連線到每一台交換機上進行設定。然而，當網路環境越複雜，設定也將越繁瑣。尤其是隨著雲端運算及物聯網(Internet of Things)等新應用的普及，這類應用必定需要一個龐大且複雜的網路環境來支撐其大量的封包傳遞，而這種網路設定已超越傳統人工設定所能負擔的範圍。因此， 在此趨勢下，由軟體自動化地去進行相關的網路裝置設定與修改，已經是明顯且迫切的需求，也進而衍生出軟體定義網路(Software-Defined Networking；SDN)的概念[1]。

　　近幾個月來，工研院雲端中心針對傳統的乙太網路(Ethernet)，開發一套基於VLAN 之軟體定義網路解決方案：Peregrine，其主要提供三項核心技術， 分別為網路虛擬化(Network Virtualization)、動態路徑規劃(Dynamic Traffic Engineering)及快速故障移轉快速失敗轉移(Fast Failover)。其中，網路虛擬化技術可讓多個租戶(Tenant)共用同一個實體網路(Physical Network)，且彼此不會互相干擾。每個租戶可自訂私有的網段， 並擁有獨立的廣播區域(Broadcast Domain)；動態路徑規劃技術主要負責規劃實體伺服器(Physical Server) 之間的路徑，並將流量(Traffic) 的負載平衡(Load Balancing)納入考量，期望將流量盡量分散至所有可用的交換機鏈路(Link)上；快速故障移轉技術則處理某條鏈路或某台交換機故障的情況，其任務主要在極短時間內恢復網路的連通性(Connectivity)。與其它軟體定義網路技術相比，Peregrine 系統無需使用實體的OpenFlow交換機，僅需使用目前主流的Ethernet 交換機，即可佈建一個軟體定義網路的環境。如此，可幫助Peregrine的使用者大幅降低汰換交換機的硬體成本。此外，Peregrine 亦與OpenStack Icehouse [2]整合，因此Peregrine可支援Neutron APIs。

　　本論文章節架構如下，第2章節首先回顧軟體定義網路技術於目前國內外發展的現況；接著，第3章節介紹Peregrine 軟體定義網路技術；第4章節針對Peregrine 之效能進行解說；最後，第5章節將總結與歸納本論文所提出的各種觀點。

2. 國內外發展之現況

　　在軟體定義網路的技術中，「網路虛擬化」、「動態路徑規劃」及「快速故障移轉」是三項非常重要的議題。接下來，我們將進一步介紹這三項技術於國內外發展之現況。

2.1 網路虛擬化

　　網路虛擬化在軟體定義網路中，是一個非常重要的技術，透過該技術， 多個租戶可共用同一個實體網路， 且彼此不會互相干擾。幾乎 所有的軟體定義網路解決方案(Solution)均支援此技術，例如VMware 的NSX 、IBM 的DOVE、NEC 的VTN 及Microsoft 的VL2等。此外，大部份公司採用Tunnel 技術實現網路虛擬化。目前，有三種主流的Tunnel 技術被使用，分別為Virtual eXtensible Local Area Network (VxLan) [3]、Network Virtualization using Generic Routing Encapsulation (NvGRE) [4] 及Stateless Transport Tunneling Protocol (STT) [5]。 　　VxLan 由Cisco、VMware 及其他公司共同推出，其中心思想是在終端節點(Endpoint)，對封包進行封裝(Encapsulate) 及解封裝(De-encapsulate)的動作。其將原始的封包封裝在一個UDP 封包中，如此，該封包在傳遞時，交換機檢查的是外層封包的資訊。當封包傳遞至目的終端後，將由目的終端進行解封裝，並提取出原始封包。 　　NvGRE 是由Microsoft 所推出的技術，其概念與VxLan 相同， 均是在終端節點對封包進行封裝及解封裝的動作。然而，與VxLan相比，NvGRE需要網路設備的特殊支援，例如，設備須支援利用GRE Key 進行負載平衡的Hash 計算。 　　STT是由Nicira 針對虛擬交換機所設計的技術，目的在於解決封包分割(Segmentation)的問題。以往，分割封包的動作是由網路卡(Network Interface Card) 所負責，且只能針對TCP 封包進行分割。因此，一旦使用的Tunnel技術為VxLan 或NvGRE，網路卡將無法針對封包進行分割，因為此時的封包並不是TCP封包。故分割封包的動作將交由虛擬交換機執行，導致CPU負擔過重的問題產生。STT 與上述兩個Tunnel 技術不同的地方在於，其將原始封包封裝後，新封包的Tunnel Header 格式為TCP 格式， 藉此讓網路卡以為該封包為TCP 封包，進而執行封包分割的動作，但事實上，該封包並不是真的TCP封包，並不需要進行三向交握(Three-Way Handshake) 的動作。 　　由上述的介紹可知，無論是哪一種Tunnel技術，均須在終端節點，對封包進行封裝及解封裝的動作，而這兩個動作均需由CPU 來執行。因此，在一個網路環境複雜且龐大的場景中，使用Tunnel 技術實現網路虛擬化是不適合的，原因是，CPU 必須耗費大量的時間處理封裝及解封裝的動作，導致CPU 資源無法有效利用在適當的地方，進而降低網路的產能(Throughput)。 　　工研院雲端中心曾針對資料中心，提出一集中管理ARP Table 的方法[6]， 其給予每個租戶一個獨立的ID。透過此ID，即使不同租戶使用相同的網段，彼此也不會相互干擾，進而達到網路虛擬化的目標。然而，為了集中管理ARP Table，首先必須擁有網路中所有設備的資訊，例如IP 及MAC 位址，而這在某些場景是無法達成的。 　　本論文所提出之網路虛擬化技術以VLAN 為基礎，利用VLAN 天生的特性，達到網路虛擬化的目標。與[3-5] 之Tunnel 技術相比，本論文所提出之技術，可有效提昇CPU 使用效率；與[6] 之方法比較，本技術無需掌控所有設備的資訊，故適用的場景更加廣泛。

2.2 動態路徑規劃

　　動態路徑規劃亦是軟體定義網路的一項重要技術，在傳統網路中，根據不同的生成樹協定，例如Spanning Tree Protocol (STP) [7] 或Rapid Spanning Tree Protocol (RSTP) [8]，可在網路環境中建立一棵Spanning Tree，用以防止廣播風暴(Broadcast Storm)，並讓實體或虛擬伺服器之間，透過該Spanning Tree 傳輸資料。然而，在資料中心裡，伺服器間的資料傳輸是非常頻繁的，當伺服器的數量越多，表示傳輸量越大，此時，Spanning Tree 將成為網路傳輸效能的瓶頸（Bottleneck）。 　　為了改善網路傳輸效能，Cisco 提出Multiple Spanning Tree Protocol (MSTP) [9] 技術，希望透過建立多棵Spanning Tree，讓流量分散至不同的Tree 上。其概念是將VLAN 分組，屬於同一群組的VLAN 共用同一棵Spanning Tree，因此，流量將被分散至不同的Tree 上。然而，MSTP 所支援的群組數量並不多，且共用同一棵Tree 的VLAN 依然無法負載平衡。 　　總體而言， 無論是何種生成樹協定，均以分散式的方式產生Spanning Tree。也就是說，網路管理人員無法自己挑選伺服器間的資料傳輸路徑， 而這與軟體定義網路的宗旨相互違背，因此，現存於交換機上的各種生成樹協定，並不適用於軟體定義網路的解決方案。 　　Brocade VCS Fabric 技術[10] 不採用任何生成樹協定，而是在任兩台交換機間規劃一條最短路徑(Shortest Path)。因此，每一條鏈路均可能成為路徑上的一員。然而，當網路擁塞時，其無法重新規劃路徑以達到負載平衡。此外，此技術必須搭配Brocade 自己生產的交換機才可使用。Cisco Application Centric Infrastructure (ACI) 解決方案[11] 使用其自己的路徑規劃技術，然而，其最大的問題與Brocade 一樣，必須使用Cisco 所生產的硬體設備才可發揮出好的效能。 　　無論是Brocade VCS Fabric 或CiscoACI，均高度仰賴其自家公司所生產的硬體設備。因此，若要使用其軟體定義網路解決方案，除了要付費購買技術外，亦要花費大量的金錢採購硬體設備，這對於許多有興趣於軟體定義網路的使用者來說， 是一項沉重的負擔。基於此，工研院雲端中心所開發的動態路徑規劃技術，不仰賴特殊的硬體設備，僅需使用目前主流的Ethernet交換機，即可佈建一個軟體定義網路的環境， 大幅降低使用者踏入軟體定義網路領域的門檻。此外，Peregrine 之動態路徑規劃技術，可有效的將流量分散至整個網路上，達到流量負載平衡的目標。

2.3 快速故障移轉

　　在網路環境中，網路設備故障將導致連線中斷的問題產生，而中斷時間過久是很多應用(Application)所無法忍受的。因此，當網路設備故障後，如何在短時間內恢復網路的連通性，亦是軟體定義網路中一項重要的課題。 　　失敗轉移的效能與路徑規劃技術息息相關，原因是，某條鏈路或某台交換機故障時，勢必得觸發路徑規劃技術重新規劃路徑，以恢復網路的連通性。STP 在失敗轉移方面，表現的非常不理想，其恢復網路連通性所耗費的時間高達幾十秒鐘，進而促使RSTP 的興起。然而，即便使用RSTP，在最佳情況下，也需要花費幾秒鐘的時間恢復網路連通性。Brocade VCSFabric 及Cisco ACI 均有其各自的失敗轉移技術，然而，如同先前所述，其解決方案高度仰賴特殊硬體設備的支援。 　　工研院雲端中心所開發的失敗轉移技術，無須依賴特殊硬體設備的支援，並預計在300至400 毫秒(millisecond)的時間內，即可恢復網路的連通性。在此，稍微說明我們如何預估執行失敗轉移流程所需的時間。本中心的SDN開發團隊在失敗轉移技術方面，已有非常豐富的開發經驗， 而根據先前的經驗，我們可做到在400 毫秒內完成失敗轉移的程序，這部份的成果可參考文獻[6][12][13]。

　　本章節主要介紹工研院雲端中心所開發的Peregrine 軟體定義網路解決方案。以下，首先介紹其所適用的網路環境，接著，分別針對三項核心技術進行說明。

3.1 網路環境

　　在Peregrine 所適用的網路環境中，需存在多台實體伺服器與Ethernet交換機。每一台實體伺服器上，須安裝開放原始碼的虛擬OpenFlow 交換機(Open vSwitch)。如此，如圖1 所示，所有的Ethernet 交換機將被虛擬OpenFlow 交換機包圍，且所有由伺服器所發出的封包，必定將先經過虛擬OpenFlow 交換機，接著才會流進由實體Ethernet 交換機所構成的網路。也就是說，Peregrine 可透過設定虛擬OpenFlow 交換機上的Flow Rule，及實體Ethernet 交換機上的Forwarding Table 與VLAN 配置，控制封包的流向。

　　Peregrine 運行在OpenDaylight Controller上[14]。透過該Controller， Peregrine 可經由OpenFlow 協定設定Flow Rule 至虛擬OpenFlow 交換機上。為了控制Ethernet 交換機，工研院雲端中心亦參與OpenDaylight Controller 的開發，並貢獻一名為SNMP4SDN免費訂閱 第161期電腦與通訊25的南向Plugin [15]至OpenDaylight Controller中，其目的在於希望讓Controller上的應用，可透過標準的SNMP 協定，控制Ethernet 交換機。在目前OpenDaylight 所公佈的兩個Controller版本中，SNMP4SDN 均被納入，並成為其中的一環，這兩個版本分別是Hydrogen及Helium [16] 。接下來，本論文將針對Peregrine 所提供之三項核心技術進行介紹。

3.2 網路虛擬化

　　如同先前所述，Peregrine支援OpenStack Neutron，根據Neutron的定義，每個租戶可建立多個網路(Network)，且每個網路被視為一個廣播區域。基於此定義，Peregrine之網路虛擬化技術的中心思想為，替每個租戶建立的網路分配一個VLAN ID，透過VLAN 天生的特性，即可達到網路虛擬化的目標。舉例來說，考慮一租戶A為一間大型企業，其可替旗下的會計、法務或資訊等部門分別建立一個網路，而Peregrine將替每個部門各自分配一個VLAN ID，並在交換機上進行VLAN 的相關配置，如此，每個部門電腦所發出的封包將各自攜帶其專屬的VLAN ID。故即使所有部門均共用同一個實體網路，其所發送之訊息依然可透過交換機上VLAN 的配置，將訊息進行隔離，讓每個部門的使用者均有「該實體網路只有自己部門在使用」的假象。 　　租戶亦可替每個網路，設定各自的防火牆(Firewall)、閘道器(Gateway)及DHCP 伺服器等網路相關配置。此外，亦可啟動NAT 服務，如此，即使每個網路所使用的網段相同，也不會造成衝突。舉例而言，兩台分別位於會計及資訊部門的電腦，即使使用相同的IP位址，並在同一時間存取同一個外部網站(例如Google)，也可以正常的運作。總體而言，Peregrine的網路虛擬化技術是利用VLAN 天生的特性，故可有效達到網路虛擬化的目標。與Tunnel 技術相比，本技術可讓CPU資源不浪費在處理封包之封裝及解封裝的動作，進而提昇CPU 使用效率及網路的產能。

3.3動態路徑規劃

　　本中心所開發之動態路徑規劃技術，為了將流量的負載平衡納入考量，因此，不採用任何的生成樹協定。其基本概念是為每一個VLAN 計算一棵Tree，用以防止廣播風暴，且為了將流量分散至整個網路環境中，所有的VLAN Tree將盡量不使用相同的交換機鏈路，故當網路環境中存在足夠多的鏈路時，任一條鏈路最多只會成為一棵VLAN Tree的邊(Edge)。 　　如圖2所示，考慮一網路環境存在A 至G七台實體Ethernet交換機，與VM1 至VM10共10台虛擬伺服器。其中，VM1、VM4、VM7及VM8 屬於藍色的VLAN，而剩餘之虛擬伺服器則屬於綠色的VLAN。Peregrine 所開發的動態路徑規劃技術，會為兩個VLAN 各自計算一棵Tree，且若網路環境中存在足夠多的交換機鏈路，則兩棵樹將不會使用相同的鏈路，如此，可分散兩個VLAN 的流量，進而提昇頻寬利用率及網路效能。

　　總體來說，工研院雲端中心所開發的動態路徑規劃技術，利用Tree 天生不會有迴圈(Loop)的特性，防止廣播風暴的發生。同時，亦將流量的負載平衡納入考量，提昇頻寬利用率及網路效能。此外，Brocade VCS Fabric或Cisco ACI 相比，本技術不仰賴特殊的硬體設備，僅需使用目前主流的Ethernet交換機即可運作。

3.4 快速故障移轉

　　在管理網路方面，Peregrine 以In-band 控制的方式管理網路，也就是說Peregrine 透過Controller 所下達的指令，將透過Control Plane 網路送至網路裝置；伺服器間的資料交換，則是透過Data Plane 網路(即由動態路徑規劃技術所產生的Tree)進行傳輸。因此，當某條鏈路或某台交換機故障時，Peregrine 所開發之快速故障移轉技術，將優先修復Control Plane 網路，之後才修復那些受影響的VLAN Tree。其基本概念是替Control 及Data Plane網路，事先計算備援方案，當網路設備故障時，Peregrine 即可根據相對應的方案，進行網路修復的動作。以下，本論文以Data Plane 網路為例，進行說明。 　　首先，Peregrine 替每一個動態路徑規劃技術所產生的VLAN Tree，事先計算所有可能的備援方案(Backup Solution)。此方案的目的在於，當網路因某條鏈路或某台交換機故障，導致一棵Tree 分裂成兩棵以上的Tree 時，其可將所有的Tree 重新修復成一棵VLANTree，以恢復該VLAN 的網路連通性。

　　如圖3(a)所示，考慮一網路環境存在A至G七台實體Ethernet交換機，及S1 至S3 三台實體伺服器，且共有vm1至vm5五台虛擬伺服器，分別位於三台實體伺服器上。假設所有的虛擬伺服器，均屬於同一租戶所建立的網路，如圖3(a)中藍色的Tree 所示，動態路徑規劃技術將替此網路計算一棵VLAN Tree。之後，快速故障移轉技術將針對這棵VLAN Tree，事先分別計算其每一條鏈路及每一台實體交換機故障後的備援方案。如圖3(b)所示，假設鏈路A-C 失效，則交換機A 與C 將會發送Link Down Trap 至Controller，之後，Peregrine 之快速故障移轉技術，將根據事先計算好的備援方案，進行該VLAN Tree 的修復程序。在此例中，當鏈路A-C 故障後之相對應備援方案為「讓鏈路A-B 加入該VLANTree」，如此，即可恢復該VLAN 的網路連通性。

　　如同章節2.3所述，根據以往的經驗，工研院雲端中心在快速故障移轉技術方面，設定的目標是，當某條鏈路或交換機故障時，預計在300至400 毫秒的時間內，恢復網路的連通性，而這是非常有機會可以達成的。原因是，需要耗費大量時間運算的工作，在於事先計算所有的備援方案，因此，當故障發生時，Peregrine只需更改交換機上的相關配置即可，例如VLAN 配置。此外，依照以往經驗，最不可掌控的時間在於，當故障發生後，Controller 收到Link Down Trap所等待的時間，而這屬於硬體設備的問題。本中心的SDN開發團隊曾做過相關實驗，使用等級越高的交換機，Controller收到Trap的時間也越快，故隨著科技的進步，未來此問題勢必也將得到改善。

4. Peregrine 效能測試

　　本章節主要說明，工研院雲端中心所開發之Peregrine 軟體定義網路技術的效能測試結果。由於Peregrine 尚在開發階段， 因此，目前僅針對動態路徑規劃技術，進行簡單的效能量測。未來，當Peregrine 完成所有的開發與功能測試後， 本中心的SDN 開發團隊將會進行更加深入且完善的效能分析。

　　圖4為Peregrine 效能量測的環境，其為一小型的真實網路環境。在此環境中，共存在4台實體Ethernet交換機，及6台實體伺服器。在環境中，所有的交換機鏈路頻寬均為1G。我們挑選1台伺服器作為Peregrine 之SDNController，並在其它5 台伺服器上安裝OpenStack Icehouse 雲端作業系統(1 台OpenStack Control Node及4台Compute Node)。我們透過OpenStack 分別在4台Compute Node上各建立兩個虛擬伺服器，其中一台作為Sender 的角色，負責透過iperf 工具產生流量；另一台作為Receiver 角色，負責經由iperf接收來自Sender 的流量。此外， 我們亦透過OpenStack 建立4 個網路， 並分配VLAN100、101、102 及103 這4 個VLAN ID 給4個網路。如圖4所示，在測試過程中，相同顏色Sender 及Receiver 屬於同一個網路，該Sender 將發送流量至與其顏色相同Receiver。

　　為了量測Peregrine之動態路徑規劃技術的效能，我們首先讓所有的流量，透過相同的Tree進行傳輸，用以模擬使用STP [7] 或RSTP [8]的網路環境。之後，啟動Peregrine動態路徑規劃技術，重新規劃伺服器之間的路徑，藉此觀察本技術的效能。圖5顯示4個Receiver隨著時間的推移，所量測出的網路產能。其中，在前26秒使用相同的Tree進行傳輸時，4個Receiver所測出的網路產能大致落在250　Mbits/sec至550Mbits/sec 的範圍內，原因是所有的流量均擠在同一棵Tree上，導致該Tree 成為網路傳輸效能的瓶頸。之後，我們於第26秒啟動Peregrine動態路徑規劃技術。此時，可明顯的發現4個Receiver所測出的網路產能均開始提昇，最後達到900 Mbits/sec 左右，與前26秒相比，效能提昇約1倍。其中，在第26至27秒時，4個Receiver所測出之產能往下降的原因在於，Peregrine正將其計算後的結果，佈署至網路設備上，故會造成封包丟失的情況，導致該段時間網路產能下降。

　　本章節透過簡單的實際測試，證明Peregrine 之動態路徑規劃技術，確實在流量的負載平衡上，具有良好的效能。未來，當Peregrine 完成所有的開發與功能測試後，本中心的SDN 開發團隊將會進行更加深入且完善的效能分析。

5. 結論

　　本論文所介紹的Peregrine，為工研院雲端中心針對傳統乙太網路，所開發的一套軟體定義網路解決方案，其主要提供三項核心技術，分別為網路虛擬化、動態路徑規劃及快速故障移轉。其中，在網路虛擬化部份，本技術可有效提昇CPU使用效率，且無需掌控所有設備的資訊，故適用的場景更加廣泛。在動態路徑規劃部份，本技術不仰賴特殊硬體設備，可動態調整資料傳輸路徑， 並將流量負載平衡納入考量。最後，在快速故障移轉部份，相較於傳統技術以秒為單位的修復速度，本技術可於300毫秒左右的時間內，恢復網路的連通性。此外，與其它軟體定義網路技術相比，Peregrine系統無需使用實體的OpenFlow交換機，僅需使用目前主流的Ethernet交換機，即可佈建一個軟體定義網路的環境。如此，可幫助Peregrine 的使用者大幅降低汰換交換機的硬體成本。Peregrine 亦與OpenStack Icehouse整合，故其可支援Neutron APIs。

　在效能測試方面， 本中心的SDN 開發團隊採取實機實測的方式， 真實的佈建一個以Peregrine 為核心之軟體定義網路環境，用以測試Peregrine 之動態路徑規劃技術。測試結果顯示，Peregrine 動態路徑規劃技術，確實在流量的負載平衡上， 具有良好的效能。未來，當Peregrine 完成所有的開發與功能測試後，我們將會進行更加深入且完善的效能分析。

參考文獻

1. N. McKeown, T. Anderson, H. Balakrishnan, G.Parulkar, L. Peterson, J. Rexford, S. Shenker, and J.Turner, “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM ComputerCommunication Review, USA, Aug. 2008.
2. OpenStack, OpenStack Icehouse [Online].Available:http://www.openstack.org/software/icehouse/
3. M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L.Kreeger, T. Sridhar, M. Bursell, and C. Wright,“VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks,” Feb. 2012, Internet Draft draft-mahalingam-dutt-dcops-vxlan-01.
4. M. Sridharan, A. Greenberg, N. Venkataramiah, Y.Wang, K. Duda, I. Ganga, G. Lin, M. Pearson, P.Thaler, and C. Tumuluri, “NVGRE: Network Virtualization using Generic RoutingEncapsulation,” Jul. 2012, Internet Draft draft-sridharan-virtualization-nvgre-01.
5. B. Davie and J. Gross, “A Stateless Transport Tunneling Protocol for Network Virtualization (STT),” Mar. 2012, Internet Draft draft-daviestt-01.

6. C. C. Tu, P. W. Wang, and T. C. Chiueh, “In-Band Control for an Ethernet-Based Software-Defined Network,” in Proc. Int. Conf. Systems and Storage,Israel, Jun. 2014.

7. Spanning Tree Protocol, IEEE Standard 802.1D,1998.

8. Rapid Spanning Tree Protocol, IEEE Standard 802.1D, 2004.

9. Multiple Spanning Tree Protocol, IEEE Standard 802.1Q, 2005.

10. Brocade, Brocade VCS Fabric Technology[Online]. Available:http://www.brocade.com/solutions-technology/tech
    nology/vcs-technology/details.page

11. Cisco, Cisco Application Centric Infrastructure[Online]. Available:http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html

12. 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.

13. 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.

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

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

16. OpenDaylight, Hydrogen and Helium Releases[Online]. Available:http://www.opendaylight.org/software/release-archives

林志宇

於2012年取得淡江大學資訊工程博士學位，現任工研院雲端中心系統硬體與管理組工程師。專長為雲端運算、軟體定義網路及無線感測網路技術。目前從事軟體定義網路技術開發。 E-mail: rainlin@itri.org.tw