常 坤,趙 敏,劉 磊,田 野

(中國科學(xué)技術(shù)大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院,合肥 230027)

軟件定義網(wǎng)絡(luò)[1](Software-Defined Networking,SDN)是一種新型的網(wǎng)絡(luò)架構(gòu),SDN將傳統(tǒng)網(wǎng)絡(luò)中耦合的控制平面和數(shù)據(jù)平面分離開來,網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)單元僅包含數(shù)據(jù)平面.使用集中式的控制平面來為用戶提供靈活可編程的接口,上層應(yīng)用使用這些接口對網(wǎng)絡(luò)中的匹配轉(zhuǎn)發(fā)、資源調(diào)度等進(jìn)行可編程的集中式管理.OpenFlow[2,3]是斯坦福大學(xué)提出的一種SDN的實現(xiàn)技術(shù).OpenFlow交換機(jī)使用流表(Flow Table)進(jìn)行匹配轉(zhuǎn)發(fā).然而OpenFlow不能支持新協(xié)議,雖然它的規(guī)范在不斷的更新,并通過增加字段的方式來支持更多的協(xié)議,但是這種被動式的增長會導(dǎo)致協(xié)議的臃腫和數(shù)據(jù)平面硬件的不斷重新設(shè)計.

為了解決OpenFlow存在的問題,華為提出了協(xié)議無感知轉(zhuǎn)發(fā)[4–7](Protocol Oblivious Forwarding,POF)技術(shù).在 POF 中,數(shù)據(jù)平面通過{type,offset,length}的三元組形式標(biāo)識協(xié)議字段,不需要理解具體的協(xié)議格式;同時使用統(tǒng)一的協(xié)議無關(guān)指令集進(jìn)行匹配轉(zhuǎn)發(fā),徹底做到數(shù)據(jù)平面的協(xié)議無感知.因此POF可以方便的支持任意新協(xié)議而無需修改數(shù)據(jù)平面,從而使得SDN的控制平面和數(shù)據(jù)平面徹底解耦.

數(shù)據(jù)中心網(wǎng)絡(luò)[8,9]廣泛應(yīng)用于虛擬化、云計算等領(lǐng)域.然而,隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)張和需求的增加,傳統(tǒng)的路由機(jī)制使用的基于IP地址的最長前綴匹配的方法會造成轉(zhuǎn)發(fā)單元的復(fù)雜和轉(zhuǎn)發(fā)表的爆炸[10],從而影響網(wǎng)絡(luò)的性能; 同時隨著網(wǎng)絡(luò)規(guī)模的增大,傳統(tǒng)的拓?fù)鋵W(xué)習(xí)策略導(dǎo)致大量探測包的冗余,嚴(yán)重消耗了網(wǎng)絡(luò)的帶寬資源.

目前一種基于源路由的數(shù)據(jù)中心網(wǎng)絡(luò)的實現(xiàn)是Sourcey[11].Sourcey在數(shù)據(jù)中心網(wǎng)絡(luò)中使用源路由進(jìn)行路由轉(zhuǎn)發(fā),同時提供基于主機(jī)的拓?fù)浒l(fā)現(xiàn)策略.然而Sourcey提出的拓?fù)浒l(fā)現(xiàn)策略中,所有主機(jī)都要探測全局的網(wǎng)絡(luò)拓?fù)?該策略會造成非常多的探測包冗余,嚴(yán)重影響網(wǎng)絡(luò)的性能.

針對以上問題和現(xiàn)狀,本文提出兩個協(xié)議無關(guān)的數(shù)據(jù)中心網(wǎng)絡(luò)關(guān)鍵技術(shù).首先,利用POF支持任意協(xié)議的特性,設(shè)計極其簡單的源路由機(jī)制實現(xiàn)數(shù)據(jù)中心網(wǎng)絡(luò)中的源路由,從而極大地簡化數(shù)據(jù)平面,避免匹配轉(zhuǎn)發(fā)的時間成為數(shù)據(jù)中心網(wǎng)絡(luò)中的瓶頸; 其次,設(shè)計一種主機(jī)和控制器協(xié)作的拓?fù)涔芾硭惴?能夠有效的減少探測包的冗余,減輕控制器和每個主機(jī)的負(fù)載.

本文余下的內(nèi)容安排為: 第1節(jié)介紹本文提出的源路由機(jī)制; 第2節(jié)介紹主機(jī)和控制器協(xié)作的拓?fù)涔芾聿呗? 第3節(jié)介紹實驗內(nèi)容; 第4節(jié)總結(jié)工作.

1 基于POF的數(shù)據(jù)中心網(wǎng)絡(luò)路由機(jī)制

1.1 源路由

在源路由中,主機(jī)通過在數(shù)據(jù)包頭部添加路由信息來為數(shù)據(jù)包規(guī)劃轉(zhuǎn)發(fā)路徑.網(wǎng)絡(luò)中的數(shù)據(jù)平面根據(jù)這些路由信息進(jìn)行轉(zhuǎn)發(fā).與傳統(tǒng)的路由協(xié)議相比,源路由大大簡化了數(shù)據(jù)平面的復(fù)雜度.

當(dāng)前已有的源路由策略包括傳統(tǒng)的源路由和基于OpenFlow的源路由.傳統(tǒng)的源路由策略是基于IPv4的: 主機(jī)將由IPv4地址組成的路由信息添加在數(shù)據(jù)包IPv4協(xié)議層的Options中,網(wǎng)絡(luò)中的路由器根據(jù)其中某個IPv4地址選擇下一跳進(jìn)行轉(zhuǎn)發(fā).傳統(tǒng)源路由的缺點是必須與IPv4協(xié)議綁定在一起,IPv4中的其余字段會造成額外的開銷,同時Options字段最長只有40字節(jié),因此不能用于較大規(guī)模的網(wǎng)絡(luò)中.

當(dāng)前有很多基于OpenFlow的源路由研究[12–15].其中一種常見的方法是是基于MPLS[16]的源路由: 使用多個MPLS標(biāo)簽,每個標(biāo)簽代表一跳路由,網(wǎng)絡(luò)中的數(shù)據(jù)平面根據(jù)某個MPLS標(biāo)簽進(jìn)行轉(zhuǎn)發(fā).這種方法的問題是數(shù)據(jù)平面支持的MPLS標(biāo)簽數(shù)目是有限的,一般為3～5個,因此不具有擴(kuò)展性,在大規(guī)模網(wǎng)絡(luò)中很難使用這種方法.另一種方法[17]是在 OpenFlow v1.3及其之后的版本[18,19]中,對字段進(jìn)行匹配時可以使用任意bit長度的掩碼,因此使用IPv6等字段保存每一跳的信息.然而,這種方法同樣包含很多不需要使用的字段,增加了協(xié)議長度,同時也面臨擴(kuò)展性的問題,例如若網(wǎng)絡(luò)中交換機(jī)端口數(shù)目最多為256,則128 bit的源IP字段最多只能支持16跳源路由.

1.2 基于POF的源路由機(jī)制

基于OpenFlow的源路由如此復(fù)雜的根本原因,是OpenFlow不能夠支持自定義的協(xié)議.本文提出的基于POF的源路由策略,充分利用POF協(xié)議無感知的特性,定義新協(xié)議POFSR如圖1所示,POFSR包括標(biāo)志字段Flag和一系列的SRlabel字段.Flag為0時表示POFSR 協(xié)議,否則為其它數(shù)據(jù)包.字段 SRlabel是8bit長度的字段,每個SRlabel包含一跳的路由信息,這些SRlabel組成了完整的源路由信息.

圖1 POFSR 協(xié)議格式

使用圖2和圖3來比較以上介紹的源路由方法.圖2是一個基于POF的數(shù)據(jù)中心網(wǎng)絡(luò),由主機(jī)、POF交換機(jī)和POF控制器三部分組成.若圖2中的h1要發(fā)送數(shù)據(jù)包給h4,則根據(jù)以上三種源路由協(xié)議,h1需要組建的三種數(shù)據(jù)包如圖3所示.使用傳統(tǒng)源路由時所需的數(shù)據(jù)包如圖3(a)所示,在IPv4的Options字段中包括了規(guī)劃路徑上的全部5個IP地址; 圖3(b)表示使用OpenFlow的源路由時組建的數(shù)據(jù)包,h1將所有路由端口寫在IPv6協(xié)議的源IP地址的不同bit中,轉(zhuǎn)發(fā)路徑上的每一跳路由匹配該字段中的不同bit位; 而如圖1(c)所示,在基于POF的源路由中,h3僅需組建POFSR協(xié)議,將路徑上每一跳的端口號分別放入SRlabel中,而不需要任何多余的協(xié)議或字段.路徑上的每個POF交換機(jī)只需要讀取一個SRlabel字段,根據(jù)其中的端口字段的值進(jìn)行匹配轉(zhuǎn)發(fā)即可.綜上可知,借助POF支持任意協(xié)議的特點,POFSR協(xié)議做到了最簡單的源路由.

圖2 基于 POF 的數(shù)據(jù)中心網(wǎng)絡(luò)

圖3 不同格式的源路由數(shù)據(jù)包

同時,設(shè)計SRProbe: 用于拓?fù)涔芾淼奶綔y數(shù)據(jù)包的協(xié)議格式.如圖4所示,為了區(qū)分POFSR和SRProbe,規(guī)定當(dāng)Flag字段為0時表示頭部協(xié)議為POFSR的負(fù)載數(shù)據(jù)包(簡稱負(fù)載包),否則表示頭部協(xié)議為SRProbe的探測數(shù)據(jù)包(簡稱探測包).圖4中的Hop字段代表要探測的跳數(shù),Own字段代表發(fā)出該探測包的主機(jī)的編號.最后是多個SRProbe標(biāo)簽,該標(biāo)簽包括三個字段: 表示交換機(jī)(或主機(jī))編號的dpid,代表數(shù)據(jù)包進(jìn)入端口的inp,代表發(fā)出端口的outp.在2.1小節(jié)具體描述POF交換機(jī)如何處理探測包.

圖4 SRProbe 協(xié)議格式

2 拓?fù)涔芾?/h2>

為了使用源路由,每個主機(jī)都需要掌握全局的網(wǎng)絡(luò)拓?fù)鋸亩軌蚪M建源路由的數(shù)據(jù)包.本章詳細(xì)描述主機(jī)和控制器協(xié)作的拓?fù)涔芾硭惴?包括初始時的拓?fù)浒l(fā)現(xiàn)和運行中的拓?fù)浔O(jiān)控兩部分.

2.1 拓?fù)浒l(fā)現(xiàn)

拓?fù)浒l(fā)現(xiàn)的基本思想是: 初始時每個主機(jī)各自發(fā)送探測包進(jìn)行拓?fù)浒l(fā)現(xiàn),通過POF交換機(jī)對探測包的過濾來減少冗余,通過POF控制器來整合每個主機(jī)學(xué)習(xí)到的部分拓?fù)?最后下發(fā)給所有主機(jī).在拓?fù)浒l(fā)現(xiàn)中每個角色的任務(wù)如下.

(1) 主機(jī): 主機(jī)的拓?fù)浒l(fā)現(xiàn)基于廣度優(yōu)先搜索(Breadth-First-Search,BFS)的思想: 對于每個主機(jī),首先構(gòu)造Hop=1的探測包來發(fā)現(xiàn)距自己一跳的拓?fù)?然后構(gòu)造Hop=2的探測包來發(fā)現(xiàn)距自己兩跳的拓?fù)?以此類推.每個探測包在從主機(jī)出發(fā)后,隨著Hop的遞減不斷向前探索,稱這一階段為前進(jìn)階段; 而當(dāng)探測包的Hop=0或其它條件下,探測包會沿著原路徑返回直至主機(jī),我們稱這一階段為響應(yīng)階段,這一階段的探測包稱為響應(yīng)包.

法1.HostTopo(h,Hop,LocalTopo[])Input: host h,int Hop=0,topology list LocalTopo Output: ToController Steps:1. if has received SRProbe of other host then 2. ToController(NULL);3. Hop = Hop + 1;4. pkt = construct_pkt(1,Hop,h.dpid);5. for i in h.ports do 6. send(pkt);7. while time < LIMIT_TIME_H do 8. if receive SRProbe packet pkt then 9. add_topo(LocalTopo,pkt);10. if received nothing or only boundary packet then 11. ToController(LocalTopo);12. Goto 3;

算法1是主機(jī)的拓?fù)浒l(fā)現(xiàn)算法,首先判斷是否響應(yīng)過其它主機(jī)的探測包,若是則將空拓?fù)渖辖唤o控制器并停止拓?fù)浒l(fā)現(xiàn); 否則,在第 4 行,開始第一輪的拓?fù)浒l(fā)現(xiàn).第7行設(shè)置等待時間為LIMIT_TIME_H,該時間內(nèi)主機(jī)監(jiān)聽所有端口,若收到響應(yīng)包,解析該響應(yīng)包并將其中的拓?fù)湫畔⒓尤隠ocalTopo.

主機(jī)可能收到的響應(yīng)包分為兩類: Flag=1的響應(yīng)包和Flag=2的響應(yīng)包,其中前者是由于Hop自減到0后返回的正常響應(yīng)包,而后者是由于POF交換機(jī)的過濾而導(dǎo)致在Hop為0之前就返回的響應(yīng)包,稱為邊界響應(yīng)包,稍候?qū)⒕唧w描述邊界響應(yīng)包.如第10行所示,如果在探測某一跳的拓?fù)鋾r,主機(jī)沒有收到任何響應(yīng)包,或者只收到了邊界響應(yīng)包,則停止拓?fù)浒l(fā)現(xiàn),將學(xué)到的拓?fù)湫畔⑸辖唤o控制器.

(2) POF交換機(jī): 需要處理負(fù)載包和探測包兩種數(shù)據(jù)包.如算法 2 所示,對于負(fù)載包,POF 交換機(jī)僅僅需要使用SRForward指令,該指令是自定義的POF指令,使用源路由的策略: 剝離第一個SRlabel,并根據(jù)該字段的值進(jìn)行轉(zhuǎn)發(fā); 而對于探測包,POF交換機(jī)首先判斷其是否來自于自己第一次收到的探測包所屬主機(jī).

若是,如第 7 行所示.則接下來讀取 Hop 的值: 若Hop=0,說明這是返回階段的響應(yīng)包,使用SRForward處理; 若 Hop 為 1,說明這是前進(jìn)階段的最后一跳,如第13～16行所示,POF交換機(jī)將自己的信息加入數(shù)據(jù)包并使用SRForward處理; 若Hop大于1,說明處于前進(jìn)階段,則使用SRFlood指令: POF交換機(jī)對于自己的每個端口,在數(shù)據(jù)包里添加其相應(yīng)的信息并轉(zhuǎn)發(fā)出去.

若不是,即該探測包所屬的主機(jī)不是當(dāng)前POF交換機(jī)第一次收到的探測包所屬的主機(jī).為了避免探測包的冗余,此時不應(yīng)該繼續(xù)向前轉(zhuǎn)發(fā): 如18行所示,POF交換機(jī)通過Own字段判斷是否是第一次收到該數(shù)據(jù)包所屬的主機(jī)發(fā)來的探測包,若是,則將Flag置2后使用SRForward將探測包沿著來時的端口回送,這樣處理的目的是告訴源主機(jī)本POF交換機(jī)已經(jīng)被別的主機(jī)探測過; 若不是,則直接丟棄該探測包.

算法2.ProcessPkt(sw,pkt,inport)Input: switch sw,packet pkt,ingoing port inport Output: Forward or Drop Steps:1. if pkt.Flag == 0 then 2. SRForward(pkt);3. else 4. if sw.Own == 0 then 5. sw.Own = pkt.Own;6. if pkt.Own == sw.Own then 7. if pkt.Hop == 0 then 8. SRForward(pkt);9. else if pkt.Hop == 1 then 10. pkt.Hop = 0;11. add_label(sw.dpid,inp,inp);12. double_label(pkt);

13. SRForward(pkt);14. else 15. SRFlood(sw,pkt,inp);16. else 17. if see pkt.Own for the first time then 18. pkt.Flag = 2;19. pkt.Hop = 0;20. add_label(sw.dpid,inp,inp);21. double_label(pkt);22. SRForward(pkt);23. else 24. Drop(pkt);Procedure SRForward(pkt)1. if pkt.Flag == 0 then 2. port = extract(pkt.SRlabel);3. else 4. port = extract(pkt.SRPlabel);5. forward(port);Procedure SRForward(pkt)1. for i in sw.ports do 2. if i != inport then 3. add_label(sw,dpid,inport,i);4. forward(i);

(3) POF 控制器: 如算法 3 所示,POF 控制器在LIMIT_TIME_C時間內(nèi)監(jiān)聽所有主機(jī)發(fā)來的局部拓?fù)?并將這些拓?fù)浜喜镚lobalTopo,最后將GlobalTopo下發(fā)給所有主機(jī).

?

2.2 拓?fù)浒l(fā)現(xiàn)舉例

結(jié)合圖2和圖5來詳細(xì)介紹3.1小節(jié)的拓?fù)浒l(fā)現(xiàn)算法.假設(shè)在圖2 中,h1 首先開始拓?fù)浒l(fā)現(xiàn),于是 h1 組建如圖5(a)所示的探測包并從所有端口發(fā)出,只有s1會收到該探測包,根據(jù)算法2,s1組建圖5(b)所示的響應(yīng)包并從端口1返回,h1收到該響應(yīng)包后解析,從而學(xué)習(xí)到自己的端口1和s1的端口1之間存在一條鏈路.

接著,h1組建圖5(c)所示的Hop=2的探測包來探測距自己2跳的拓?fù)?s1使用SRFlood組建圖5(d)所示的兩個探測包并從端口2和3洪泛.s2處理該探測包并返回圖5(e)所示的響應(yīng)包.在經(jīng)過s1的轉(zhuǎn)發(fā)后,h1最終收到圖5(f)所示的響應(yīng)包,并解析出s1到s2的鏈路.同時h2也收到s1轉(zhuǎn)發(fā)來的探測包,假設(shè)此時h2還沒有拓?fù)浒l(fā)現(xiàn),于是與s2類似,h2也回送響應(yīng)包,如圖5(g)所示.最終h1學(xué)習(xí)到s1和h2之間的鏈路.

圖5 不同階段的探測包和響應(yīng)包

下面描述主機(jī)和控制器的協(xié)作.假設(shè)在某一時刻,主機(jī)h1～h4的拓?fù)浒l(fā)現(xiàn)狀態(tài)為: h1學(xué)習(xí)到了距自己2 跳的拓?fù)?即 s1,s2 和 h2; h2 由于響應(yīng)了 h1 的探測包,因此不進(jìn)行拓?fù)浒l(fā)現(xiàn); h3學(xué)習(xí)了距自己1跳的拓?fù)?即s3,而h4學(xué)習(xí)了距自己2跳的拓?fù)?即s5和s4.根據(jù)算法1和算法2,所有主機(jī)在進(jìn)行下一步的探測時,都只能收到邊界響應(yīng)包,這是因為所有的POF交換機(jī)都被探測過了,對于其它主機(jī)的探測包,所有交換機(jī)都只會響應(yīng)邊界響應(yīng)包.圖6表示經(jīng)過下一跳的探測后,每個主機(jī)探測到的局部拓?fù)?因此所有主機(jī)都會結(jié)束拓?fù)浒l(fā)現(xiàn),并將拓?fù)渖辖唤oPOF控制器.根據(jù)算法3,POF控制器將所有局部拓?fù)浜喜槿值木W(wǎng)絡(luò)拓?fù)洳⑾掳l(fā)給所有的主機(jī).

圖6 每個主機(jī)學(xué)習(xí)的局部拓?fù)?/p>

環(huán)路: 由于拓?fù)浒l(fā)現(xiàn)基于BFS并且逐跳的學(xué)習(xí),數(shù)據(jù)包在環(huán)路間循環(huán)到Hop為0時會原路返回,因此并不會引起廣播風(fēng)暴.另外,通過為每個探測包分配一個編號即可避免探測包的重復(fù),交換機(jī)在收到編號相同的探測包且Hop不為0時就丟棄該數(shù)據(jù)包.

2.3 拓?fù)浔O(jiān)控

拓?fù)浔O(jiān)控的目的是維護(hù)最新的全局拓?fù)?主要包括發(fā)現(xiàn)新鏈路和結(jié)點、探測失效的鏈路和結(jié)點.與看重效率的拓?fù)浒l(fā)現(xiàn)相比,拓?fù)浔O(jiān)控需要的是時效性.

在拓?fù)浒l(fā)現(xiàn)中的協(xié)作方法仍然適用于拓?fù)浔O(jiān)控:由于每個主機(jī)在初始的拓?fù)浒l(fā)現(xiàn)時都學(xué)習(xí)了局部拓?fù)?因此在拓?fù)浔O(jiān)控時,每個主機(jī)只負(fù)責(zé)自己的局部拓?fù)涞谋O(jiān)控,通過控制器的協(xié)作來獲取全局的拓?fù)渥兓?

每個主機(jī)間歇性的重復(fù)拓?fù)浒l(fā)現(xiàn)的步驟,如果學(xué)習(xí)到的拓?fù)渑c上一次不一樣,則將變化的部分上交給POF控制器,控制器將這些變化下發(fā)給所有主機(jī),這樣所有主機(jī)就學(xué)習(xí)到了拓?fù)涞淖兓?例如圖7是圖2所示的拓?fù)浒l(fā)生了變化,其中s4和s5之間的鏈路失效了,并多出了結(jié)點s6和其與s1的鏈路.則s1在拓?fù)浔O(jiān)控中進(jìn)行2跳的探測時就會探測到s6結(jié)點和s1到s6的鏈路,而原先負(fù)責(zé)探測s4的主機(jī)h4在進(jìn)行拓?fù)浔O(jiān)控時就會探測到s4與s5鏈路的消失.

由于每個主機(jī)只需要負(fù)責(zé)部分拓?fù)涞谋O(jiān)控,因此宏觀上,相當(dāng)于所有主機(jī)同時進(jìn)行全局網(wǎng)絡(luò)拓?fù)涞谋O(jiān)控,因此時延較低,具有很好的時效性.

圖7 發(fā)生變化后的拓?fù)?/p>

3 實驗

使用Mininet[20]設(shè)計并部署基于POF和源路由的數(shù)據(jù)中心網(wǎng)絡(luò).使用POF控制器[21]和基于華為的軟件版本POF交換機(jī)部署該數(shù)據(jù)中心網(wǎng)絡(luò)中的控制器和交換機(jī).實驗的主要目的是驗證: (1)本文設(shè)計的源路由機(jī)制可以有效減少轉(zhuǎn)發(fā)平面中流表項的數(shù)目; (2)拓?fù)浒l(fā)現(xiàn)算法可以有效減少探測包的冗余.

3.1 流表大小

本文提出的基于POF的源路由機(jī)制使用極簡的源路由協(xié)議POFSR,轉(zhuǎn)發(fā)平面只需要使用簡單的源路由對數(shù)據(jù)包進(jìn)行處理,因此能夠簡化處理邏輯,減小轉(zhuǎn)發(fā)平面中流表的大小.

本實驗中,我們搭建k=4(pods)的Fat-Tree[22]網(wǎng)絡(luò)拓?fù)洳⒃谄渲袑崿F(xiàn)了POFSR協(xié)議.為該拓?fù)渲械闹鳈C(jī)編寫腳本使它們能夠為數(shù)據(jù)包添加POFSR頭部.為了驗證目標(biāo),使用每個主機(jī)與其它的所有主機(jī)進(jìn)行通信,統(tǒng)計該場景下Fat-Tree的不同層次中每個交換機(jī)流表項的數(shù)目,并且與使用OpenFlow v1.0實現(xiàn)的成對單播(pairwise unicast)路由產(chǎn)生的流表項數(shù)目進(jìn)行比較.

表1列出了對于Fat-Tree的不同層次,基于POF的源路由機(jī)制和成對單播的流表項數(shù)目.從表格中可以看出,對于Fat-Tree的三層,基于POF的源路由機(jī)制都能極大地節(jié)省流表項的數(shù)目.這是因為其只需要匹配SRlabel字段,而成對單播需要匹配源地址、目的地址等多個協(xié)議字段.轉(zhuǎn)發(fā)單元中處理邏輯的簡化和流表項數(shù)目的減少可以有效的減少處理時間,從而避免處理時間成為大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)的瓶頸.

表1 流表項數(shù)目對比

3.2 探測包冗余

為了驗證本文提出的拓?fù)浒l(fā)現(xiàn)策略可以有效減少探測包的冗余.我們使用Mininet搭建不同規(guī)模的網(wǎng)絡(luò)拓?fù)?在這些拓?fù)渲袑崿F(xiàn)3.1小節(jié)的拓?fù)浒l(fā)現(xiàn)策略.使用POFOX作為POF控制器并且編寫程序來實現(xiàn)主機(jī)與控制器的消息交互.計算不同規(guī)模的網(wǎng)絡(luò)中的探測包數(shù)目,并與同等條件下的Sourcey[9]進(jìn)行比較.

定義探測包的數(shù)目為: 前進(jìn)階段的探測包和返回階段的響應(yīng)包的總和.其中前者是由主機(jī)和POF交換機(jī)(使用SRFlood)產(chǎn)生的,而后者是根據(jù)算法2產(chǎn)生的.本實驗中,將主機(jī)的數(shù)量m設(shè)為16,網(wǎng)絡(luò)的維度d設(shè)為8.圖8和圖9顯示了探測包的數(shù)目隨交換機(jī)的個數(shù)和最大端口數(shù)變化的趨勢圖.從圖中可以看出,不論是隨著交換機(jī)數(shù)目的增加,還是隨著最大端口個數(shù)的增加,本文提出的拓?fù)浒l(fā)現(xiàn)方法產(chǎn)生的探測包都遠(yuǎn)遠(yuǎn)少于同等條件下Sourcey產(chǎn)生的探測包.由此證明本文提出的拓?fù)浒l(fā)現(xiàn)策略可以極大地減少探測包的冗余,節(jié)約網(wǎng)絡(luò)的帶寬資源.

圖8 探測包隨交換機(jī)個數(shù)變化對比圖

圖9 探測包隨最大端口數(shù)變化對比圖

4 結(jié)論與展望

本文通過對數(shù)據(jù)中心網(wǎng)絡(luò)的現(xiàn)狀進(jìn)行分析,結(jié)合協(xié)議無感知轉(zhuǎn)發(fā)技術(shù)和源路由,提出了兩個數(shù)據(jù)中心網(wǎng)絡(luò)的關(guān)鍵技術(shù): 首先,設(shè)計極其簡單的源路由機(jī)制,從而簡化數(shù)據(jù)平面,有效減少流表的規(guī)模; 其次,提出一種協(xié)作的拓?fù)涔芾硭惴?通過主機(jī)和控制器的協(xié)作和交換機(jī)的過濾來較少探測包的冗余,提高拓?fù)浒l(fā)現(xiàn)的效率.最后,我們在Mininet中搭建數(shù)據(jù)中心網(wǎng)絡(luò)并實現(xiàn)了以上兩點技術(shù).實驗結(jié)果表明,我們提出的關(guān)鍵技術(shù)可以有效地降低轉(zhuǎn)發(fā)平面中流表的規(guī)模,極大地減少探測包的冗余.接下來的研究工作是完善拓?fù)涔芾硭惴?此外,基于協(xié)議無感知轉(zhuǎn)發(fā)的數(shù)據(jù)中心網(wǎng)絡(luò)將會是一個有價值的重要研究方向.

參考文獻(xiàn)

1Casado M,Freedman MJ,Pettit J,et al.Ethane: Taking control of the enterprise.ACM SIGCOMM Computer Communication Review,2007,37(4): 1 –12.[doi: 10.1145/1282427]

2McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow:Enabling innovation in campus networks.ACM SIGCOMM Computer Communication Review,2008,38(2): 69–74.[doi:10.1145/1355734]

3張朝昆,崔勇,唐翯祎,等.軟件定義網(wǎng)絡(luò) (SDN)研究進(jìn)展.軟 件 學(xué) 報 ,2015,26(1): 62 –81.[doi: 10.13328/j.cnki.jos.004701]

4Song HY.Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane.Proceedings of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking.Hong Kong,China.2013.127–132.

5Song HY,Gong J,Chen HF,et al.Unified POF programming for diversified SDN data plane.Eprint arXiv:1405.0060,2014.

6Yu JZ,Wang XZ,Song J,et al.Forwarding programming in protocol-oblivious instruction set.Proceedings of the 22nd International Conference on Network Protocols.Raleigh,NC,USA.2014.577–582.

7POF: Specification of Huawei’s POF controller and switch.http://www.poforwarding.org/.[2017-09-20].

8Niranjan Mysore R,Pamboris A,Farrington N,et al.Portland: A scalable fault-tolerant layer 2 data center network fabric.ACM SIGCOMM Computer Communication Review,2009,39(4): 39–50.[doi: 10.1145/1594977]

9李丹,陳貴海,任豐原,等.數(shù)據(jù)中心網(wǎng)絡(luò)的研究進(jìn)展與趨勢.計算機(jī)學(xué)報,2014,37(2): 259–274.

10Greenberg A,Hamilton J,Maltz DA,et al.The cost of a cloud: Research problems in data center networks.ACM SIGCOMM Computer Communication Review,2009,39(1):68–73.

11Jin X,Farrington N,Rexford J.Your data center switch is trying too hard.Proceedings of the Symposium on SDN Research.Santa Clara,CA,USA.2016.12.

12Alizadeh M,Edsall T,Dharmapurikar S,et al.CONGA:Distributed congestion-aware load balancing for datacenters.ACM SIGCOMM Computer Communication Review,2014,44(4): 503–514.[doi: 10.1145/2740070]

13Ramos RM,Martinello M,Rothenberg CE.SlickFlow:Resilient source routing in Data Center Networks unlocked by OpenFlow.Proceedings of the 38th Annual IEEE Conference on Local Computer Networks.Sydney,NSW,Australia.2013.606–613.

14汪正康,周鵬,肖俊超,等.基于 SDN 的數(shù)據(jù)中心網(wǎng)絡(luò)資源調(diào)度機(jī)制.計算機(jī)系統(tǒng)應(yīng)用,2015,24(8): 212–218.

15Guo CX,Lu GH,Wang HJ,et al.SecondNet: A data center network virtualization architecture with bandwidth guarantees.Proceedings of the 6th International Conference.Philadelphia,PA,USA.2010.15.

16Rosen E,Viswanathan A,Callon R.Multiprotocol label switching architecture.RFC No.3031,2001.

17Jyothi SA,Dong M,Godfrey PB.Towards a flexible data center fabric with source routing.Proceedings of the 1st ACM SIGCOMM Symposium on Software Defined Networking Research.Santa Clara,CA,USA.2015.10.

18OpenFlow switch protocol: Provides an open interface for controlling connectivity and flows within that connectivity in SDN.https://www.opennetworking.org/.[2017-09-20].

19OpenFlow.OpenFlow switch specification version 1.5.1.http://t.cn/R0btma9.[2015-03-26].

20Lantz B,Heller B,McKeown N.A network in a laptop:Rapid prototyping for software-defined networks.Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks.Monterey,CA,USA.2010.19.

21談小冬,鄒山,郭浩然,等.面向協(xié)議無感知轉(zhuǎn)發(fā)技術(shù)的SDN 試驗床.計算機(jī)系統(tǒng)應(yīng)用,2016,25(4): 237–241.

22Al-Fares M,Loukissas A,Vahdat A.A scalable,commodity data center network architecture.ACM SIGCOMM Computer Communication Review,2008,38(4): 63–74.[doi:10.1145/1402946]