基于OpenFlow協議和Ryu控制器的生成樹協議研究與設計

楊曉，王玲

（西華大學計算機與軟件工程學院，成都610039）

0 引言

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

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

1 總體設計

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

圖1 整體框架

圖2 Ryu事件邏輯

STP模塊所實現的功能對于傳統交換模塊來說是隱藏的，傳統交換模塊只根據對應的packet-in事件進行Mac地址表的學習和數據包轉發以及流表的下發。而STP模塊會對相關原始BPDU信息的packet-in事件進行處理和封裝，并將封裝后的事件信息重新拋出到Ryu中，由Ryu再將封裝后的事件轉發到注冊該事件的傳統交換模塊中。

2 傳統交換模塊

傳統交換模塊主要是實現Mac地址學習，并根據學習到的Mac地址，轉發數據包和下發流表。交換模塊處理邏輯如圖3所示。

圖3 交換模塊處理邏輯

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

當有未知數據包進入時，OpenFlow交換機會向控制器發送packet-in消息，Ryu在就收到了這個消息后，生成對應的EventPacketIn事件，并轉發到注冊該事件的處理函數中處理。根據packet-in消息中的內容，對比Mac地址表，如果存在則下發對應的流表，避免下次packet-in，并將此數據包通過packet-out消息轉發出去；若不存在，則學習此條信息，并通過packet-out消息，泛洪到網絡中。

當檢測到網路拓撲發生變化，STP模塊會重新計算拓撲信息，并發送EventToplogyChange事件到Ryu中，由Ryu轉發到傳統交換模塊中，并調用相應的處理函數。拓撲變更函數，根據事件中的信息，將已經失效的交換機的Mac地址信息從Mac地址表中刪除，并下發指令清除相關的流表。

3 STP模塊

STP模塊分為兩部分，事件處理邏輯和兩個處理模型：Bridge模型和Port模型。事件處理邏輯用于處理事件，并調用模型進行處理。而Bridge模型和Port模型用于實現交換機控制平面功能。

3.1 事件處理邏輯

STP模塊主要是根據獲取到的交換機信息，構建STP拓撲信息，并通過OpenFlow協議控制底層物理設備行為，避免出現環路。STP模塊事件處理邏輯如圖4所示。

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

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

圖4 STP模塊處理邏輯

事件EventPacketIn，當有未知數據包或BPDU進入，觸發packet-in事件到控制器中，Ryu會將此事件路由到STP模塊中，并調用Bridge模型處理。

端口狀態事件EventOFPPortStatus，在底層設備端口狀態發生改變（端口增加，端口修改，端口修改）時觸發。對應的事件處理函數，根據改變類型做出處理；如果是增加或移除端口，則調用端口對應的Bridge模型進行處理；如果是端口修改，根據修改狀態（開啟、關閉），做出處理。

3.2 Bridge模型和Port模型

每個底層OpenFlow交換機物理設備都會在控制器層對應一個Bridge模型實例，它是底層設備邏輯控制實體，相當于底層設備的控制平面，用于處理和Bridge相關的功能（如，計算生成樹、管理端口等）；端口模型是每個交換機端口的邏輯控制實體，用于完成對端口的控制（如，端口狀態修改、BPDU發送等）

Bridge模型主要實現的功能：

●delet：刪除對應交換機中的所有端口實例

●port_add：添加指定端口

●port_delete：刪除指定端口

●link_up：開啟交換機中指定的端口

●link_down：關閉指定端口

●packet_in_handler：處理當前實例對應的Open-Flow交換機發送來的packet_in消息

●reaclculate_spanning_tree：重新計算生成樹

●toplogy_change_notifify：拓撲變更通告

Port端口模型主要實現功能：

●delet：清除端口相關的信息

●up：啟用端口

●down：端口管理性關閉

●rcv_config_bpdu：接收BPDU

●transmit_tc_bpdu：發送拓撲變更BPDU

●transmit_ack_bpdu：發送拓撲變更確認BPDU

●transmit_tcn_bpdu：發送拓撲變更BPDU

●_generate_tcn_bpdu：生成BPDU

●_generate_config_bpdu：生成配置BPDU

4 實驗驗證與分析

實驗通過Mininet構建了一個具有三個OpenFlow交換機的環形拓撲網絡，如圖5所示。通過檢驗網絡連通性、環路轉發情況，以及動態重新建立生成樹來驗證本設計。

圖5 網絡拓撲

4.1 驗證網絡連通性，以及環路避免

首先從h1主機向h2主機發送ICMP數據包檢驗網絡連通性，同時在三臺交換機端口eth2捕獲ARP數據包，以檢測ARP轉發情況。測試網絡連通性，結果如圖6所示。因為在網絡初始狀態下，MAC地址表為空，控制器會通過OpenFlow交換機泛洪尋找目標主機，并學習MAC地址；如果存在環路，則可以從ARP數據包的轉發情況獲知，轉發情況如圖7、8、9所示。

圖6

圖7 交換機s1輸出

圖8 交換機s2輸出

圖9 交換機s3輸出

從實驗結果，可以看出，網絡中雖然存在物理環路，但在保證連通性前提，并沒有環路數據包轉發情況，避免了網絡中出現廣播風暴，和MAC地址表不穩定的狀況，同時又保證網絡的高可用性。

4.2 驗證是否可以重新計算STP

生成樹協議的另一個功能就是，它不僅可以實現環路避免，同時在網絡拓撲出現變化時候可以自動重新計算，重新建立拓撲保證網絡連通性。設置交換機s2端口eth2為down，檢驗網絡是否可以重新計算生成樹，并保證網絡連通性。

從實驗結果如圖10、11，可以看出，在當某個生成樹端口關閉情況下，可以迅速重新計算生成樹并回復網絡連通性。

圖10

圖11

5 結語

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