本發(fā)明涉及網(wǎng)絡(luò)技術(shù)領(lǐng)域，更具體的說是一種基于Openflow協(xié)議的實(shí)時(shí)數(shù)據(jù)分發(fā)系統(tǒng)和方法。

背景技術(shù)：

隨著控制、通信、計(jì)算機(jī)等技術(shù)的飛速發(fā)展，各種應(yīng)用系統(tǒng)的體系結(jié)構(gòu)呈現(xiàn)出以網(wǎng)絡(luò)為中心的趨勢(shì)，這對(duì)通信網(wǎng)絡(luò)的實(shí)時(shí)性、動(dòng)態(tài)性、靈活性都提出了更高的要求。同時(shí)希望系統(tǒng)中各個(gè)參與者間是一種松散耦合的關(guān)系，且QoS請(qǐng)求還需要支持靈活的交互機(jī)制和通信模式。現(xiàn)有的發(fā)布/訂閱系統(tǒng)能夠提供松耦合的通信模式，但卻缺乏合適的系統(tǒng)控制和應(yīng)用級(jí)QoS支持。因此，急需一種基于發(fā)布/訂閱模式且能有效合理地控制部署實(shí)時(shí)系統(tǒng)所需的QoS參數(shù)的系統(tǒng)來滿足分布式實(shí)時(shí)應(yīng)用需求。

動(dòng)態(tài)應(yīng)用的本質(zhì)是對(duì)底層通信系統(tǒng)和通信網(wǎng)絡(luò)的挑戰(zhàn)，這就增加了對(duì)網(wǎng)絡(luò)可擴(kuò)展性和支持高QoS特性的挑戰(zhàn)。實(shí)際上，如果網(wǎng)絡(luò)資源利用率是關(guān)注的焦點(diǎn)，那么網(wǎng)絡(luò)必須足夠靈活來實(shí)現(xiàn)針對(duì)網(wǎng)絡(luò)應(yīng)用變化的重新規(guī)劃。當(dāng)前的方法要么解決應(yīng)用的動(dòng)態(tài)性問題，要么關(guān)注網(wǎng)絡(luò)資源的利用率，且都是基于靜態(tài)的專用網(wǎng)絡(luò)或覆蓋網(wǎng)，這使得按需設(shè)置網(wǎng)絡(luò)性能很困難。軟件定義網(wǎng)絡(luò)SDN的出現(xiàn)為解決上述問題提供了新的方法，其靈活的組網(wǎng)特點(diǎn)能夠?qū)崿F(xiàn)細(xì)粒度按需動(dòng)態(tài)網(wǎng)絡(luò)規(guī)劃。因此，SDN能夠有效地支撐動(dòng)態(tài)分布式實(shí)時(shí)應(yīng)用，同時(shí)保證網(wǎng)絡(luò)資源利用率很高。

本發(fā)明主要目的是提出一種結(jié)合數(shù)據(jù)分發(fā)服務(wù)中間件和基于Openflow協(xié)議的SDN的通信系統(tǒng)來高效支持動(dòng)態(tài)實(shí)時(shí)應(yīng)用。采用數(shù)據(jù)分發(fā)服務(wù)的原因是因?yàn)閿?shù)據(jù)分發(fā)服務(wù)應(yīng)用被成功用于高性能分布式實(shí)時(shí)系統(tǒng)，能夠提供許多QoS參數(shù)用于數(shù)據(jù)分發(fā)服務(wù)表達(dá)應(yīng)用的需求。這些QoS參數(shù)大部分是動(dòng)態(tài)的，且可以在運(yùn)行時(shí)改變，以保證數(shù)據(jù)分發(fā)服務(wù)中間件捕獲動(dòng)態(tài)應(yīng)用的QoS需求。數(shù)據(jù)分發(fā)服務(wù)支持的Pub/sub模型能夠進(jìn)一步捕獲應(yīng)用的動(dòng)態(tài)性，允許應(yīng)用組成部分動(dòng)態(tài) 的改動(dòng)數(shù)據(jù)流。為了確保QoS，對(duì)終端用戶和網(wǎng)絡(luò)資料的控制都是強(qiáng)制的。對(duì)于終端用戶，當(dāng)數(shù)據(jù)分發(fā)服務(wù)存在于終端用戶，就需要定義一組機(jī)制來實(shí)現(xiàn)QoS認(rèn)知控制來接入主機(jī)資源；對(duì)于網(wǎng)絡(luò)資源，網(wǎng)絡(luò)接口需要根據(jù)應(yīng)用需求管理網(wǎng)絡(luò)資源，這些需求正好是SDN能夠提供的。

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

本發(fā)明針對(duì)分布式實(shí)時(shí)應(yīng)用，提出了一種基于Openflow協(xié)議的實(shí)時(shí)數(shù)據(jù)分發(fā)系統(tǒng)和方法，采用數(shù)據(jù)分發(fā)服務(wù)中間件和軟件定義網(wǎng)絡(luò)相結(jié)合的網(wǎng)絡(luò)框架，以滿足分布式實(shí)時(shí)應(yīng)用對(duì)QoS動(dòng)態(tài)變化的需求。

本發(fā)明為實(shí)現(xiàn)上述目的所采用的技術(shù)方案是：一種基于Openflow協(xié)議的實(shí)時(shí)數(shù)據(jù)分發(fā)系統(tǒng)，包括：

數(shù)據(jù)分發(fā)服務(wù)組件，基于以數(shù)據(jù)為中心的分發(fā)/訂閱模型，用于提供實(shí)時(shí)數(shù)據(jù)傳送，并通過QoS分級(jí)和搶占機(jī)制來控制不同用戶對(duì)通信質(zhì)量的需求；基于發(fā)布/訂閱傳輸模型的用戶QoS需求分析和定義，并將結(jié)果反饋給控制器，控制器統(tǒng)一下發(fā)流表到底層交換設(shè)備；

SDN組件，用于將數(shù)據(jù)平臺(tái)和控制平臺(tái)分離，提供統(tǒng)一管控機(jī)制。

所述數(shù)據(jù)分發(fā)服務(wù)組件包括：

DDS代理模塊，用于分析收到的請(qǐng)求數(shù)據(jù)，將其解析為能夠被SDN組件中的控制器模塊理解的數(shù)據(jù)形式，然后發(fā)送到控制器模塊；

DDS接口API模塊，是路由代理模塊和DDS代理模塊的信息交互通道；

路由代理模塊，用于發(fā)現(xiàn)訂閱請(qǐng)求和發(fā)布請(qǐng)求，并將收到的請(qǐng)求通過DDS接口API模塊發(fā)送到DDS代理模塊。

所述SDN組件包括：

北向接口模塊，是控制器模塊與各種應(yīng)用的交互通道；

控制器模塊，用于對(duì)數(shù)據(jù)分發(fā)服務(wù)組件中的DDS代理模塊發(fā)來的請(qǐng)求進(jìn)行分析計(jì)算，并獲得相應(yīng)的路徑信息，下發(fā)到DDS代理模塊；

南向接口模塊，是控制器模塊與OF交換機(jī)模塊的連接通道；

OF交換機(jī)模塊，是支持Openflow協(xié)議的交換機(jī)，負(fù)責(zé)網(wǎng)絡(luò)底層數(shù)據(jù)的轉(zhuǎn)發(fā)，并通過南向接口模塊與控制器模塊交互控制信息；

Openflow協(xié)議模塊，是一種交換技術(shù)，建立軟件定義網(wǎng)絡(luò)，實(shí)現(xiàn)數(shù)據(jù)流只在底層的OF交換機(jī)模塊中傳輸，控制流由控制器模塊以流表的形式統(tǒng)一下發(fā)到各個(gè)OF交換機(jī)模塊。

所述控制器模塊包括：

網(wǎng)絡(luò)拓?fù)淠K，用于存儲(chǔ)網(wǎng)絡(luò)中邏輯拓?fù)浜臀锢硗負(fù)湫畔ⅲ?/p>

QoS模塊，是存儲(chǔ)并分析網(wǎng)絡(luò)QoS需求的模塊，負(fù)責(zé)對(duì)已有的QoS進(jìn)行存儲(chǔ)，并對(duì)新的QoS需求進(jìn)行響應(yīng)分析；

負(fù)載均衡模塊，是實(shí)現(xiàn)網(wǎng)絡(luò)資源合理分配的模塊，對(duì)網(wǎng)絡(luò)的帶寬和緩存資源進(jìn)行全局管理，結(jié)合網(wǎng)絡(luò)拓?fù)浜蚎oS需求為數(shù)據(jù)流分配合理的網(wǎng)絡(luò)資源，以最大化網(wǎng)絡(luò)資源利用率；

Openflow模塊，是Openflow協(xié)議的控制器部分，負(fù)責(zé)流表的下發(fā)及OF交換機(jī)傳來的控制數(shù)據(jù)的分析處理；

Vlan模塊，用于針對(duì)不同的發(fā)布/訂閱組進(jìn)行vlan劃分，即定義一個(gè)有相同主題的vlan，并針對(duì)不同vlan中的數(shù)據(jù)進(jìn)行統(tǒng)一的處理。

所述Openflow協(xié)議是Openflow-spec-v1.4.0。

所述QoS需求包括時(shí)延、帶寬、優(yōu)先級(jí)、搶占式需求。

一種基于Openflow協(xié)議的實(shí)時(shí)數(shù)據(jù)分發(fā)方法，包括以下步驟：

步驟1：當(dāng)一個(gè)終端應(yīng)用發(fā)起發(fā)布數(shù)據(jù)請(qǐng)求后，該請(qǐng)求被傳輸?shù)紻D組件中，接著傳到SDN組件中按照主題進(jìn)行存儲(chǔ)并返回發(fā)布成功消息；

步驟2：當(dāng)有訂閱端發(fā)起訂閱請(qǐng)求后，該請(qǐng)求也同樣被DDS組件傳到控制器模塊中，控制器模塊按主題查找是否有需求的主題已經(jīng)被注冊(cè)，如果沒有則給訂閱端發(fā)送訂閱失敗消息，如果有則返回訂閱成功消息；

步驟3：數(shù)據(jù)分發(fā)服務(wù)組件分析訂閱端的QoS需求，并將該QoS信息傳送到SDN組件中的控制器模塊，控制器模塊進(jìn)行存儲(chǔ)分析，調(diào)用相關(guān)的拓?fù)湫畔ⅰ?QoS功能模塊和負(fù)載均衡功能模塊計(jì)算出最優(yōu)的路由路徑；

步驟4：控制器模塊將最優(yōu)的路由路徑信息轉(zhuǎn)化為各個(gè)相關(guān)設(shè)備的流表信息，然后下發(fā)到OF交換機(jī)中，并按照流表轉(zhuǎn)發(fā)來自終端設(shè)備的數(shù)據(jù)，實(shí)現(xiàn)符合QoS需求的數(shù)據(jù)實(shí)時(shí)分發(fā)。

本發(fā)明具有以下優(yōu)點(diǎn)及有益效果：解決了分布式實(shí)時(shí)應(yīng)用對(duì)通信時(shí)延和帶寬的動(dòng)態(tài)需求問題，實(shí)現(xiàn)了對(duì)網(wǎng)絡(luò)資源的高效靈活配置。本發(fā)明中基于發(fā)布/訂閱分發(fā)模式的數(shù)據(jù)分發(fā)中間件，具有動(dòng)態(tài)分配QoS參數(shù)的能力，以應(yīng)對(duì)實(shí)時(shí)變化的數(shù)據(jù)流及其QoS需求。本發(fā)明中基于Openflow協(xié)議的軟件定義網(wǎng)絡(luò)架構(gòu)解決了網(wǎng)絡(luò)資源固定分配帶來的資源利用率低問題，提供了靈活的按需動(dòng)態(tài)網(wǎng)絡(luò)資源配置。另外，本發(fā)明通過對(duì)Openflow協(xié)議中的Meter表和端口隊(duì)列表相互協(xié)作實(shí)現(xiàn)復(fù)雜的QoS配置。本發(fā)明能夠極大的滿足用戶對(duì)QoS的動(dòng)態(tài)需求，同時(shí)提高了網(wǎng)絡(luò)資源的利用率，適用于對(duì)實(shí)時(shí)性有特別需求的網(wǎng)絡(luò)應(yīng)用中。

附圖說明

圖1為本發(fā)明的基于SDN的DDS框圖；

圖2為本發(fā)明的DDS的對(duì)象模型圖；

圖3為本發(fā)明的QoS保障機(jī)制示意圖；

圖4為本發(fā)明的控制器處理業(yè)務(wù)的流程；

圖5為本發(fā)明的QoS數(shù)據(jù)流處理過程。

具體實(shí)施方式

下面結(jié)合附圖及實(shí)施例對(duì)本發(fā)明做進(jìn)一步的詳細(xì)說明。

本發(fā)明針對(duì)分布式實(shí)時(shí)應(yīng)用提出了基于Openflow協(xié)議的實(shí)時(shí)數(shù)據(jù)分發(fā)系統(tǒng)和方法，該系統(tǒng)結(jié)合數(shù)據(jù)分發(fā)服務(wù)和軟件定義網(wǎng)絡(luò)框架，體系結(jié)構(gòu)如圖1所示。該系統(tǒng)主要包括底層網(wǎng)絡(luò)設(shè)備、DDS接口API(又稱南向接口)、控制器、DDS代理、北向接口和應(yīng)用服務(wù)。其中DDS代理、DDS接口API和底層網(wǎng)絡(luò)設(shè)備中的路由代理是DDS系統(tǒng)的組件，北向接口、控制器、南向接口、OF交換機(jī)和Openflow協(xié)議是軟件定義網(wǎng)絡(luò)的組件。該系統(tǒng)中的SDN支持Openflow 協(xié)議，通過流表實(shí)現(xiàn)數(shù)據(jù)的存儲(chǔ)轉(zhuǎn)發(fā)。終端用戶通過發(fā)布/訂閱傳輸模式按topic向數(shù)據(jù)分發(fā)系統(tǒng)進(jìn)行注冊(cè)，注冊(cè)信息通過DDS代理統(tǒng)一保存到控制器中，當(dāng)有APP請(qǐng)求時(shí)，由控制器根據(jù)保存的信息進(jìn)行統(tǒng)一路由計(jì)算并進(jìn)行流表下發(fā)，同時(shí)最優(yōu)化網(wǎng)絡(luò)資源的利用率。

本發(fā)明中的數(shù)據(jù)分發(fā)服務(wù)定義了一種基于發(fā)布/訂閱模式的標(biāo)準(zhǔn)框架，提供全局?jǐn)?shù)據(jù)存儲(chǔ)平臺(tái)，發(fā)布端用于寫數(shù)據(jù)，訂閱端用于讀數(shù)據(jù)。DDS提供一個(gè)完全解耦的靈活模塊化框架，該框架主要特點(diǎn)包括：采用匿名發(fā)布訂閱隱藏位置信息；允許多發(fā)布端和多訂閱端實(shí)現(xiàn)冗余；提供異步時(shí)間獨(dú)立的數(shù)據(jù)分布；提供基于消息的以數(shù)據(jù)為中心的連接管理；且兼容多種平臺(tái)。該系統(tǒng)的域成員對(duì)發(fā)布/訂閱模式中的數(shù)據(jù)按照QoS需求進(jìn)行緩存，該DDS對(duì)象模型如圖2所示，主要包括信息主題、域成員和數(shù)據(jù)域。域成員按照主題將要發(fā)送的數(shù)據(jù)通過數(shù)據(jù)發(fā)送器傳送到發(fā)布者，并按照服務(wù)質(zhì)量進(jìn)行隊(duì)列緩存，然后經(jīng)過DDS的數(shù)據(jù)域，然后由控制器進(jìn)行相應(yīng)的處理，根據(jù)Openflow計(jì)算出相應(yīng)的路由路徑，然后通過DDS代理向路由代理下發(fā)路由信息，然后存儲(chǔ)到各個(gè)交換機(jī)的流表中。然后再將發(fā)布端的數(shù)據(jù)經(jīng)過數(shù)據(jù)域傳送到訂閱者中。

基于Openflow協(xié)議的實(shí)時(shí)數(shù)據(jù)分發(fā)系統(tǒng)的工作流程服從Openflow協(xié)議，實(shí)時(shí)業(yè)務(wù)處理流程示意圖如圖3所示，其中DDS APP為數(shù)據(jù)分發(fā)服務(wù)的終端應(yīng)用，即為發(fā)布端或訂閱端，圖中包括3個(gè)子網(wǎng)、3個(gè)網(wǎng)關(guān)和一個(gè)SDN控制器。具體流程如下：

步驟1：當(dāng)一個(gè)終端應(yīng)用發(fā)起發(fā)布數(shù)據(jù)請(qǐng)求后，該請(qǐng)求被傳輸?shù)紻DS服務(wù)系統(tǒng)中，接著傳到SDN控制器中按照topic進(jìn)行存儲(chǔ)并返回發(fā)布成功消息；

步驟2：當(dāng)有訂閱端發(fā)起訂閱請(qǐng)求后，該請(qǐng)求也同樣被DDS服務(wù)系統(tǒng)傳到控制器中，控制器按主題查找是否有需求的主題已經(jīng)被注冊(cè)，如果沒有則給訂閱端發(fā)送訂閱失敗消息，如果有則返回訂閱成功消息；

步驟3：DDS系統(tǒng)分析訂閱端的QoS需求，并將該QoS信息傳送到SDN控制器，控制器進(jìn)行存儲(chǔ)分析，調(diào)用相關(guān)的拓?fù)湫畔?、QoS功能和負(fù)載均衡功 能計(jì)算出最優(yōu)的路由路徑；

步驟4：控制器將最優(yōu)的路由路徑信息轉(zhuǎn)化為各個(gè)相關(guān)設(shè)備的流表信息，然后下發(fā)到各個(gè)設(shè)備中，終端設(shè)備按照流量執(zhí)行信息轉(zhuǎn)發(fā)，就實(shí)現(xiàn)了符合QoS需求的數(shù)據(jù)實(shí)時(shí)分發(fā)系統(tǒng)。

SDN控制器處理業(yè)務(wù)流程主要分三部分，包括監(jiān)測(cè)、規(guī)劃和執(zhí)行，處理流程框圖如圖4所示?？刂破鲗?duì)網(wǎng)絡(luò)狀態(tài)進(jìn)行實(shí)時(shí)監(jiān)測(cè)，當(dāng)收到網(wǎng)絡(luò)事件后，對(duì)網(wǎng)絡(luò)事件進(jìn)行相應(yīng)的處理，然后判斷網(wǎng)絡(luò)環(huán)境是否改變，如果未改變則繼續(xù)處理網(wǎng)絡(luò)事件，如果改變了則建立新的Openflow環(huán)境，判斷網(wǎng)絡(luò)資源是否是最優(yōu)化的分配方案，如果是則將變化應(yīng)用到網(wǎng)絡(luò)中，如果否則重新建立新的Openflow環(huán)境，重新判斷是否是最優(yōu)化資源分配。當(dāng)控制器收到DDS QoS事件后，首先建立DDS QoS約束，然后判斷網(wǎng)絡(luò)約束是否改變了，沒有改變則重新建立DDS QoS約束，直到發(fā)生改變后，建立新的Openflow環(huán)境，然后接著判斷網(wǎng)絡(luò)資源是否是最優(yōu)的，最優(yōu)則執(zhí)行變化操作，否則重新建立Openflow環(huán)境，這與處理網(wǎng)絡(luò)事件的流程一致。

基于Openflow協(xié)議的控制器對(duì)數(shù)據(jù)流的QoS控制，主要通過Meter表機(jī)制實(shí)現(xiàn)，但是Meter表本身能夠?qū)崿F(xiàn)的QoS功能不多，因此需要對(duì)Meter表進(jìn)行擴(kuò)展，并與queue支持的set-queue action相互結(jié)合實(shí)現(xiàn)復(fù)雜的QoS需求。數(shù)據(jù)流的處理流程示意圖如圖5所示。當(dāng)DDS代理將事件傳送到控制器后，F(xiàn)low_in_event事件首先進(jìn)入QoS存儲(chǔ)模塊，對(duì)QoS指標(biāo)進(jìn)行存儲(chǔ)，便于后續(xù)資源分析模塊對(duì)整個(gè)網(wǎng)絡(luò)資源進(jìn)行分析，然后針對(duì)QoS需求進(jìn)行實(shí)時(shí)業(yè)務(wù)路由計(jì)算，獲得實(shí)時(shí)路由路徑，然后對(duì)網(wǎng)絡(luò)資源的利用率進(jìn)行評(píng)估，如果當(dāng)前資源利用率最優(yōu)則將QoS配置轉(zhuǎn)發(fā)為流表下發(fā)到下層網(wǎng)絡(luò)設(shè)備，如果不是最優(yōu)，則返回資源分析模塊重新計(jì)算實(shí)時(shí)路徑，直到獲得最優(yōu)鏈路資源為止。