本發(fā)明涉及計算機應用技術，具體涉及一種基于OpenFlow協(xié)議的多控制器協(xié)同平臺的協(xié)同方法。

背景技術：

隨著網絡規(guī)模的不斷擴大和網絡互連設備的日益增多，傳統(tǒng)網絡正面臨著越來越多的問題，比如對網絡設備的管理、對網絡的擴展與延伸、對網絡的集中控制。軟件定義網絡作為一種新型的網絡架構，通過將控制平面和數據平面分離，從而實現對網絡流量的靈活控制，控制平面負責生成轉發(fā)策略并給應用層提供開發(fā)的接口，數據平面負責數據包的轉發(fā)。SDN集中控制減少了復雜網絡的管理和配置，但隨著網絡規(guī)模的擴大和服務需求的增加，對于大量交換機的流請求和控制平面的擴展，單一的集中式控制器已無法滿足整個網絡的性能需求，這就促進了多控制器架構的產生。

多控制器的協(xié)同工作可以更加方便的實現對網絡進行擴展和對網絡設備的管理，控制器之間通過東西向接口完成數據同步和對全網的管理，多控制器架構解決了單個控制器的低擴展性和高負載的問題，同時多控制器的架構也帶來了問題。多控制器之間的通信缺乏安全規(guī)范，現有的OpenFlow協(xié)議僅給出了控制器和交換機間的通信規(guī)范，但并未指定多個控制器之間通信的具體安全協(xié)議和標準，因而多個控制器之間的通信仍面臨著認證、數據同步等方面的安全問題；同時如何實現多控制器間的負載均衡以達到資源的有效利用，如何實現多控制器間的故障轉移，避免單控制器的失效導致網絡的癱瘓，這些也是多控制器架構面臨的挑戰(zhàn)。

技術實現要素：

發(fā)明目的：本發(fā)明的目的在于解決現有技術中存在的不足，提供一種基于OpenFlow協(xié)議的多控制器協(xié)同平臺的協(xié)同方法。

技術方案：本發(fā)明所述的一種基于OpenFlow協(xié)議的多控制器協(xié)同平臺的協(xié)同方法，所述多控制器協(xié)同平臺包括控制器安全連接模塊、交換機證書密鑰存儲模塊、負載均衡策略模塊和故障轉移策略模塊，具體包括以下步驟：

(1)通過控制器安全連接模塊多控制器協(xié)同平臺與控制器之間采用基于消息認證碼的安全通信機制，防止攻擊者接入到控制器，多控制器協(xié)同平臺提供有效的信任評估；

(2)通過交換機證書密鑰存儲模塊對控制器和交換機之間的安全傳輸TLS認證過程進行改進，讓各個交換機生成聚合證書，并與控制器進行安全認證，并將交換機的證書與密鑰存于多控制器協(xié)同平臺；

(3)通過負載均衡策略模塊多控制器協(xié)同平臺持續(xù)查看全網各個控制器的負載情況，并制定相應的負載均衡算法；

(4)通過故障轉移策略模塊多控制器協(xié)同平臺持續(xù)查看全網各個控制器是否處于正常工作狀態(tài)，，當發(fā)現某個控制器發(fā)生故障時，及時執(zhí)行故障轉移策略，并將故障控制器管理的交換機的證書和密鑰發(fā)送給即將連接的控制器進行認證。

進一步的，所述步驟(1)的具體過程為：

(11)在發(fā)送消息前，各個控制器與多控制器協(xié)同平臺之間首先協(xié)商好共同的散列函數和密鑰；

(12)當控制器給多控制器協(xié)同平臺發(fā)送消息時，控制器使用雙方協(xié)商好的散列函數和密鑰計算得到消息對應的的散列值MAC，并將消息和MAC一起發(fā)送給多控制器協(xié)同平臺；

(13)當多控制器協(xié)同平臺收到消息和MAC時，同時利用協(xié)商好的散列函數計算消息的散列值，將此本地計算出的散列值和收到的MAC比較，若兩者相等，則消息通過認證。

進一步的，所述步驟(2)的具體過程為：

(21)采用深度優(yōu)先遍歷將所有交換機的證書和密鑰發(fā)送給根節(jié)點交換機，該根節(jié)點交換機將所有交換機的證書和密鑰發(fā)送給控制器統(tǒng)一進行TLS安全認證；

(22)控制器將該域范圍內所有交換機的證書與密鑰存于多控制器協(xié)同平臺中。

進一步的，所述步驟(3)的具體過程為：

(31)多控制器協(xié)同平臺設置負載均衡系數LB和浮動系數FL，例如初始時設置LB為0.8，FL為0.2，當對負載均衡精度要求比較高時，就適當改變參數的數值；

(32)多控制器協(xié)同平臺每隔一段時間(例如可以是30s)，統(tǒng)計各個控制器收到的Packet-in消息的數量CP作為各個控制器自身的負載，并且分別統(tǒng)計該控制器所連交換機這段時間發(fā)給控制器的Packet-in消息數量SP；

(33)多控制器協(xié)同平臺根據收到的控制器負載信息，計算出各個控制器負載CP的平均值AVG_CP，并篩選出各個控制器的負載CP中的最大值MAX_CP與最小值MIN_CP，然后計算出AVG_CP/MAX_CP；

(34)當AVG_CP/MAX_CP不在(LB-FL，LB+FL)區(qū)間內時，就執(zhí)行負載均衡策略；

(35)當需要執(zhí)行負載均衡策略時，多控制器協(xié)同平臺就篩選出負載最大的控制器所連交換機中SP最大的交換機，通過修改控制器的角色，將這個交換機轉移給負載最小的控制器進行控制。

進一步的，所述步驟(4)的具體過程為：

(41)多控制器協(xié)同平臺持續(xù)監(jiān)聽各控制器的狀態(tài)，檢測是否有控制器發(fā)生故障：當檢測到某臺控制器出現故障時，多控制器協(xié)同平臺選擇出剩余控制器中負載最小的控制器，通過修改其角色，將故障控制器管理的交換機轉移給這臺控制器進行控制；

(42)將存于多控制器協(xié)同平臺的交換機的密鑰和證書發(fā)送給這臺控制器進行認證，避免這些交換機重新給控制器發(fā)送證書和密鑰進行認證。

有益效果：本發(fā)明，與現有技術相比具有以下優(yōu)點：

(1)本發(fā)明考慮了在實際場景中可能存在偽造的攻擊者接入到控制器，獲取網絡的拓撲結構并竊取和修改網絡數據，造成網絡癱瘓的問題；本發(fā)明讓控制器與多控制器協(xié)同平臺間的通信采用基于消息認證碼的驗證，多控制器協(xié)同平臺可以相信消息未被修改，因為如果攻擊者改變了消息，但他無法改變相應的MAC，所以多控制器協(xié)同平臺計算出的MAC將不等于接收到的MAC；多控制器協(xié)同平臺可以相信消息是來自真實的控制器C，因為其他各方均不知道密鑰，因此偽造方不能產生具有正確的MAC，這樣就能確保多控制器協(xié)同平臺與控制器之間的通信安全。

(2)本發(fā)明考慮了在OpenFlow協(xié)議的通信規(guī)范中，控制器和交換機之間采用安全傳輸協(xié)議TLS對消息進行加密和認證，該過程涉及多次握手及信息確認步驟，此操作較為繁瑣。本發(fā)明改進控制器和交換機的認證過程，讓各個交換機生成聚合證書，統(tǒng)一的與控制器進行基于TLS的安全認證，并將交換機的證書與密鑰存于多控制器協(xié)同平臺，避免了控制器與每個交換機進行多次繁瑣的握手與信息確認，提高了控制層和基礎設置之間的安全認證效率，同時也節(jié)省了帶寬。

(3)本發(fā)明考慮了多控制器之間的負載均衡問題，多控制器協(xié)同平臺持續(xù)監(jiān)控全網各個控制器的負載情況，并制定相應的算法，實現各個控制器之間的負載均衡。

(4)本發(fā)明考慮了多控制器之間的故障轉移問題，多控制器協(xié)同平臺持續(xù)監(jiān)控全網各個控制器的狀態(tài)，當發(fā)現某個控制器發(fā)生故障時，及時執(zhí)行故障轉移的策略，實現了控制器故障的動態(tài)轉移。

附圖說明

圖1為本發(fā)明的整體結構示意圖；

圖2為本發(fā)明步驟(1)中安全通信的示意圖；

圖3為本發(fā)明步驟(2)中安全認證的示意圖；

圖4為本發(fā)明步驟(3)中負載均衡策略的具體流程圖；

圖5為本發(fā)明步驟(4)中故障轉移策略的具體流程圖。

具體實施方式

下面對本發(fā)明技術方案進行詳細說明，但是本發(fā)明的保護范圍不局限于所述實施例。

如圖1所示，本發(fā)明基于OpenFlow協(xié)議的多控制器協(xié)同平臺的協(xié)同方法中，在控制器平面上建立一個多控制器協(xié)同平臺，多控制器協(xié)同平臺由控制器安全連接模塊、交換機證書密鑰存儲模塊、負載均衡策略模塊和故障轉移策略模塊這4個模塊構成。

其中，控制器安全連接模塊負責協(xié)同平臺和控制器的安全連接，交換機證書密鑰存儲模塊負責管理交換機的證書與密鑰，負載均衡模塊負責實現各個控制器的負載均衡，故障轉移模塊負責實現各個控制器的故障恢復。

控制器與多控制器協(xié)同平臺間的通信采用基于消息認證碼的驗證，以保證多控制器協(xié)同平臺所收到的消息確實來自真實的發(fā)送方控制器，且是未被修改的消息，控制器與交換機之間采用改進的安全傳輸協(xié)議TLS進行認證；同時多控制器協(xié)同平臺通過收集各個控制器的狀態(tài)信息，從而下發(fā)策略實現多控制器間的負載均衡與故障轉移。

如圖2所示，本發(fā)明中控制器與多控制器協(xié)同平臺安全通信過程為：多控制器協(xié)同平臺與控制器之間采用基于消息認證碼的安全通信機制，控制器與多控制器協(xié)同平臺共同協(xié)商的密鑰可以設為0xFFFF，散列函數可以是將消息字符串映射為整形數字，并與密鑰0xFFFF進行異或，產生消息認證碼。當控制器連接多控制器協(xié)同平臺時，控制器給多控制器協(xié)同平臺發(fā)送的requestconnect消息加密為requestconnect577b，多控制器協(xié)同平臺接收到消息requestconnect577b，通過對消息requestconnect使用散列函數計算MAC，計算得到577b，和接收到的消息認證碼相同，說明認證成功，若認證不成功，多控制器協(xié)同平臺將拒絕控制器的連接請求。

如圖3所示，本發(fā)明中控制器與交換機安全認證的具體過程為：本方案采用深度優(yōu)先遍歷將所有交換機的證書和密鑰發(fā)送給根節(jié)點交換機，這個交換機將所有交換機的證書和密鑰發(fā)送給控制器統(tǒng)一進行認證，認證后，控制器將該域范圍內所有交換機的證書與密鑰存于多控制器協(xié)同平臺中。這樣控制器不需要與每個交換機都進行多次握手及信息確認，只需和所有交換機進行一次統(tǒng)一的認證，且當某個控制器發(fā)生故障時，將存于多控制器協(xié)同平臺的交換機的證書和密鑰發(fā)送給新的控制器進行認證，避免了這些交換機重新給控制器發(fā)送證書和密鑰進行認證，節(jié)省了帶寬，同時也提高了資源利用率。

如圖4所示，本發(fā)明中負載均衡策略的具體流程為：控制器的主要負載來源于Packet-in消息，多控制器協(xié)同平臺每隔一段時間統(tǒng)計各個控制器收到的Packet-in消息的數量CP作為各個控制器自身的負載，并且分別統(tǒng)計該控制器所連交換機這段時間發(fā)給控制器的Packet-in消息數量SP。協(xié)同平臺根據收到的控制器負載信息，計算出各個控制器負載CP的平均值AVG_CP，并計算出各個控制器的負載CP中的最大值MAX_CP與最小值MIN_CP，然后計算出AVG_CP/MAX_CP，這個值在一定范圍內浮動越小，各控制器負載越均衡。設置一個負載均衡系數LB和一個浮動系數FL，當AVG_CP/MAX_CP不在(LB-FL，LB+FL)區(qū)間內，就執(zhí)行負載均衡策略，初始時我們設置LB為0.8，FL為0.2，當對負載均衡精度要求比較高時，可以適當改變參數的數值。當需要執(zhí)行負載均衡策略時，多控制器協(xié)同平臺就篩選出負載最大的控制器所連交換機中SP最大的交換機，通過修改控制器的角色，將這個交換機轉移給負載最小的控制器進行控制，這樣一段時間后，可實現局域網內所有控制器之間的負載均衡。

如圖5所示，本發(fā)明中故障轉移策略的具體流程為：多控制器協(xié)同平臺負責管理控制器的角色，初始時多控制器協(xié)同平臺通過控制器提供的REST-API將角色下發(fā)給控制器，并持續(xù)監(jiān)聽各控制器的狀態(tài)，檢測是否有控制器發(fā)生故障。當檢測到某臺控制器出現故障時，多控制器協(xié)同平臺選擇出剩余控制器中負載最小的控制器，通過修改其角色，將故障控制器管理的交換機轉移給這臺控制器進行控制，并將存于多控制器協(xié)同平臺的交換機的密鑰和證書發(fā)給這臺控制器進行認證，這樣可以實現多控制間的故障轉移，且避免了這些交換機重新給控制器發(fā)送證書和密鑰進行認證。