基于OpenFlow南向協(xié)議的SDN控制器性能測試方法及定量分析

張 攀 楊 虹

引言

隨著軟件定義網(wǎng)絡(luò)(Software Defined Network,SDN)成為網(wǎng)絡(luò)世界的新的范式轉(zhuǎn)移，控制平面和轉(zhuǎn)發(fā)平面的分離讓后者得到了極大的簡化，繁重的處理和計算工作都遷移至控制平面。作為控制平面的核心組件，控制器在全局網(wǎng)絡(luò)性能中扮演決定性角色。鑒于SDN網(wǎng)絡(luò)的實驗或商業(yè)部署已經(jīng)展開，網(wǎng)絡(luò)用戶將控制器的性能當(dāng)作一個越來越重要的衡量標(biāo)準(zhǔn)。

作為目前業(yè)界關(guān)注的焦點，SDN控制器的性能關(guān)系到SDN技術(shù)是否可以兌現(xiàn)新技術(shù)帶來的承諾。為滿足網(wǎng)絡(luò)用戶需求，本文介紹SDN控制器性能的詳細(xì)測試方法，以及以某一款開源控制器為例的定量測試結(jié)果，以便給出結(jié)果的標(biāo)準(zhǔn)呈現(xiàn)形式。所有測試?yán)坚槍penFlow 1.3[1]這一SDN南向協(xié)議。

本文介紹的測試方法可以在實驗室中復(fù)現(xiàn)，可為所有關(guān)心SDN控制器性能的用戶提供標(biāo)準(zhǔn)化的測試過程及測試?yán)O(shè)計依據(jù)[2]。同時，在本文中提供了示例控制器在特定硬件平臺上的定量測試結(jié)果，詳細(xì)介紹了結(jié)果的分析過程和結(jié)論?？蔀樵u估控制器性能的用戶，提供必要及有效的參考[3]。

2 環(huán)境設(shè)計

2.1 設(shè)計目標(biāo)

本文介紹的測試方法旨在以定量的方式測量SDN控制器以下幾個方面的性能。

1)控制通道容量?？刂破鬟B接交換機的最大數(shù)目，關(guān)系到整個SDN網(wǎng)絡(luò)的可拓展性。

2)拓?fù)浒l(fā)現(xiàn)時間。該功能是SDN控制器需要實現(xiàn)的基本功能之一，本文介紹的測試方法可以測量其在不同規(guī)模、不同拓?fù)溥B接方式下完成網(wǎng)絡(luò)拓?fù)浒l(fā)現(xiàn)所需的時間。

3)拓?fù)漤憫?yīng)時間。SDN控制器針對拓?fù)渥兓录?，比如Port Down/Up等事件的偵測及響應(yīng)時間，可以衡量SDN控制器對網(wǎng)絡(luò)鏈路的控制能力。

4)被動流表下發(fā)速率。即控制器根據(jù)既定策略下發(fā)流表的速率?？梢院饬靠刂破鲗ι蠈泳W(wǎng)絡(luò)策略的執(zhí)行能力。

5)被動Packet_out消息下發(fā)速率。Packet_out消息是OpenFlow協(xié)議中主要的消息類型之一，在實際網(wǎng)絡(luò)運營中關(guān)系到LLDP、ARP等協(xié)議的應(yīng)用。其下發(fā)速率也是需要定量測量的指標(biāo)之一。

在給出測試方法之外，仍會對實際的測量結(jié)果加以分析，介紹其結(jié)果的定量分析方法。同時，本文也將嘗試對比分析控制器在單點運行模式以及集群運行模式下，同一性能指標(biāo)的變化，其變化的特點以及所揭示出的控制器的特質(zhì)，將為SDN網(wǎng)絡(luò)用戶提供參考。

2.2 被測控制器設(shè)計

為完成設(shè)計目標(biāo)，一款開源控制器被選為示例被測控制器。它是目前流行的開源控制器之一，支持多種功能，例如設(shè)備管理、拓?fù)涔芾?、鏈路管理、集群、圖形用戶界面以及多種SDN應(yīng)用。它的OpenFlow 1.3南向協(xié)議消息處理性能是我們關(guān)注的內(nèi)容。在本次搭建的測試環(huán)境里，我們設(shè)置了三臺完全相同的虛擬機，每一虛擬機上都運行著一個完全相同的控制器節(jié)點實例。

2.3 硬件環(huán)境設(shè)計

為更好地比較控制器集群運行模式的實驗結(jié)果，本次設(shè)計硬件環(huán)境為單臺物理機運行多臺虛擬機的模式，控制器運行于虛擬機中。詳細(xì)配置如下。

物理機：

虛擬機：

2.4 控制器運行模式設(shè)計

為得到控制性能更完善的信息，定義了兩種控制器運行模式。

1)單點運行模式。一個控制器節(jié)點實例運用于一個虛擬機之上。

2)集群運行模式。每一個虛擬機各運營一個控制器節(jié)點實例，三個分布式的，運營在不同虛擬機上的控制器實例組合成控制器集群，共同工作。

2.5 測試建議

1)隔離建議。所有的測試都建議執(zhí)行于實驗室環(huán)境和隔離的網(wǎng)絡(luò)之中，以防外界的干擾對測試結(jié)果造成影響。

2)連接建議。被測控制器建議與測試工具直接連接，防止中間設(shè)備引入延遲或失效，導(dǎo)致測試結(jié)果不準(zhǔn)確。

3)迭代建議。每一測試?yán)冀ㄗh迭代執(zhí)行10次以上，分別記錄最大值、最小值和平均值?？梢愿娴伢w現(xiàn)控制器的性能。

4)負(fù)載均衡驗證建議。當(dāng)控制器以集群模式運行時，建議分別記錄各節(jié)點實例的CPU、內(nèi)存使用率，以便檢測在壓力之下，控制器集群是否可以進行負(fù)載分擔(dān)。

3 性能測試?yán)敖Y(jié)果

3.1 控制通道容量測試

1)測試目的。測量控制器可以同時建立的OpenFlow 1.3通道的最大數(shù)目。

2)測試前提。

①被測控制器可以分別運行于單點模式和集群模式。

②被測控制器和模擬交換機都可以通過OpenFlow Echo request/reply消息維持控制通道的連接。

3)測試拓?fù)?。如圖1所示。

圖1 控制通道容量測試示例拓?fù)?/p>

4)測試方法。

①以單點模式啟動被測控制器。

②以不同拓?fù)溥B接的模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③逐步增加交換機的數(shù)量，直到最大數(shù)目Nm，記錄每一步的內(nèi)存占用量。

④等待5分鐘，確保已建立的控制通道穩(wěn)定。

⑤在集群模式下迭代該測試過程。

5)測試結(jié)果。

①單點模式。本次測試采用三種拓?fù)溥B接方式：即Linear拓?fù)洹ing拓?fù)浜虶rid拓?fù)?。如果建立的控制通道穩(wěn)定并且每一個模擬控制器都收到了來自被測控制器的正確配置(安裝默認(rèn)流表)，那么此時記錄的內(nèi)存使用量即視為有效數(shù)據(jù)。默認(rèn)情況下，控制器會下發(fā)兩個針對ARP和LLDP數(shù)據(jù)包的流表給交換機，如果有交換機沒收到這兩條流表，我們即認(rèn)為此時的交換機數(shù)目已超過最大數(shù)目，并將此時內(nèi)存使用情況標(biāo)記為N/A。詳細(xì)的平均內(nèi)存使用情況如圖2所示。

②集群模式。在集群模式下，三個節(jié)點的內(nèi)存使用量需要分別表示。該模式下，采用了兩種拓?fù)洌篖inear拓?fù)浜蚏ing拓?fù)?。從測試結(jié)果可以看出，即便是存在一個leader節(jié)點，三個節(jié)點的內(nèi)存使用量也大致相同，并且在每一個的總量上也稍稍高于單點模式。分析認(rèn)為這是由于每一個節(jié)點都需要建立與全部交換機的控制通道，同時加入額外的集群同步機制；因此，可建立控制通道的數(shù)量并沒有得到極大提升。詳細(xì)結(jié)果如圖3所示。

3.2 拓?fù)浒l(fā)現(xiàn)時間

1)測試目的。測量在不同網(wǎng)絡(luò)拓?fù)浜筒煌粨Q機數(shù)量下的控制器拓?fù)浒l(fā)現(xiàn)時間。

2)測試前提。

①被測控制器可以分別運行于單點模式和集群模式。被測控制器可以無差錯地支持拓?fù)浒l(fā)現(xiàn)功能。

②默認(rèn)的Table-miss流表的動作必須為上送控制器，或交換機有預(yù)先安裝的針對拓?fù)浒l(fā)現(xiàn)消息的流表。

3)測試拓?fù)?。如圖4所示。

圖2 單點模式測試結(jié)果

圖3 控制通道容量集群模式測試結(jié)果

圖4 拓?fù)浒l(fā)現(xiàn)時間測試示例拓?fù)?/p>

4)測試方法。

①以單點模式啟動被測控制器。

②模擬交換機開始建立與被測控制器的連接。

③記錄時間Tstart為控制器開啟拓?fù)浒l(fā)現(xiàn)服務(wù)的時間。

④記錄時間Tfout為控制器發(fā)出第一個包含LLDP數(shù)據(jù)包的Packet_out消息的時間。

⑤記錄時間Tfin為控制器收到第一個Packet_in消息的時間。

⑥記錄時間Tlin為最后一個由模擬交換機發(fā)出的Packet_in消息的時間。

⑦記錄時間Tend為控制器完成拓?fù)浒l(fā)現(xiàn)的時間。

⑧取得拓?fù)浒l(fā)現(xiàn)時間為T=Tend - Tstart。

⑨同時計算Tfout - Tstart(Tinit)，為控制器初始化拓?fù)浒l(fā)現(xiàn)服務(wù)時間，Tfin - Tfout (Ttool)和Tlin -Tfin(Tnode)為使用不同測試工具和不同拓?fù)?、?jié)點數(shù)目的變動時間。Tend - Tlin(Tproc)為控制器處理LLDP消息并生成拓?fù)浒l(fā)現(xiàn)結(jié)果的處理時間。

⑩在不同拓?fù)溥B接方式，不同節(jié)點數(shù)目下迭代該測試。

在集群模式下迭代該測試。

5)測試結(jié)果。

①單點模式。本次測試采用了三種不同的拓?fù)漕愋?，Linear拓?fù)?、Ring拓?fù)浜虶rid拓?fù)?。從測試結(jié)果來看，Tinit和Ttool兩個時間間隔在不同情況下基本保持恒定，這兩個時間分別為60±5ms和1ms，在下述的圖標(biāo)中并不容易被觀察到。Tnode和Tproc與節(jié)點數(shù)量成正比，同時遠(yuǎn)大于Tinit和Ttool兩個時間間隔。詳細(xì)結(jié)果見圖5所示。

圖5 拓?fù)浒l(fā)現(xiàn)時間單點模式測試結(jié)果

②集群模式。在集群模式下，采用了相同的三種拓?fù)溥B接類型。Tinit和Ttool與在單點模式下的測試結(jié)果相同。當(dāng)節(jié)點數(shù)量相對較小時，Tproc比單點模式要長，主要由于節(jié)點間同步進程的額外開銷。當(dāng)節(jié)點數(shù)量較大時(100～300)，Tproc的時間減小，由于集群增加的計算能力成為了主要的影響因素。根據(jù)測試過程中的抓包記錄，只有l(wèi)eader節(jié)點通過Packet_out消息發(fā)送LLDP數(shù)據(jù)包，但是交換機將Packet_in消息分別發(fā)送給三個節(jié)點，因此，Tnode時間在集群模式下增長。所以全局的拓?fù)浒l(fā)現(xiàn)時間在不同的測試環(huán)境下，可能增加也可能增長。同時可以發(fā)現(xiàn)拓?fù)浒l(fā)現(xiàn)時間與交換機連接的拓?fù)漕愋陀忻芮嘘P(guān)系。詳細(xì)測試結(jié)果如圖6所示。

3.3 拓?fù)涫录憫?yīng)時間測試

1)測試目的。測量被測控制器對拓?fù)渥兓录捻憫?yīng)時間。這些事件包括Port up/down和Switch up/down。在本測試?yán)胁粌H檢測控制器對這些事件的偵測時間，同時也包括整套拓?fù)涓聞幼鞯耐瓿蓵r間。

圖6 拓?fù)浒l(fā)現(xiàn)時間集群模式測試結(jié)果

2)測試前提。

①被測控制器可以分別運行于單點和集群模式。

②被測控制器可以無差錯地支持拓?fù)浒l(fā)現(xiàn)功能。

③默認(rèn)的Table-miss流表的動作必須為上送控制器，或交換機有預(yù)先安裝的針對拓?fù)浒l(fā)現(xiàn)消息的流表。

3)測試拓?fù)洹Ｈ鐖D7所示。

圖7 拓?fù)鋾r間相應(yīng)時間測試示例拓?fù)?/p>

4)測試方法。

①以單點模式啟動被測控制器。

②以不同拓?fù)溥B接的模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③等待直至拓?fù)浒l(fā)現(xiàn)完成。

④手動關(guān)閉交換機的某一端口。

⑥記錄時間T1為控制器收到通知消息的時間。

⑦記錄時間T2為控制器完成拓?fù)渲匦掳l(fā)現(xiàn)的時間。

⑧取得拓?fù)涫录憫?yīng)時間T = T2 - T1。

⑨在不同拓?fù)洹⒉煌粨Q機數(shù)量下迭代執(zhí)行該測試。

⑩在集群模式下迭代執(zhí)行該測試。

5)測試結(jié)果。

①單點模式。本次測試中采用了兩種拓?fù)溥B接模式，Ring拓?fù)浜虷ub-spoke拓?fù)洹臏y試結(jié)果看來，Port up/down事件相對于Switch up/down事件，被測服務(wù)器響應(yīng)的時間更短。對拓?fù)溆绊懜蟮腜ort down事件比Port up事件響應(yīng)的時間更長。針對Port down事件的響應(yīng)時間甚至超過了10秒，被測控制器在該方面還有很大的提升空間。圖8中，Port down/up事件的時間單位是秒，Switch up/down事件的時間單位是毫秒。

圖8 拓?fù)涫录憫?yīng)時間單點模式測試結(jié)果

②集群模式。在集群模式下，采用了三種拓?fù)溥B接模式。從測試結(jié)果來看，拓?fù)渥兓录捻憫?yīng)時間展現(xiàn)出不可控的特性。集群節(jié)點之間的同步進程、拓?fù)漕愋鸵约凹簝?nèi)部的拓?fù)浒l(fā)現(xiàn)機制(發(fā)送LLDP數(shù)據(jù)包的時間間隔)，所有這些有影響的變量都讓測試結(jié)果出現(xiàn)了隨機性。沒有人可以斷言集群模式下的控制器響應(yīng)時間更短，或拓?fù)渲泄?jié)點數(shù)量越小越容易響應(yīng)。這也是網(wǎng)絡(luò)用戶在真實部署SDN網(wǎng)絡(luò)時可能遇到的問題。詳細(xì)測試結(jié)果如圖9所示。

圖9 拓?fù)涫录憫?yīng)時間集群模式測試結(jié)果

3.4 被動流表下發(fā)速率測試

1)測試目的。測量被測控制器被動流表下發(fā)最大速率。

2)測試前提。①被測控制器可以分別運行于單點模式和集群模式。②被測控制器可以無差錯地支持拓?fù)浒l(fā)現(xiàn)功能。③默認(rèn)的Table-miss流表的動作必須為上送控制器。④一個SDN應(yīng)用需要在控制器之上運行，響應(yīng)流表下發(fā)的需求，并能以最大可能的速率下發(fā)流表。

3)測試拓?fù)洹Ｈ鐖D10所示。

圖10 被動流表下發(fā)速率測試示例拓?fù)?/p>

4)測試方法。

①以單點模式啟動被測控制器。

②模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③等待直至拓?fù)浒l(fā)現(xiàn)完成。

④被測控制器運行L2 Learning Switch應(yīng)用。

⑤一定數(shù)量M的ARP_request消息通過Packet_in消息上送控制器。

⑥當(dāng)控制器下發(fā)Packet_out消息結(jié)束之后，模擬交換機以一定速率通過Packet_in消息上送對應(yīng)的ARP_Reply消息。

⑦記錄時間Tf為模擬交換機收到的一個Flow_mod消息的時間。

⑧記錄時間Tl為模擬交換機收到的最后一個Flow_mod消息的時間。

⑨確保所有的APR_reply消息都被控制器正確回應(yīng)。

⑩求出被動流表下發(fā)速率R=M/(Tl-Tf)。

以不同的模擬交換機APR_reply上送速率迭代該測試。

在集群模式下迭代該測試。

5)測試結(jié)果。

①單點模式。在該測試中，一個模擬交換機連接被測控制器。測試工具被配置為以不同的速率上送Packet_in消息。在一些特定的配置下，被測控制器不能為每一條APR_Reply消息都下發(fā)兩條雙向連通的流表，但是實際流表下發(fā)數(shù)量還是被統(tǒng)計并作為有效數(shù)據(jù)。當(dāng)上送速率在一定范圍之內(nèi)時，被測控制器流表下發(fā)速率與上送速率呈正相關(guān)關(guān)系。當(dāng)上送速率超過某一閾值之后，流表下發(fā)速率顯著下降，可認(rèn)為此時被測控制器出現(xiàn)過載。APR消息的總數(shù)對流表下發(fā)的速率沒有影響。詳細(xì)測試結(jié)果請參照圖11。

圖11 被動流表下發(fā)速率單點模式測試結(jié)果

②集群模式。在集群模式，模擬交換機產(chǎn)生的每一個Packet_in消息都復(fù)制三份，分別發(fā)給集群中的三個節(jié)點，但只期望三個節(jié)點中的一個下發(fā)對應(yīng)的兩條雙向連通的流表。在測試結(jié)果分析階段，發(fā)現(xiàn)有兩個或兩個以上的節(jié)點同時下發(fā)了相同的流表。換言之，一部分ARP_request/reply消息，控制器集群一共下發(fā)了四條或六條，互相重復(fù)的流表。這很大程度上是由于集群節(jié)點之間的同步進程未能正確地完成同步工作引起的。根據(jù)OpenFlow 1.3.4協(xié)議，如果Flow_mod消息中設(shè)定了CHECK_OVERLAP標(biāo)志位，這還會導(dǎo)致交換機返回錯誤消息。所以針對集群模式的測試結(jié)果不能作為有效的結(jié)果。

3.5 被動Packet_out消息下發(fā)速率測試

1)測試目的。測量被測控制器最大被動Packet_out消息下發(fā)速率。

2)測試前提。①被測控制器可以分別運行于單點模式和集群模式。②被測控制器可以無差錯地支持拓?fù)浒l(fā)現(xiàn)功能。③默認(rèn)的Table-miss流表的動作必須為上送控制器。④一個SDN應(yīng)用需要在控制器之上運行，響應(yīng)發(fā)送Packet_out的請求，并能以最大可能的速率下發(fā)Packet_out消息。

3)測試拓?fù)?。如圖12所示。

圖12 被動Packet_out速率示例拓?fù)?/p>

4)測試方法。

①以單點模式啟動被測控制器。

②模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③等待直至拓?fù)浒l(fā)現(xiàn)完成。

④被測控制器運行L2 Learning Switch應(yīng)用。

⑤模擬交換機以一定速率，通過Packet_in消息上送一定數(shù)量M的ARP_request消息。

⑥記錄時間T1為模擬交換機收到第一個包含上送ARP_request的Packet_out消息的時間。

⑦記錄時間T2為模擬交換機收到的最后一個Packet_out消息的時間。

⑧確保所有的APR_request消息都被控制器以Packet_out消息下發(fā)。

⑨求出被動Packet_out消息下發(fā)速率R=M/(T2-T1)。

⑩以不同的模擬交換機APR_request上送速率迭代該測試。

在集群模式下迭代該測試。

5)測試結(jié)果。

①單點模式。在該測試中，一個模擬交換機連接被測控制器。APR_request消息總數(shù)被設(shè)定為恒定值(1K)，但會以不同的上送速率進行迭代測試。與上一個流表下發(fā)速率測試?yán)煌?，Packet_out消息下發(fā)速率并沒有隨著APR_request消息上送速率的增加而增加。在該測試?yán)慕Y(jié)果分析階段，被測控制器在下發(fā)Packet_out消息時發(fā)現(xiàn)有大量的TCP重傳，使下發(fā)速率在上送速率超過200個/秒時出現(xiàn)了顯著下降。即便如此，實際的Packet_out下發(fā)速率也被認(rèn)為是有效數(shù)據(jù)。詳細(xì)測試結(jié)果請參照圖13。

圖13 單點模式測試結(jié)果

②集群模式。在集群模式下，情況與上一測試?yán)愃?。每一個上送的ARP_request消息封裝于Packet_in消息之中，并復(fù)制三份，分別發(fā)給三個集群節(jié)點。每一個ARP_request消息都只期望有一個對應(yīng)的Packet_out消息回應(yīng)。但在該測試結(jié)果分析階段，某些ARP_request消息被發(fā)現(xiàn)由多個控制器節(jié)點分別回應(yīng)了相同的Packet_out消息。換言之，在集群模式下，Packet_out消息的總數(shù)比上送的APR_request消息多(大約為其1.5倍)，某些APR_request被重復(fù)泛洪多次。這一現(xiàn)象，同樣是由控制器集群節(jié)點間同步機制不能正確完成工作所致。因該現(xiàn)象不但沒有正確完成所需的工作，同時又浪費了現(xiàn)有的網(wǎng)絡(luò)資源，所以其測試數(shù)據(jù)不能作為有效的測試結(jié)果。這也同樣是網(wǎng)絡(luò)用戶可能在部署SDN網(wǎng)路時遇到的問題。

4 總結(jié)

本文介紹了一些SDN控制器的性能測試方法及對測試結(jié)果的定量分析[4]。意在著重介紹測試方法及結(jié)果的呈現(xiàn)形式。這些測試?yán)?，都是依?jù)網(wǎng)絡(luò)用戶的實際場景和需求制定的。一個開源SDN[5]控制器被選擇為示例被測控制器，以便提供定量的結(jié)果呈現(xiàn)方式和分析過程?？偨Y(jié)測試結(jié)果，被測控制器在單點模式下可以穩(wěn)定運行，盡管一些方面的性能仍需要加強，但其已經(jīng)可以作為一個小規(guī)模的SDN網(wǎng)絡(luò)的控制器。反觀集群模式，控制器節(jié)點間的同步機制還未成熟。這或?qū)?dǎo)致過重的管理開支甚至是控制行為錯誤，從而最終引發(fā)網(wǎng)絡(luò)失效。文中介紹的性能測試方法，任何需要獲得控制器確切性能參數(shù)的個人或組織都可以在實驗環(huán)境中復(fù)現(xiàn)。

本文介紹的性能測試?yán)徽J(rèn)為是這項工作的一個起點。對每一個測試?yán)齺碚f，都可以添加更詳細(xì)的配置，同時新的測試?yán)矊粩嗟乇唤榻B進這項工作中來。當(dāng)前，性能測試僅僅關(guān)注于南向接口，并且僅有一個特定版本的OpenFlow協(xié)議被提及。未來，北向接口的性能也將會納入測試范疇。每一項測試?yán)伎梢杂糜赟DN用戶評估網(wǎng)絡(luò)的實際部署情況，并成為其控制器選型的指標(biāo)與依據(jù)。

參考文獻

[1]Open Networking Foundation OpenFlow switch protocol 1.3.4[EB/OL].(2014-3-27)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdnresources/onf-specifications/open fl ow/open fl ow-switchv1.3.4.pdf

[2]Open Networking Foundation Conformance Test Specification For OpenFlow Switch Specification v1.3.4 Basic Single Table Conformance Test Profile[EB/OL].(2015-4-15)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/working-groups/OpenFlow1.3.4TestSpecification-Basic.pdf

[3]Team of Rivals: Aligning Technology & Market Drivers in an Open-Source Standards Testing Program[EB/OL].(2013-10-5)[2015-12-10].Rick Bauer Ron Milford Zhen Li https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/team-of-rivals.pdf

[4]The Evolution of SDN and OpenFlow:A Standards Perspective[EB/OL].(2014-1-26)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/evolution-of-sdn-and-of.pdf

[5]When Open Source Meets Network Control Planes[EB/OL].(2012-12)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdnresources/IEEE-papers/when-os-meets-nc-controlplanes.pdf