精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

為了對數據中心網絡虛擬化有個初步的認識，本文將對當前比較主流的幾款商業平臺進行介紹，包括VMware公司的網絡虛擬化技術，IBM公司的Dove及開源的OpenDove平臺， NEC公司的virtual-network-platform和VTN平臺,以及Cisco公司的Nexus虛擬化平臺。

1.Vmware公司的網絡虛擬化技術

VMware在虛擬化領域的領導地位使得我們必須首先介紹一下他們的網絡虛擬化技術NSX。然而需要說明的是，網絡上有關NSX的技術資料（廣告除外）并不多，因此在很多技術細節上我們也無能為力。我們首先關注到VMware公司云計算架構工程師Steve Flanders寫的一篇技術博客[1]，其主要內容是介紹VMware公司網絡虛擬化技術的發展歷史，相信這對于大家了解技術的發展有很大的幫助。然而這篇博客的問題在于幾乎沒有技術細節，從而使得讀者對技術的理解不夠深入。為了彌補這個缺陷，本文將在Steve文章的基礎之上進行必要的擴充，盡量使得大家能夠對VMware的網絡虛擬化技術有更深刻的理解。VMware公司的網絡虛擬化技術經歷了vSwitch,VDS,vCNS,收購NVP,到最終演變為NSX。根據每種技術的不同側重點，早期的vSwtich和VDS（虛擬交換機）是構建虛擬網絡的基礎，vCNS和NVP實際上是VMware和Nicira公司各自的虛擬網絡平臺，而NSX則是在收購Nicira之后VMware推出的統一平臺并被寄予厚望。本節的后續部分將按照這種歷史順序進行介紹。

1.1.虛擬交換機

最初的虛擬化技術大多關注于主機端，從而實現對處理器、內存等物理資源的共享。隨著虛擬化技術的發展，虛擬機之間以及虛擬機與外部如何通信的問題獲得了更多的重視。為了解決這些問題，VMware首先推出了vSwitch技術。顧名思義，vSwitch就是一個虛擬交換機，其主要功能就是實現數據包的交換。換句話說，當網卡接收到數據包時，vSwitch將負責將數據包轉發給正確的虛擬機。vSwitch可以簡單的認為是一臺交換機，因此當系統規模擴大后，如何實現對數萬乃至數十萬臺vSwitch的高效管理成為一個必須解決的問題。

為此，VMware提出了vSwitch的替代方案，即VDS（vNetwork Distributed Switch）。簡單來說，如果vSwitch是一個交換機，那么我們可以將VDS看作是一整套網絡解決方案，包括交換機和管理系統。如圖 1所示，VDS包括數據平面和管理平面。數據平面負責數據的轉發和相關操作，而控制平面則負責制定數據平面的規則，這一點與SDN的思想是一致的。特別的是，VDS通過增加一個抽象層可以將整個網絡抽象為一個聚合資源來處理。例如，我們可以將一個租戶的虛擬機連接到一個虛擬分布式交換機上。從而，對該租戶的所有網絡配置都可以通過對這一臺分布式交換機的配置來完成。假如一個租戶有500臺虛擬機，并且不幸的是這500臺虛擬機分布在500臺物理機上。那么，如果采用vSwitch方案，管理員需要分別配置500臺虛擬交換機。然而使用VDS方案，這500臺虛擬機交換機可以被一臺虛擬的分布式交換機所取代，此時管理員只需要配置一臺交換機就可以了，這對降低管理復雜度起到了非常重要的作用。另外，VDS為了方便管理員監控和調試網絡，提供了對NetFlow和SNMP等傳統手段的支持，這大大平滑了網絡管理員的學習曲線。然而VDS也存在一些局限性，即VDS主要集中于底層的配置，例如VLAN，虛擬端口以及端口的流量策略等等。對于上層的網絡應用，例如流量均衡和防火墻，則沒有太多的支持。為了解決這個問題，VMware又推出了vCNS。

圖1 VMware VDS架構圖[2]

1.2 vCNS

vCNS（vCloud Network and Security）,顧名思義其主要解決的是云環境中的網絡和安全問題，其可提供的服務包括虛擬防火墻、VPN、負載均衡和基于VXLAN的虛擬網絡擴展等等。如圖 2所示，vCNS可以實現為不同的租戶構建虛擬數據中心（VDC），并且不同的VDC可以采用完全定制化的網絡和安全策略。簡單來說，vCNS是由一個個虛擬裝置（appliance）構成，例如虛擬防火墻、虛擬DNS服務器等等。為了實現VDC的定制化管理，管理員可以通過配置，實現網絡負載流經不同的虛擬裝置。在vCNS中存在兩種基本的虛擬裝置，邊緣網關裝置（Edge Gateway）和應用防火墻（App Firewall）。其中，邊緣網關裝置為進入和離開VDC的數據流建立一個網關，并且提供防火墻、IPsec VPN、NAT、靜態路由、DHCP和DNS等服務；應用防火墻則直接為某個負載（workload），例如虛擬機，提供保護。vCNS提供兩種虛擬裝置類型，大大提高了系統配置的靈活性。例如，當只需要對某個負載進行保護時，應用防火墻可以快速的為這個負載建立起保護。此時，管理員并不需要關心數據來自哪里。當需要對某個虛擬域進行管理時，則可以使用虛擬邊緣網管設備，從而對進出該域的數據進行管理，而對域內的數據流動不做任何限制。另外，vCNS還支持通過REST API接口來集成第三方的服務，因此具有較好的靈活性。如果大家對NFV的服務鏈比較了解就可以發現，vCNS實際上已經具備了構建NFV服務鏈的能力。

圖2 VMware vCNS架構圖[3]

1.3.NVP

上面的這些技術都是針對于VMware自身平臺。實際上，最近幾年OpenStack項目非常活躍。VMware顯然對于這個巨大的市場也很感興趣，因此斥資12億美元收購了由Martin Casado、Nick McKeown和Scott Shenker聯合創辦的Nicira公司，而該公司的主要產品即是NVP（Network Virtualization Platform）。NVP的主要目的是實現“租戶的工作負載無需經過修改就可以遷到多租戶數據中心”的愿景。首先，NVP使用隧道技術，在服務器的hypervisor間建隧道，這樣做有兩個目的：一方面是為了加速虛擬機的遷移，包括實現從原企業網向云端的無縫遷移和數據中心內部不同子網之間自由遷移；另一方面，使用隧道技術亦有助于減少網絡設備需維護的網絡狀態（如與虛擬機MAC、IP相關的信息）。其中，隧道的創建和管理由中央控制器集群——NVP控制集群（NVP Controller Cluster）負責。其次，NVP采用軟件實現的虛擬交換機將虛擬機接入網絡。NVP平臺最終實現的效果是在物理網絡上構建虛擬網絡，且虛擬網絡對物理網絡透明，物理網絡中設備所見到的不過是物理服務器之間普通的網絡流量而已。

如圖 3所示，NVP的架構包括兩大部分：NVP控制集群和傳輸節點（Transport Nodes）。NVP控制器邏輯上可分為：OpenFlow控制器（OpenFlow Controller）和配置管理器（Configuration Manager）。

圖3 NVP架構[6]

其中，OpenFlow控制器通過OpenFlow協議實現對虛擬交換機內數據轉發的管理。由于NVP平臺采用Open vSwitch作為虛擬交換機，因此與OpenFlow控制器進行通信的實際上是ovs-vswitchd（OVS守護進程），NVP與Open vSwitch間的交互如圖4所示。配置管理器則通過OVSDB管理協議（Open vSwitch Database Management Protocol）來實現對數據庫ovsdb的管理。Ovsdb主要用于存儲虛擬網絡的配置信息，例如虛擬機與hypervisor的對應關系和隧道等相關信息。傳輸節點包括三種類型：網關節點（Gateway Nodes）、服務節點（Service Nodes）和虛擬交換機。其中，網關節點指數據中心內虛擬網絡與外界通信的連接點，可位于數據中心或遠程的企業網中。服務節點是可選的，其主要用于為虛擬網絡提供多播和廣播服務。首先由需要進行多播和廣播的主機將數據包發給服務節點，然后由服務節點進行復制并發給對應的目的主機。虛擬交換機（位于Hypervisor內）為虛擬機提供網絡接入，并構成網絡邊緣層（Network Edge）。目前，NVP只控制網絡邊緣，而核心的物理網絡則由專用的物理交換機構成。

圖4 NVP與Open vSwitch交互圖

NVP采用STT技術（Stateless Transport Tunneling Protocol，無狀態傳輸隧道協議）來構建隧道。一般來說，選擇隧道技術時，我們希望它的開銷盡可能小。由于STT技術支持一些網卡加速技術（NIC offload），如CKO（Checksum Offloading）和TSO（TCP segmentation offloading），故而基于STT構建隧道一般具有較好的性能。基于NVP技術，建立虛擬網絡包括以下三個步驟：

1）hypervisor和網關節點通過OVSDB管理協議為NVP控制集群提供虛擬網卡的位置信息，并當虛擬機發生遷移時更新這一信息。

2）服務提供商通過NVP API配置系統。NVP提供了面向OpenStack的北向接口，可由Openstack提供對網絡的配置要求。當有新租戶加入系統或已有租戶的配置發生改變，或者系統底層的物理配置發生變化，均會觸發步驟3）

3）控制器為OVS計算流表和數據庫表項（比如數據庫中和隧道相關的表項）。然后將計算所得的轉發狀態（即流表項和數據庫表項）通過OpenFlow協議和OVSDB管理協議送到傳輸節點上。

為了簡化上述過程，NVP提出一種新的計算模型，nlog。Nlog是一種聲明式語言，因此用戶只需告訴NVP要做什么（給出聲明），而如何實現則完全由nlog自動完成。Nlog直觀看來就是輸入到輸出的一個映射。輸入為配置目標和位置信息，經過nlog計算后得到輸出，即流表項和數據庫表項。Nlog的聲明實質是數據記錄查詢，每個查詢就是對一些數據表的連接（join）操作，最終得到head表。Head表是nlog定義的一種特殊的表，它能將表項導出到nlog的運行時引擎中進行計算。nlog采用增量計算方式，即當參與連接操作的表發生變化時，會對受影響的部分所在的表重新做連接操作。

1.4.NSX

NSX的核心思想是將網絡服務化。如圖 5所示，如果把虛擬機看作是一個計算服務的容器，NSX創建的虛擬網絡則是一個網絡服務的容器。這些以軟件形式存在的服務則可以是邏輯交換機、邏輯路由器和邏輯防火墻等等。為了構建一個虛擬網絡，云管理平臺（CMP）首先通過NSX控制提供的RESTful接口發出服務請求；接受到請求之后，NSX控制器將抽象的網絡服務分解到相應的虛擬交換機上，并且這些服務（虛擬交換機）與負載（虛擬機）進行邏輯連接。為了與負載進行連接，虛擬網絡與傳統的物理網絡工作原理是相同的，唯一的不同在于虛擬網絡中的網絡服務實際上是一個分布式軟件模塊的邏輯實例。這些實例可以直接運行在hypervisor中，從而可以降低實施服務的開銷。

圖5 NSX網絡虛擬化示意圖[4]

NSX可以認為是VMware收購Nicira之后將vCNS和NVP進行整合之后的產物，因此NSX具有vCNS和NVP的大部分功能。對于這些重復的內容，我們在這里就不再贅述了。相比較前面的產品而言，NSX一個顯著的特點在于它的兼容性。NSX提供了一個可擴展的平臺,基于這個平臺可以運行任何應用、任何hypervisor、任何的網絡基礎設施以及任何的網絡管理平臺。對于用戶來說，抽象出來的虛擬網絡與物理網絡沒有什么不同，因此應用不需要為使用虛擬網絡做任何修改。另外，NSX已經實現了對Xen、KVM和VMware ESXi等hypervisor，以及CloudStack、OpenStack和VMware vCloud Automation Center的完美支持。因此，NSX是一個開放的平臺，并不會導致用戶被鎖定在VMware自身的平臺上，而這一點一般是客戶選購產品時非常關注的。

3.NEC公司的網絡虛擬化技術

NEC公司有兩套虛擬網絡平臺，一個是基于開源控制器Trema[8]的 virtual-network-platform，另一個基于ODL的VTN。兩者在實現網絡虛擬化的技術也不同，virtual-network-platform采用了目前較熱門的VXLAN協議，而VTN則沒有采用分裝技術。我們并沒有找到關于兩個平臺的官方解釋，因此不清楚其商業意圖。在此，我們將只對其技術進行討論。

3.1.NEC virtual-network-platform

為租戶提供云服務，必須要保證用戶的信息安全和服務質量。NEC從這兩方面著手構建了一個中央管理平臺，名為virtual-network-platform。該平臺可以實現對網絡邊緣進行控制，并通過使用VXLAN封裝技術，實現租戶間的安全隔離。另一方面，與IBM的Open Dove不同，NEC在網絡核心同樣部署Open vSwitch交換機，在其Trema控制器中提供了名為“Sliceable_switch”的應用，通過對網絡中心的Open vSwitch進行控制，從而實現性能隔離。

圖8 NEC virtual-network-platform架構示意圖[9]

如圖 8所示，NEC網絡虛擬化平臺包括虛擬網絡控制器(virtual network controller)、虛擬網絡代理（virtual network agent）、虛擬交換機（OpenFlow Switch）和VXLAN TEP構成。下面，我們逐一對這些部件進行介紹：

虛擬網絡控制器運行在開源的OpenFlow控制Trema之上，其可以進一步分解為配置前端（Configuration Frontend）、后端數據庫（Backend Database）和虛擬網絡管理器（Virtual Network Manager）。其中，配置前端實際上是一個web服務器，對外提供REST接口，并與OpenStack相兼容。通過這個接口，用戶可以創建和刪除虛擬網絡，并將交換機的端口（提供虛擬機所在虛擬交換機的ID和虛擬機tap設備MAC地址）加入虛擬網絡或從虛擬網絡刪除。基于MySQL的后端數據庫可以用來存儲虛擬網絡的配置信息和OpenFlow交換機及虛擬網絡管理器的操作狀態。虛擬網絡管理器實際上是負責管理虛擬網絡的應用。它從后端數據庫中獲取配置信息，遠程配置OpenFlow交換機和VXLAN TEP。

虛擬網絡代理、虛擬交換機和VXLAN TEP運行在虛擬機的宿主機中。虛擬網絡代理用來接收并處理來自虛擬網絡管理器發送來的配置和管理消息，例如配置VXLAN隧道和OpenFlow虛擬交換機。虛擬交換機實現虛擬機之間以及虛擬機和外界的數據交換，而VXLAN TEP則實現VXLAN數據包的封裝和解封裝。

3.2.NEC VTN

NEC VTN（全稱Virtual Tenant Network）是NEC為Opendaylight提供的開源網絡虛擬化解決方案，集成在Opendaylight的Hydrogen虛擬化版本中，也集成在Opendaylight的Helium版本中。VTN基于NEC 的ProgrammableFlow GA產品。其與Open Dove均為Opendaylight網絡虛擬化解決方案。與Open Dove采用overlay方式實現網絡虛擬化不同，VTN采用hop-by-hop的方式，完全通過OpenFlow協議實現網絡虛擬化。

VTN由兩部分組成：VTN Coordinator和VTN Manager。前者獨立于Opendaylight存在，對Opendaylight來說是一個外部應用，后者為Opendaylight的組件（在Hydrogen版本中通過“-virt vtn”選項在啟動odl 控制器時啟動；在Helium版本中，只需在安裝時安裝VTN Manager及相關feature，之后啟動控制器即可啟動VTN）。VTN Coordinator有兩個關鍵的作用：1）提供VTN的REST API接口，與VTN Manager交互實現用戶配置, 2）協調多個odl控制器，使得可以跨越控制器實現一個大虛擬網絡（VTN）。VTN Manager為實現網絡虛擬化的部件。

VTN將底層的物理網絡抽象出一系列的虛擬節點（vNode），例如如vBridge、vRouter、vTunnel等等。VTN中最基礎的虛擬節點即vBridge，它并不是一個真實的bridge ，而是一個2層域。如圖9所示，這里的vBridge實際是從Host1到Host3間的三個交換機構成的一個2層物理網絡。在VTN中，用戶首先定義一個VTN，即一個虛擬網絡（如VTN1），然后將物理網絡通過端口或VLAN映射的方式映射到一個虛擬網絡中。與Host1連接的交換機端口被映射到vBridge的一個虛擬接口（vInterface），與Host3連接的端口被映射到vBridge的另一個接口。即Host1與Host3看起來是直接連接在同一個交換機設備上（此處的vBridge）。經此，一個復雜的網絡就被抽象成一些vBridge等基本元件連接的簡單網絡。為上層應用和操作者提供簡單的網絡接口而掩蓋底層物理網絡的復雜性。

圖9 NEC VTN抽象的vBridge[10]

如圖 10所示，VTN實現網絡隔離的原理解釋如下：MAC1（指mac地址為MAC1的虛擬機）向MAC2發送數據包，數據包到達Switch-A后發送packet_in給odl控制器，控制器收到此packet_in后通知VTN Manager，VTN Manager通過這一packet_in消息判斷發送此數據包的端口是被映射到哪個vBridge中的。VTN Manager為每個vBridge都單獨分配一張MAC-PORT表，并在收到數據包后只在對應的vBridge中查找轉發信息，從而與別的vBridge（虛擬網絡）相隔離。VTN從此vBridge的MAC-PORT表中查到目的MAC地址位于哪個交換機的哪個端口上，然后將查找結果，即（源交換機，源交換機端口，目的交換機，目的交換機端口），送于控制器，由控制器算得相應的路由路徑。可見VTN Manager是靠在OpenFlow控制器中為每個虛擬網絡維護各自的網絡視圖來實現網絡虛擬化的。

圖10-VTN工作原理圖[11]

4.Cisco Nexus Virtual Services Appliance

Cisco Nexus Virtual Services Appliance是Cisco的專用硬件虛擬化平臺，其是一個系列產品，有：Cisco Nexus 1010, Cisco Nexus 1010-X, Cisco Nexus 1110-S, 和 Cisco Nexus 1110-X。其上運行對應的虛擬化軟件服務產品Cisco Nexus 1000V virtual service blades，簡稱VSB。VSB包括Cisco Nexus 1000V Virtual Supervisor Module (VSM), Network Analysis Module (NAM), Virtual Security Gateway(VSG), 以及Data Center Network Management Module (DCNM)等。Cisco為了提高虛擬化平臺的性能，將軟件虛擬化產品以“可插拔”的形式運行在專用的高性能硬件平臺上，一個Cisco Nexus Virtual Services Appliance上可運行6-10個VSB（產品名稱后加-X的為可運行10個）。 在Cisco Nexus Virtual Services Appliance 的bootflash庫中，有VSB的ISO或OVA文件，通過它們來創建VSB。

思科的虛擬化平臺中使用的虛擬交換機為 Cisco Nexus 1000V，它包含VEM（virtual Ethernet module）和VSM兩部分，其中VEM運行在ESXi服務器上取代VMware原有的虛擬交換機，VSM是單獨運行在一臺虛擬機上（此處作為一個VSB運行在Cisco Nexus Virtual Services Appliance上）。VSM提供了命令行接口，用于管理和配置整個虛擬交換機，1個VSM對應多個VEM，即所謂分布式虛擬交換機。思科數據通路與其硬件管理平臺間的聯系是通過虛擬服務數據通路（Virtual Service Datapath，簡稱vPath）實現的。vPath是Cisco Nexus 1000V交換機的VEM模塊實現的一個功能，它的作用是可以在交換機將數據包下發到虛擬機前將數據包重定向到提供虛擬服務的節點。

服務平面（Service Plane）：為交換機到虛擬服務節點間通過GRE、VXLAN-GPE等隧道技術建立隧道形成的服務平面。虛擬服務節電可以如防火墻、負載均衡等服務。這些服務節點可硬件可軟件，可以是運行在Cisco硬件虛擬化平臺上，也可以是運行在虛擬機上。Cisco為不同租戶定義不同策略，而策略實質上即是一條服務鏈。服務鏈包含兩層意思：1）此租戶的數據包要經過哪些虛擬服務2）該租戶的數據包以怎樣的順序經過這些虛擬服務節點。為了實現正確的路由，故在VXLAN的封裝頭之后原始包之前加入了另一個頭，稱為網絡服務頭（Network Service Header，簡稱NSH）。NSH頭包括兩部分內容：1）服務路徑相關信息（服務節點要利用它來選擇服務路徑上的下一個服務節點），2）為途徑的網絡設備和服務設備提供所需的元數據。NSH服務頭是由具有服務分類功能的設備或應用添加，該設備或應用可以確定哪些數據包需要服務，需要哪些服務，相應地經過怎樣的服務路徑。并且Cisco還實現了NSH代理（NSH Proxy）。該代理作為gateway用于為數據包去掉或插入NSH 頭，從而與其他網絡服務節點相兼容。

在物理網絡中，實現網絡服務（如服務器的負載均衡，防火墻等）通常方法是在服務器間的物理通路上放置中間盒（MiddleBox，即網絡服務設備）。與Cisco vPath相比，這樣的網絡服務拓撲稱為靜態服務拓撲，它有明顯的缺點：1、拓撲改變頻繁。當我們需要改變流量經過的服務或服務的順序時必須改變拓撲，因此，當服務要求改變頻繁時，拓撲也得隨之頻繁改變；2、不區分流量。在這樣的拓撲中，所有的應用無論需不需要某個服務都得嚴格的按照拓撲順序經過拓撲路徑上的所有服務。

Data Center Network Management Module (DCNM) （本質上是一種VSB，相當于其他平臺的中央控制器）為網絡虛擬化提供了中央管理。DCNM中的模塊，中央管理點（Central Point of Management ，簡稱CPOM)），負責制定policy。DCNM還提供接口與云管理平臺OpenStack 、Cisco UCS Director、VMware vCloud Director (vCD)集成。總之，Cisco采用的硬件虛擬化平臺的概念是：將實現網絡虛擬化的各個模塊及網絡服務都以VSB的形式運行在此硬件虛擬化平臺上（當然部分部件也可運行在虛擬機上），由vPath指導數據包在這些部件間流動。

5.總結

綜上所述，目前各大公司都在圍繞自身的平臺開發了相應的虛擬網絡管理平臺。這些平臺的功能類似，即通過一個集中式的控制器實現對虛擬網絡的管理和配置，例如哪些虛擬機屬于一個虛擬網絡、以及這些虛擬機與物理機的對應關系等。為了實現不同虛擬網絡之間的數據隔離以及便于虛擬機的遷移，這些虛擬平臺（除了NEC VTN）都采用了一定的封裝技術，例如VXLAN。NEC VTN沒有采用隧道技術，而是采用維護vBridge的方式來隔離不同虛擬網絡的流量。這樣做的好處在于可以在網絡上進行更細粒度的流控，但是同時也增大了網絡設備的負擔。Cisco的Nexus虛擬化網絡方案與其他方案有些不同，他提供了專用的高性能虛擬化物理平臺，并且將虛擬化服務以VSB的形式運行其上。Cisco這樣做肯定有很多原因，但是我們認為其希望維護自身的“壟斷”地位也應該是一個非常重要的原因。筆者認為，基于標準的X86平臺進行網絡功能虛擬化，應該是大勢所趨，這也是NFV的核心思想。開放的OpenStack就是一個例子，上述的虛擬化平臺都提供了相應的支持或擴展方法，即使WMware也不例外。

參考文獻

[1]Steve Flanders，The History and Future of VMware Networking，http://sflanders.net/2013/09/04/history-future-vmware-networking/

[2]Distributed Switch, http://www.vmware.com/cn/products/vsphere/

features/distributed-switch.html

[3]VMware vCloud Networking and Security Overview,

https://www.vmware.com/files/pdf/products/vcns/vmware-vcloud-networking-and-security-overview.pdf

[4]The VMware NSX Network Virtualization Platform

http://www.vmware.com/files/pdf/products/nsx/VMware-NSX-Network-Virtualization-Platform-WP.pdf

[5]DOVE: Distributed Overlay Virtual nEtwork Architecture

http://domino.research.ibm.com/library/cyberdig.nsf/papers/D7D93A33CF54F46585257A4C004947BD/$File/H-0315.pdf

[6]Network Virtualization in Multi-tenant Datacenters

https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-koponen.pdf

[7]Open Dove, https://wiki.opendaylight.org/view/Open_DOVE:Proposal

[8]Trema, http://trema.github.io/trema/

[9]Trema/Virtual-Network-Platform

https://github.com/trema/virtual-network-platform

[10]VTN,How to configure L2 Network with Single Controller

https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi:How_to_configure_L2_Network_with_Single_Controller

[11]OpenDaylight Network Virtualization and its Future Direction

https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf