本發(fā)明涉及一種SDN體系架構中協(xié)調層的構建方法，屬于計算機應用技術領域。

背景技術：

隨著“大物移云”，即大數(shù)據(jù)、物聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)和云計算的時代到來，傳統(tǒng)的底層網(wǎng)絡架構已經(jīng)無法滿足管理者的需求，設備繁雜配置麻煩迭代緩慢，各種問題層出不窮。下一代網(wǎng)絡，需要的是可編程按需定制、集中式統(tǒng)一管理、動態(tài)流量監(jiān)管、自動化部署等。這些都是軟件定義網(wǎng)絡(SDN)的出發(fā)點。

SDN最大的特點是控制和轉發(fā)完全分離，其中控制層實現(xiàn)集中式控制、軟件可編程、可視化、自動化等，轉發(fā)層通過硬件實現(xiàn)高速轉發(fā)。但直接對接SDN的控制層和轉發(fā)層很難滿足實際網(wǎng)絡中的需求。這體現(xiàn)在以下兩方面：

一方面，在控制層中，不同北向控制器之間應用功能的成熟度存在差異，例如有的北向控制器防火墻功能較為成熟，而有的北向控制器負載均衡器功能較為成熟，導致底層網(wǎng)絡的管理者在控制層部署不同北向控制器的成熟應用對轉發(fā)層設備進行控制。此外，即使北向控制器相同，不同轉發(fā)層設備需要的網(wǎng)絡功能也存在差異，導致控制不同轉發(fā)層設備的北向控制器也需要提供不同的應用。實際上來自轉發(fā)層的網(wǎng)絡請求需要由多種不同的北向控制器應用來處理，因此直接對接SDN的控制層和轉發(fā)層很難滿足這一需求，這要求轉發(fā)層和應用異構型的控制層之間具有針對不同應用實現(xiàn)OpenFlow消息調度的能力。

另一方面，由于單個北向控制器節(jié)點的處理能力有限，隨著接入層和轉發(fā)層網(wǎng)絡規(guī)模的擴大，單個北向控制器將無法滿足控制層的處理性能要求，這要求轉發(fā)層和應用異構型的控制層之間具有彈性部署北向控制器的能力，直接對接SDN的控制層和轉發(fā)層也很難滿足這一需求。

綜上所述，SDN的控制層與轉發(fā)層架構存在缺陷，直接對接SDN的控制層和轉發(fā)層很難滿足實際網(wǎng)絡中的需求。

技術實現(xiàn)要素：

為了應對上述挑戰(zhàn)，本發(fā)明提出了一種SDN體系架構中協(xié)調層的構建方法。該方法在控制層和轉發(fā)層之間添加了一層集中式的協(xié)調層，即OpenFlow協(xié)調器，使得控制層中的多個SDN北向控制器彼此合作分擔控制層業(yè)務負載，實現(xiàn)OpenFlow控制流在多個應用異構型北向控制器間靈活調度，從而滿足管理者在實際網(wǎng)絡中的需求，提升整個SDN系統(tǒng)的可用性和可靠性。

本發(fā)明的技術方案：

一種SDN體系架構中協(xié)調層的構建方法，邏輯功能上由南向交換機信道管理，北向控制器信道管理，以及OFPT_PACKET_IN消息分發(fā)三部分組成。

其中，南向交換機信道管理是協(xié)調器訪問轉發(fā)層的橋梁，涉及南向交換機信道管理的工作有：一、接收到由南向交換機發(fā)起的信道建立請求后，處理對應的OpenFlow握手流程，并根據(jù)握手過程中的OFPT_FEATURES_REPLY和OFPST_DESC消息在協(xié)調器中為每個南向交換機建立對應的物理交換機對象，協(xié)調器通過建立的物理交換機對象既可以向對應的南向交換機發(fā)送OpenFlow消息，也可以處理對應的南向交換機發(fā)送的OpenFlow消息；二、進行基于LLDP與BDDP協(xié)議的拓撲鏈路發(fā)現(xiàn)任務以及基于OFPT_STATS_REPLY的統(tǒng)計信息收集任務，將獲取的網(wǎng)絡狀態(tài)信息存儲在協(xié)調器中，供北向控制器訪問。

北向控制器信道管理是協(xié)調器訪問控制層的橋梁，涉及北向控制器信道管理的工作有：一、接收到控制層變容的請求后，向新增的北向控制器發(fā)起信道建立請求，處理對應的OpenFlow握手流程，在協(xié)調器中為每個控制信道建立對應的虛擬交換機對象，協(xié)調器通過建立的虛擬交換機對象既可以向對應的北向控制器發(fā)送OpenFlow消息，也可以處理對應的北向控制器發(fā)送的OpenFlow消息；二、根據(jù)存儲在協(xié)調器中的網(wǎng)絡狀態(tài)信息處理北向控制器對于拓撲鏈路和統(tǒng)計信息的OpenFlow請求消息。

OFPT_PACKET_IN消息分發(fā)是協(xié)調器實現(xiàn)OpenFlow控制流在多個應用異構型北向控制器間靈活調度的核心與基礎，涉及OFPT_PACKET_IN消息分發(fā)的工作有：一、為每個北向控制器設置單獨的OFPT_PACKET_IN消息隊列，用于反映當前北向控制器對于OpenFlow消息的處理情況；二、當物理交換機對象接收到對應南向交換機向控制層發(fā)送的OFPT_PACKET_IN消息時，會根據(jù)北向控制器提供的服務種類以及消息隊列的情況進行消息分發(fā)，將消息分發(fā)給合適的虛擬交換機對象對應的控制信道，并把消息的標識加入對應北向控制器的消息隊列，代表消息正在被北向控制器處理；三、北向控制器處理完畢請求后發(fā)送OFPT_PACKET_OUT、OFPT_FLOW_MOD以及OFPT_PORT_MOD消息給虛擬交換機對象，虛擬交換機對象將消息發(fā)送給物理交換機對象對應的南向交換機，并把消息的標識彈出對應北向控制器的消息隊列，代表消息已被北向控制器處理完畢。

本發(fā)明的有益效果：

1.支持應用異構型的SDN控制層。允許管理者在控制層部署提供不同功能和服務的應用異構型北向控制器，組成一個北向控制器集群對轉發(fā)層設備進行集中管控。

2.支持動態(tài)的SDN控制層變容。允許管理者在SDN系統(tǒng)上線運行的過程中，在控制層彈性部署SDN北向控制器，分擔原有控制層的業(yè)務負載。

附圖說明

圖1是本發(fā)明的整體架構圖。

圖2是本發(fā)明的物理交換機模塊OpenFlow消息處理狀態(tài)機圖。

圖3是本發(fā)明的物理交換機模塊網(wǎng)絡狀態(tài)維護圖。

圖4是本發(fā)明的虛擬交換機模塊OpenFlow消息處理狀態(tài)機圖。

圖5(a)是本發(fā)明的消息隊列模塊南向業(yè)務流程圖。

圖5(b)是本發(fā)明的消息隊列模塊北向業(yè)務流程圖。

圖6是本發(fā)明的遠程管理模塊架構圖。

圖7是本發(fā)明的遠程管理模塊業(yè)務流程圖。

具體實施方式

以下結合附圖和技術方案，進一步說明本發(fā)明的具體實施方式。

一種SDN體系架構中協(xié)調層的構建方法，如圖1所示，整體架構中協(xié)調層即OpenFlow協(xié)調器，位于應用異構型的SDN控制層和轉發(fā)層之間；在OpenFlow協(xié)調器中，物理交換機對象負責與南向交換機建立連接，使得OpenFlow協(xié)調器對于轉發(fā)層來說是一個集中的北向控制器，它的最終決策來源于應用異構型的SDN控制層，而虛擬交換機對象負責與北向控制器建立連接，使得OpenFlow協(xié)調器對于控制層來說是一個交換機的集合，它的最終轉發(fā)由轉發(fā)層完成；

OpenFlow協(xié)調器劃分為物理交換機模塊、虛擬交換機模塊、消息隊列模塊以及遠程管理模塊；

物理交換機模塊，在OpenFlow協(xié)調器上線后被啟動，在協(xié)調器對應的主機IP地址和端口上建立Socket，與之綁定的消息管道處理器有OpenFlow消息編解碼器、管道空閑處理器、讀超時處理器、OpenFlow握手超時處理器、管道線程池處理器以及OpenFlow消息處理器；消息管道的處理流程分為Socket讀流程和Socket寫流程；Socket讀流程涉及的處理器依次是：OpenFlow消息解碼器、管道空閑處理器、讀超時處理器、OpenFlow握手超時處理器、管道線程池處理器以及OpenFlow消息處理器。Socket寫流程涉及的處理器依次是OpenFlow消息處理器、管道線程池處理器以及OpenFlow消息編碼器。

物理交換機模塊中，OpenFlow消息解碼器根據(jù)OpenFlow協(xié)議棧將OpenFlow消息部分從管道消息的數(shù)據(jù)部分讀取出來，而OpenFlow消息編碼器將OpenFlow消息寫入管道消息的數(shù)據(jù)部分；管道空閑處理器用于管理心跳機制，檢測遠端是否存活；讀超時處理器用于控制讀取數(shù)據(jù)時發(fā)生的超時情況，如果一段時間內沒有數(shù)據(jù)讀取就引發(fā)讀超時，并關閉當前的消息管道；OpenFlow握手超時處理器用于控制OpenFlow握手流程中發(fā)生的超時情況，從握手流程開始時計算一段時間內如果沒有握手成功就引發(fā)OpenFlow握手超時，并關閉當前的消息管道；管道線程池處理器用于轉發(fā)管道消息給線程池執(zhí)行多線程操作，提升消息處理的并發(fā)性；OpenFlow消息處理器用于處理南向交換機發(fā)送的OpenFlow消息，如圖2所示，OpenFlow消息的處理過程定義為狀態(tài)機，在不同的狀態(tài)下，對OpenFlow消息采取不同的處理方式，接收到特定消息后根據(jù)OpenFlow協(xié)議，進行狀態(tài)轉移；

物理交換機模塊同遠端南向交換機建立連接后，狀態(tài)機的初始狀態(tài)從INIT轉移到WAIT HELLO，并發(fā)起OpenFlow握手流程，根據(jù)OpenFlow協(xié)議標準，轉移到中間狀態(tài)WAIT FT_REP、WAIT CONFIG_REP和WAIT DESC_STATS。發(fā)生握手超時后，從當前狀態(tài)轉移到CHANNEL CLOSED，并中斷握手流程。當狀態(tài)成功轉移到ACTIVE時，物理交換機模塊同南向交換機間的OpenFlow握手成功，物理交換機模塊為南向交換機在協(xié)調器中建立對應的物理交換機對象，開始ECHO REPLY，并啟動新建物理交換機對象中的拓撲鏈路發(fā)現(xiàn)和統(tǒng)計信息收集網(wǎng)絡狀態(tài)維護功能。如圖3所示，網(wǎng)絡狀態(tài)維護由定時發(fā)送LLDP和BDDP 以及定時發(fā)送OFPT_STATS_REQUEST兩部分構成。南向交換機向控制層發(fā)送的OpenFlow消息通過物理交換機對象進行處理。接收到LLDP、BDDP以及OFPT_STATS_REPLY后，根據(jù)網(wǎng)絡狀態(tài)維護功能更新網(wǎng)絡狀態(tài)，將發(fā)現(xiàn)的鏈路加入拓撲，并存儲收集的統(tǒng)計信息，供控制層訪問。接收到OFPT_PACKET_IN后，請求消息隊列模塊，經(jīng)由合適的虛擬交換機對象發(fā)送給對應的北向控制器。遠端南向交換機同物理交換機模塊斷開連接時，狀態(tài)機的狀態(tài)轉移到CHANNEL CLOSED，物理交換機模塊關閉對應的消息管道，回收管道處理器資源。

虛擬交換機模塊，在物理交換機模塊上線后被啟動，接收到控制層變容的請求后，針對每個已存在的物理交換機對象，同新加入北向控制器對應的主機IP地址和端口建立Socket，并建立對應的虛擬交換機對象，與之綁定的消息管道處理器有：重連接處理器、OpenFlow消息編解碼器、管道空閑處理器、讀超時處理器、OpenFlow握手超時處理器、管道線程池處理器以及OpenFlow消息處理器。消息管道的處理流程可分為Socket讀流程和Socket寫流程。Socket讀流程涉及的處理器依次是：重連接處理器、OpenFlow消息解碼器、管道空閑處理器、讀超時處理器、OpenFlow握手超時處理器、管道線程池處理器以及OpenFlow消息處理器。Socket寫流程涉及的處理器依次是OpenFlow消息處理器、管道線程池處理器、OpenFlow消息編碼器以及重連接處理器。

虛擬交換機模塊中，OpenFlow消息編解碼器、管道空閑處理器、讀超時處理器、OpenFlow握手超時處理器、管道線程池處理器的作用與物理交換機模塊中相同。重連接處理器用于消息管道斷開時的重連接操作，連接斷開時等待一段時間后與遠端重新建立連接。OpenFlow消息處理器用于處理北向控制器發(fā)送的OpenFlow消息，如圖4所示，OpenFlow消息的處理過程定義為狀態(tài)機，在不同的狀態(tài)下，對OpenFlow消息采取不同的處理方式，接收到特定消息后根據(jù)OpenFlow協(xié)議，進行狀態(tài)轉移。

虛擬交換機模塊同遠端北向控制器建立連接后，狀態(tài)機的初始狀態(tài)從INIT轉移到WAIT HELLO，并發(fā)起OpenFlow握手流程，檢測OpenFlow協(xié)議兼容性，根據(jù)OpenFlow協(xié)議標準，轉移到中間狀態(tài)WAIT FT_REQ，虛擬交換機模塊依據(jù)對應的物理交換機對象信息構建FT_REP。當OpenFlow協(xié)議不兼容或握手超時后，從當前狀態(tài)轉移到CHANNEL CLOSED，并中斷握手流程。當狀態(tài)成功轉移到ACTIVE時，虛擬交換機模塊同北向控制器間的OpenFlow握手成功，開始ECHO REQUEST和ECHO REPLY，北向控制器向轉發(fā)層發(fā)送的OpenFlow消息通過虛擬交換機對象進行處理。虛擬交換機模塊接收到LLDP、BDDP以及OFPT_STATS_REQUEST后，根據(jù)已存儲的網(wǎng)絡狀態(tài)對北向控制器進行回復。接收到OFPT_PACKET_OUT、OFPT_FLOW_MOD以及OFPT_PORT_MOD后，請求消息隊列模塊，經(jīng)由合適的物理交換機對象發(fā)送給對應的南向交換機。北向控制器同虛擬交換機模塊斷開連接時，狀態(tài)機的狀態(tài)轉移到CHANNEL CLOSED，虛擬交換機模塊嘗試重連接北向控制器，重連接成功后，恢復對應的消息管道處理，重連接失敗后，虛擬交換機模塊關閉對應的消息管道，回收管道處理器資源。

消息隊列模塊，在虛擬交換機模塊上線后被啟動，為OpenFlow控制流的轉發(fā)提供策略；提供不同功能的南向交換機需求不同的控制層服務，將提供對應服務的北向控制器加入相對應的服務分組，即南向交換機的需求與北向控制器提供的服務是相互對應；為北向控制器創(chuàng)建消息隊列時，將北向控制器的服務分組作為消息隊列的屬性，同時該屬性也存在于物理交換機對象中；北向控制器各自擁有獨立的消息隊列，消息隊列的更新操作分為入隊操作和出隊操作，入隊操作將轉發(fā)層發(fā)送的OFPT_PACKET_IN消息的buffer_id字段作為消息的標識加入隊列，令隊列長度自增，出隊操作將控制層發(fā)送的OFPT_PACKET_OUT消息的buffer_id字段作為消息的標識從隊列中彈出，令隊列長度自減，消息隊列中的入隊以及出隊操作具有原子性。

如圖5（a）所示，當物理交換機模塊收到轉發(fā)層發(fā)送的OpenFlow請求時，向消息隊列模塊請求合適的北向控制器。消息隊列模塊收到請求，根據(jù)物理交換機對象的服務分組屬性，查詢對應服務分組內的消息隊列，并選擇其中負載因子最小，即隊列長度與負載權重乘積最小的消息隊列，負載權重是一個介于0和1之間的實數(shù)，類型為double，根據(jù)組織者設置的轉發(fā)策略確定，消息隊列模塊將OpenFlow請求入隊，并返回相應的北向控制器接口，供物理交換機模塊進行請求轉發(fā)。

如圖5（b）所示，當虛擬交換機模塊收到控制層發(fā)送的OpenFlow決策時,請求消息隊列模塊將相應的OpenFlow請求出隊。北向控制器各自的消息隊列中反映的是當前北向控制器對于OpenFlow請求的處理情況。

遠程管理模塊，在消息隊列模塊上線后被啟動，為協(xié)調器的管理提供遠程接口。如圖6所示，來自外部的控制請求由RPC服務器接收并進行處理，RPC服務器提供兩種WebSocket，分別是HTTP WebSocket和HTTPS WebSocket，其中HTTPS WebSocket提供基于SSL證書認證的加密數(shù)據(jù)傳輸?shù)倪B接。WebSocket的處理綁定了兩種服務組件，要求處理前進行請求身份的認證，不同的請求身份擁有不同的服務組件的訪問權限，其中監(jiān)控者身份僅可以訪問監(jiān)控服務組件，管理員身份除了可以訪問監(jiān)控服務組件，還可以訪問管理服務組件。監(jiān)控服務組件提供三種監(jiān)控服務的接口，分別是查詢網(wǎng)絡狀態(tài)，查詢消息隊列以及查詢資源列表。其中查詢網(wǎng)絡狀態(tài)用于讀取保存在協(xié)調器中的由物理交換機對象負責維護的網(wǎng)絡狀態(tài)，包括轉發(fā)層的拓撲鏈路以及統(tǒng)計信息，查詢消息隊列用于讀取消息隊列模塊負責維護的各個北向控制器的消息隊列狀態(tài)，查詢資源列表用于讀取保存在協(xié)調器中的物理交換機對象、虛擬交換機對象、北向控制器列表以及三者之間的映射關系。管理服務組件提供三種管理服務的接口，分別是控制層變容，設置轉發(fā)策略以及設置服務分組。其中控制層變容用于彈性的增加或減少控制層中的北向控制器，創(chuàng)建或刪除虛擬交換機對象以及同北向控制器的連接，設置轉發(fā)策略用于更新消息隊列模塊中的負載權重，設置服務分組用于更新物理交換機對象和消息隊列中的服務分組屬性。遠程管理模塊的業(yè)務流程如圖7所示。