基于OpenFlow協(xié)議和Ryu控制器的生成樹協(xié)議研究與設(shè)計

楊曉，王玲

（西華大學(xué)計算機(jī)與軟件工程學(xué)院，成都610039）

0 引言

近些年來，從手機(jī)電子支付，到國家推進(jìn)的無紙化辦公，無不展現(xiàn)了數(shù)字社會飛速發(fā)展。然而，數(shù)字社會的到來給現(xiàn)存網(wǎng)絡(luò)架構(gòu)帶來巨大的挑戰(zhàn)：流量爆炸式增長，對網(wǎng)絡(luò)服務(wù)質(zhì)量和延時更高的要求，以及企業(yè)對網(wǎng)絡(luò)更多的個性化定制需求。而傳統(tǒng)網(wǎng)絡(luò)已經(jīng)無法滿足現(xiàn)代社會對于網(wǎng)絡(luò)資源的需求[1]。SDN是一種新興的網(wǎng)絡(luò)架構(gòu)，致力于改變當(dāng)前的網(wǎng)絡(luò)存在的問題。通過打破垂直整合，將網(wǎng)絡(luò)的控制邏輯從底層的路由器和交換機(jī)中分離出來，促進(jìn)網(wǎng)絡(luò)控制（邏輯）中心化，引入對網(wǎng)絡(luò)可編程的能力。通過將網(wǎng)絡(luò)控制問題分離成一些易于解決的小部分，SDN使得它便于在網(wǎng)絡(luò)中易于創(chuàng)造和引入新的抽象，這樣簡化了網(wǎng)絡(luò)管理，有利于網(wǎng)絡(luò)發(fā)展[2]。

由于網(wǎng)絡(luò)中可能存在單點(diǎn)故障而導(dǎo)致網(wǎng)絡(luò)無法訪問的情況，因此在網(wǎng)絡(luò)中引入冗余鏈路，以提高網(wǎng)絡(luò)可用性。然而這卻導(dǎo)致了另外一個問題：網(wǎng)絡(luò)環(huán)路。如果網(wǎng)絡(luò)中存在環(huán)路，會導(dǎo)致廣播風(fēng)暴，從而導(dǎo)致網(wǎng)絡(luò)性能急速下降甚至癱瘓，也會導(dǎo)致Mac地址表震蕩，導(dǎo)致網(wǎng)絡(luò)中斷[2]。因此，生成樹協(xié)議應(yīng)運(yùn)而生，它是基于二層網(wǎng)絡(luò)的，目的是避免網(wǎng)絡(luò)出現(xiàn)的環(huán)路。在傳統(tǒng)網(wǎng)絡(luò)中，生成樹協(xié)議的實(shí)現(xiàn)是基于每個交換機(jī)之間信息交換，來做出決策，是一種分布式結(jié)構(gòu)。這種分布式結(jié)構(gòu)，存在多種問題，比如他們的決策時基于相鄰信息交換，存在收斂時間長，耗費(fèi)資源大等缺點(diǎn)。在軟件定義網(wǎng)絡(luò)中，控制器擁有全網(wǎng)視圖，所有控制策略都是控制器做出的，交換機(jī)只需根據(jù)控制器下發(fā)的流表信息進(jìn)行轉(zhuǎn)發(fā)，這大大提高決策效率[3]；交換機(jī)之間也不存在控制信息的交互，只存在轉(zhuǎn)發(fā)的數(shù)據(jù)包，有關(guān)控制器信息通過OpenFlow通道與控制器進(jìn)行交互，這提高了網(wǎng)絡(luò)利用率[4]。本文通過利用OpenFlow協(xié)議和開源控制器平臺Ryu，研究設(shè)計如何在SDN環(huán)境中實(shí)現(xiàn)生成樹協(xié)議。

1 總體設(shè)計

本系統(tǒng)將分為傳統(tǒng)交換機(jī)模塊和STP模塊，這兩個模塊之間彼此獨(dú)立，僅通過Ryu事件機(jī)制來實(shí)現(xiàn)彼此之間的通信，整體框架如圖1。由于在Ryu框架中，每個OpenFlow消息都對應(yīng)一個Ryu事件，每個應(yīng)用可以通過注冊對應(yīng)的事件到控制器，當(dāng)有相應(yīng)的事件出現(xiàn)，Ryu會調(diào)用注冊該事件的函數(shù)進(jìn)行處理[5]。每個Ryu應(yīng)用也可向Ryu發(fā)送事件，以便于和其他模塊應(yīng)用通信，這些事件是由Ryu進(jìn)行轉(zhuǎn)發(fā)和路由，Ryu事件邏輯如圖2所示。

圖1 整體框架

圖2 Ryu事件邏輯

STP模塊所實(shí)現(xiàn)的功能對于傳統(tǒng)交換模塊來說是隱藏的，傳統(tǒng)交換模塊只根據(jù)對應(yīng)的packet-in事件進(jìn)行Mac地址表的學(xué)習(xí)和數(shù)據(jù)包轉(zhuǎn)發(fā)以及流表的下發(fā)。而STP模塊會對相關(guān)原始BPDU信息的packet-in事件進(jìn)行處理和封裝，并將封裝后的事件信息重新拋出到Ryu中，由Ryu再將封裝后的事件轉(zhuǎn)發(fā)到注冊該事件的傳統(tǒng)交換模塊中。

2 傳統(tǒng)交換模塊

傳統(tǒng)交換模塊主要是實(shí)現(xiàn)Mac地址學(xué)習(xí)，并根據(jù)學(xué)習(xí)到的Mac地址，轉(zhuǎn)發(fā)數(shù)據(jù)包和下發(fā)流表。交換模塊處理邏輯如圖3所示。

圖3 交換模塊處理邏輯

在這個模塊中，注冊了兩種事件類型到Ryu中：EventPacketIn和EventToplogyChange；這兩個事件是由STP模塊處理和封裝后的，隱藏關(guān)于STP的細(xì)節(jié)，以減小模塊之間耦合性。

當(dāng)有未知數(shù)據(jù)包進(jìn)入時，OpenFlow交換機(jī)會向控制器發(fā)送packet-in消息，Ryu在就收到了這個消息后，生成對應(yīng)的EventPacketIn事件，并轉(zhuǎn)發(fā)到注冊該事件的處理函數(shù)中處理。根據(jù)packet-in消息中的內(nèi)容，對比Mac地址表，如果存在則下發(fā)對應(yīng)的流表，避免下次packet-in，并將此數(shù)據(jù)包通過packet-out消息轉(zhuǎn)發(fā)出去；若不存在，則學(xué)習(xí)此條信息，并通過packet-out消息，泛洪到網(wǎng)絡(luò)中。

當(dāng)檢測到網(wǎng)路拓?fù)浒l(fā)生變化，STP模塊會重新計算拓?fù)湫畔ⅲl(fā)送EventToplogyChange事件到Ryu中，由Ryu轉(zhuǎn)發(fā)到傳統(tǒng)交換模塊中，并調(diào)用相應(yīng)的處理函數(shù)。拓?fù)渥兏瘮?shù)，根據(jù)事件中的信息，將已經(jīng)失效的交換機(jī)的Mac地址信息從Mac地址表中刪除，并下發(fā)指令清除相關(guān)的流表。

3 STP模塊

STP模塊分為兩部分，事件處理邏輯和兩個處理模型：Bridge模型和Port模型。事件處理邏輯用于處理事件，并調(diào)用模型進(jìn)行處理。而Bridge模型和Port模型用于實(shí)現(xiàn)交換機(jī)控制平面功能。

3.1 事件處理邏輯

STP模塊主要是根據(jù)獲取到的交換機(jī)信息，構(gòu)建STP拓?fù)湫畔ⅲ⑼ㄟ^OpenFlow協(xié)議控制底層物理設(shè)備行為，避免出現(xiàn)環(huán)路。STP模塊事件處理邏輯如圖4所示。

在這個模塊中，注冊了三種事件類型到Ryu中：EventOFPStateChange、EventOFPPacketIn 和 EventOFPPortStatus。

狀態(tài)改變事件EventOFPStateChange，在底層設(shè)備狀態(tài)發(fā)生改變（與控制器連接中斷，或有新的設(shè)備加入）時觸發(fā)。對應(yīng)的事件處理函數(shù)，根據(jù)改變的類型做出處理；如果是新加入的Switch，則執(zhí)行對此這設(shè)備的注冊；如果是Switch與控制器斷開，則將對應(yīng)注冊的交換機(jī)從注冊列表中移除。

圖4 STP模塊處理邏輯

事件EventPacketIn，當(dāng)有未知數(shù)據(jù)包或BPDU進(jìn)入，觸發(fā)packet-in事件到控制器中，Ryu會將此事件路由到STP模塊中，并調(diào)用Bridge模型處理。

端口狀態(tài)事件EventOFPPortStatus，在底層設(shè)備端口狀態(tài)發(fā)生改變（端口增加，端口修改，端口修改）時觸發(fā)。對應(yīng)的事件處理函數(shù)，根據(jù)改變類型做出處理；如果是增加或移除端口，則調(diào)用端口對應(yīng)的Bridge模型進(jìn)行處理；如果是端口修改，根據(jù)修改狀態(tài)（開啟、關(guān)閉），做出處理。

3.2 Bridge模型和Port模型

每個底層OpenFlow交換機(jī)物理設(shè)備都會在控制器層對應(yīng)一個Bridge模型實(shí)例，它是底層設(shè)備邏輯控制實(shí)體，相當(dāng)于底層設(shè)備的控制平面，用于處理和Bridge相關(guān)的功能（如，計算生成樹、管理端口等）；端口模型是每個交換機(jī)端口的邏輯控制實(shí)體，用于完成對端口的控制（如，端口狀態(tài)修改、BPDU發(fā)送等）

Bridge模型主要實(shí)現(xiàn)的功能：

●delet：刪除對應(yīng)交換機(jī)中的所有端口實(shí)例

●port_add：添加指定端口

●port_delete：刪除指定端口

●link_up：開啟交換機(jī)中指定的端口

●link_down：關(guān)閉指定端口

●packet_in_handler：處理當(dāng)前實(shí)例對應(yīng)的Open-Flow交換機(jī)發(fā)送來的packet_in消息

●reaclculate_spanning_tree：重新計算生成樹

●toplogy_change_notifify：拓?fù)渥兏ǜ?/p>

Port端口模型主要實(shí)現(xiàn)功能：

●delet：清除端口相關(guān)的信息

●up：啟用端口

●down：端口管理性關(guān)閉

●rcv_config_bpdu：接收BPDU

●transmit_tc_bpdu：發(fā)送拓?fù)渥兏麭PDU

●transmit_ack_bpdu：發(fā)送拓?fù)渥兏_認(rèn)BPDU

●transmit_tcn_bpdu：發(fā)送拓?fù)渥兏麭PDU

●_generate_tcn_bpdu：生成BPDU

●_generate_config_bpdu：生成配置BPDU

4 實(shí)驗(yàn)驗(yàn)證與分析

實(shí)驗(yàn)通過Mininet構(gòu)建了一個具有三個OpenFlow交換機(jī)的環(huán)形拓?fù)渚W(wǎng)絡(luò)，如圖5所示。通過檢驗(yàn)網(wǎng)絡(luò)連通性、環(huán)路轉(zhuǎn)發(fā)情況，以及動態(tài)重新建立生成樹來驗(yàn)證本設(shè)計。

圖5 網(wǎng)絡(luò)拓?fù)?/p>

4.1 驗(yàn)證網(wǎng)絡(luò)連通性，以及環(huán)路避免

首先從h1主機(jī)向h2主機(jī)發(fā)送ICMP數(shù)據(jù)包檢驗(yàn)網(wǎng)絡(luò)連通性，同時在三臺交換機(jī)端口eth2捕獲ARP數(shù)據(jù)包，以檢測ARP轉(zhuǎn)發(fā)情況。測試網(wǎng)絡(luò)連通性，結(jié)果如圖6所示。因?yàn)樵诰W(wǎng)絡(luò)初始狀態(tài)下，MAC地址表為空，控制器會通過OpenFlow交換機(jī)泛洪尋找目標(biāo)主機(jī)，并學(xué)習(xí)MAC地址；如果存在環(huán)路，則可以從ARP數(shù)據(jù)包的轉(zhuǎn)發(fā)情況獲知，轉(zhuǎn)發(fā)情況如圖7、8、9所示。

圖6

圖7 交換機(jī)s1輸出

圖8 交換機(jī)s2輸出

圖9 交換機(jī)s3輸出

從實(shí)驗(yàn)結(jié)果，可以看出，網(wǎng)絡(luò)中雖然存在物理環(huán)路，但在保證連通性前提，并沒有環(huán)路數(shù)據(jù)包轉(zhuǎn)發(fā)情況，避免了網(wǎng)絡(luò)中出現(xiàn)廣播風(fēng)暴，和MAC地址表不穩(wěn)定的狀況，同時又保證網(wǎng)絡(luò)的高可用性。

4.2 驗(yàn)證是否可以重新計算STP

生成樹協(xié)議的另一個功能就是，它不僅可以實(shí)現(xiàn)環(huán)路避免，同時在網(wǎng)絡(luò)拓?fù)涑霈F(xiàn)變化時候可以自動重新計算，重新建立拓?fù)浔ＷC網(wǎng)絡(luò)連通性。設(shè)置交換機(jī)s2端口eth2為down，檢驗(yàn)網(wǎng)絡(luò)是否可以重新計算生成樹，并保證網(wǎng)絡(luò)連通性。

從實(shí)驗(yàn)結(jié)果如圖10、11，可以看出，在當(dāng)某個生成樹端口關(guān)閉情況下，可以迅速重新計算生成樹并回復(fù)網(wǎng)絡(luò)連通性。

圖10

圖11

5 結(jié)語

本文依據(jù)OpenFlow協(xié)議，和Ryu框架，探索設(shè)計實(shí)現(xiàn)如將傳統(tǒng)網(wǎng)絡(luò)中生成樹協(xié)議在軟件定義網(wǎng)絡(luò)環(huán)境中實(shí)現(xiàn)。從本設(shè)計可以見識到軟件定義網(wǎng)絡(luò)的優(yōu)勢：中心控制帶來更高部署的效率和高效的管理；全局網(wǎng)絡(luò)視圖更便于策略制定；轉(zhuǎn)移交換機(jī)控制平面是交換機(jī)僅僅御用數(shù)據(jù)包轉(zhuǎn)發(fā)，帶來更高的轉(zhuǎn)發(fā)帶寬；控制器對底層設(shè)備抽象給網(wǎng)絡(luò)開發(fā)帶來更多可能。本設(shè)計在一定程度上和真實(shí)環(huán)境要求存在差距（如沒有考慮多VLAN情況），需要進(jìn)一步的完善。今后的研究可以嘗試設(shè)計更加符合真實(shí)網(wǎng)絡(luò)環(huán)境的方案。