SDN網(wǎng)絡(luò)IPv6組播機(jī)制研究*

李 丹，秦 華

（北京工業(yè)大學(xué)信息學(xué)部，北京 100124）

0 引 言

近年來，隨著互聯(lián)網(wǎng)的迅猛發(fā)展，諸如視頻直播、網(wǎng)絡(luò)教學(xué)等實(shí)時(shí)業(yè)務(wù)廣泛應(yīng)用，多個(gè)接收者需要同時(shí)從一個(gè)或多個(gè)源節(jié)點(diǎn)接收相同的流媒體數(shù)據(jù)，致使網(wǎng)絡(luò)傳輸?shù)男畔⑷萘看蟠笤黾?，占用了大量的網(wǎng)絡(luò)帶寬。針對(duì)這樣的應(yīng)用需求，傳統(tǒng)的點(diǎn)播技術(shù)不僅對(duì)源節(jié)點(diǎn)資源和網(wǎng)絡(luò)帶寬的消耗很大，而且限制了用戶數(shù)量的擴(kuò)展。比較而言，組播是一個(gè)更好的傳輸方案。但是，傳統(tǒng)網(wǎng)絡(luò)中，路由器需要預(yù)先配置，然后才可以動(dòng)態(tài)支持組播訂閱者的加入操作、離開操作和組播樹的生成操作。針對(duì)組播流量對(duì)帶寬的需求未動(dòng)態(tài)選擇傳輸路徑，很容易造成鏈路擁塞，不能夠?yàn)橛脩籼峁┹^好的服務(wù)質(zhì)量。以O(shè)penFlow技術(shù)為核心的軟件定義網(wǎng)絡(luò)框架，具有集中控制的功能[1-2]，能夠自己感知網(wǎng)絡(luò)拓?fù)涞淖兓?，為IPv6組播實(shí)現(xiàn)提供好的解決方案。

文獻(xiàn)[3]提出了一種在IPv4網(wǎng)絡(luò)下基于SDN分層組播的視頻會(huì)議系統(tǒng)架構(gòu)。該系統(tǒng)舍棄了傳統(tǒng)的互聯(lián)網(wǎng)組管理協(xié)議（IGMP）和多點(diǎn)控制單元（MCU）硬件設(shè)備，結(jié)合可伸縮視頻編碼（SVC）實(shí)現(xiàn)分層視頻組播，以滿足不同設(shè)備能力的會(huì)議終端需求，用視頻層數(shù)之間的切換來避免擁塞。

文獻(xiàn)[4]在IPv4網(wǎng)絡(luò)下從控制器的安全性出發(fā)，設(shè)計(jì)了一種基于OpenFlow的可信可控的組播控制器。組播控制器通過OpenFlow交換機(jī)連接到身份認(rèn)證的主機(jī)，組播控制器制定并下發(fā)流表給OpenFlow交換機(jī)，實(shí)現(xiàn)將組播數(shù)據(jù)傳輸?shù)酵ㄟ^身份認(rèn)證的主機(jī)?；诮M播接收者的身份認(rèn)證，實(shí)現(xiàn)了組播接收者的可信；組播在組播組成員管理時(shí)，使用可信可控的組播控制器進(jìn)行集中管理，沒有使用傳統(tǒng)的IGMP協(xié)議。

文獻(xiàn)[5]提出了一種基于IPv4的新型組播機(jī)制OpenFlow，稱為OpenFLow組播（OFM）。在控制器中設(shè)計(jì)了一個(gè)集中控制器負(fù)責(zé)實(shí)現(xiàn)組播，負(fù)責(zé)處理組播訂閱者請(qǐng)求、構(gòu)造組播樹以及組播狀態(tài)維護(hù)。交換機(jī)根據(jù)生成的組播流表轉(zhuǎn)發(fā)組播流量，沒有考慮帶寬擁塞的需求。

文獻(xiàn)[6]采用TCAM為交換機(jī)細(xì)粒度流量控制提供了較大的存儲(chǔ)空間，并采用分段路由解決流量工程中的可擴(kuò)展問題。通過在組播源端交換機(jī)和分支交換機(jī)上用包頭編碼MPLS標(biāo)簽來更改包頭，配置有序列表段來表明路由路徑，并考慮了交換節(jié)點(diǎn)的負(fù)載情況，但TCAM非常昂貴且能耗高。它用斯坦納樹構(gòu)造組播生成樹，但沒有考慮到組成員加入、離開的動(dòng)態(tài)性。

本文在SDN網(wǎng)絡(luò)中研究IPv6組播實(shí)現(xiàn)技術(shù)，在保證協(xié)議棧（MLD）[7]不變的前提下，對(duì)組播訂閱者加入和離開進(jìn)行感知和維護(hù)；可根據(jù)組播流量需求，考慮在網(wǎng)絡(luò)帶寬負(fù)載情況下，根據(jù)組播訂閱者加入/離開組播組的動(dòng)態(tài)次序構(gòu)建組播生成樹；對(duì)組播轉(zhuǎn)發(fā)路徑進(jìn)行動(dòng)態(tài)調(diào)整，實(shí)現(xiàn)組播業(yè)務(wù)的有效轉(zhuǎn)發(fā)。

1 總體思路

1.1 傳統(tǒng)網(wǎng)絡(luò)與SDN網(wǎng)絡(luò)實(shí)現(xiàn)對(duì)比

SDN將分布式路由轉(zhuǎn)換為集中式路徑選擇，其控制器具有主導(dǎo)網(wǎng)絡(luò)資源管理和流量控制的能力，能夠?qū)崿F(xiàn)更靈活、細(xì)粒度的流量調(diào)度管理。傳統(tǒng)網(wǎng)絡(luò)與SDN網(wǎng)絡(luò)實(shí)現(xiàn)組播功能方式的對(duì)比，如表1所示。

表1 傳統(tǒng)網(wǎng)絡(luò)與SDN網(wǎng)絡(luò)實(shí)現(xiàn)對(duì)比

1.2 SDN網(wǎng)絡(luò)下功能性需求

組成員管理功能。在SDN網(wǎng)絡(luò)中，組播訂閱者將MLD報(bào)文發(fā)送給組成員管理功能進(jìn)行處理。該功能對(duì)組播訂閱者的加入、離開消息進(jìn)行維護(hù)。即需要感知組播訂閱者的加入，同步在組播拓?fù)渲性黾釉摮蓡T并維護(hù)網(wǎng)絡(luò)拓?fù)?，同時(shí)離開后在拓?fù)渲袆h除該成員并維護(hù)網(wǎng)絡(luò)拓?fù)洹?/p>

組播拓?fù)渚S護(hù)功能。與SDN控制器一起，維護(hù)整個(gè)網(wǎng)絡(luò)實(shí)時(shí)的網(wǎng)絡(luò)拓?fù)湫畔?，包括交換機(jī)的加入、離開、改變、交換機(jī)端口的變化和新增鏈路的實(shí)時(shí)帶寬信息。

組播選路功能。根據(jù)組播拓?fù)渚S護(hù)功能，維護(hù)網(wǎng)絡(luò)拓?fù)湫畔?、?shí)時(shí)可用帶寬信息和組成員管理功能維護(hù)的組播訂閱者信息。為每個(gè)新加入（S，G）組的交換機(jī)節(jié)點(diǎn)（S2）找到距離轉(zhuǎn)發(fā)組播流量交換機(jī)（S1）的最短路徑。如果有多條路徑，選擇路徑帶寬之和較大的路徑。

2 SDN網(wǎng)絡(luò)下IPv6組播功能的設(shè)計(jì)

基于IPv6組播的RFC標(biāo)準(zhǔn)，在保證組播訂閱者M(jìn)LD協(xié)議棧不變的前提下，依據(jù)SDN控制器具有動(dòng)態(tài)、可管理和可配置的特性，提出了SDN網(wǎng)絡(luò)下Ipv6組播功能的設(shè)計(jì)，如圖1所示。

SDN網(wǎng)絡(luò)中，實(shí)現(xiàn)IPv6組播需要設(shè)計(jì)3個(gè)功能：組成員管理、組播拓?fù)渚S護(hù)和組播選路。圖1是整體功能設(shè)計(jì)圖。整體架構(gòu)主要有3部分組成：控制器應(yīng)用層、控制器控制層和物理拓?fù)鋵印?/p>

控制器應(yīng)用層是ONOS控制器中的應(yīng)用APP，開發(fā)者可以自定義實(shí)現(xiàn)一個(gè)或多個(gè)APP來完成自己的應(yīng)用需求。本文針對(duì)單播源組播應(yīng)用場(chǎng)景，在應(yīng)用層上實(shí)現(xiàn)組成員管理、組播拓?fù)渚S護(hù)和組播選路3個(gè)功能。

控制器控制層由下往上包含協(xié)議層、適配器層、南向接口層、核心層和北向接口層。它通過OpenFlow協(xié)議接收物理拓?fù)涞刃畔?，并抽象給應(yīng)用層。

物理拓?fù)鋵邮怯山粨Q機(jī)通過鏈路連接成的網(wǎng)絡(luò)拓?fù)?。在?shí)驗(yàn)環(huán)境中，可以通過Mininet模擬器模擬實(shí)現(xiàn)。

2.1 組成員管理功能

組成員管理功能管理組播訂閱者的加入和離開消息，負(fù)責(zé)處理訂閱者發(fā)來的MLD數(shù)據(jù)報(bào)文，維護(hù)訂閱者列表HSL（主機(jī)交換機(jī)連接）表，如表2所示。

圖1 SDN網(wǎng)絡(luò)下IPv6組播的整體架構(gòu)設(shè)計(jì)

表2 HSL表

處理過程的流程，如圖2所示。對(duì)于加入組播組的報(bào)文，根據(jù)訂閱者加入的組播組地址，在HSL表中新增一條記錄，記錄下組播源地址、組播組地址以及控制器存儲(chǔ)的主機(jī)的IP地址、MAC地址、所連交換機(jī)的地址，端口信息在HSL表中添加一條記錄。對(duì)于離開組播組的報(bào)文，在HSL表中刪除一條記錄。

2.2 組播拓?fù)渚S護(hù)功能

SDN控制器通過LLDP協(xié)議與交換機(jī)通信獲得整個(gè)網(wǎng)絡(luò)信息，包括網(wǎng)絡(luò)拓?fù)?、鏈路延遲等。網(wǎng)絡(luò)管理和決策必須獲得準(zhǔn)確的網(wǎng)絡(luò)監(jiān)測(cè)數(shù)據(jù)?？刂破骺梢灾芷谛缘叵蚪粨Q機(jī)發(fā)送查詢消息，也可以由觸發(fā)條件觸發(fā)控制器發(fā)送查詢消息。本文采用第二種方式。

鏈路帶寬是進(jìn)行組播選路的重要決策數(shù)據(jù)，同樣可以通過南向接口的OpenFlow協(xié)議獲取。在OpenFlow協(xié)議中，控制器通過發(fā)送OFPT_STATS_REQUEST消息向交換機(jī)查詢端口的統(tǒng)計(jì)信息，包括已接收的字節(jié)數(shù)（g_bytes）、已發(fā)送的字節(jié)數(shù)（f_bytes）?？刂破靼凑帐剑?）計(jì)算鏈路的吞吐量BT，再根據(jù)該鏈路的總帶寬和當(dāng)前周期T計(jì)算鏈路已使用的帶寬，然后按照式（2）即可計(jì)算出該端口直連鏈路的可用帶寬B_available。

圖2 訂閱者加入/離開組播組流程

組播拓?fù)渚S護(hù)功能利用SDN控制器周期性地發(fā)送OFPT_STATS_REQUEST消息，獲取各個(gè)時(shí)刻的可用帶寬信息。當(dāng)有組成員加入時(shí)，組播拓?fù)涔δ芡ㄖ刂破饔|發(fā)OFPT_STATS_REQUEST，實(shí)時(shí)獲取各鏈路當(dāng)前的可用帶寬值，為新加入的訂閱者選擇組播路徑提供必要的信息。

網(wǎng)絡(luò)交換機(jī)表示為拓?fù)鋱D中的頂點(diǎn)，如（S1，S2，S3，S4…）。每個(gè)頂點(diǎn)相連的邊表示連接關(guān)系。網(wǎng)絡(luò)拓?fù)渲杏涗浗粨Q機(jī)互聯(lián)關(guān)系、互聯(lián)端口以及互聯(lián)鏈路的可用帶寬。圖1中的網(wǎng)絡(luò)拓?fù)淇梢员硎緸槿绫?所示。

表3 SL表

2.3 組播選路功能

根據(jù)組播訂閱者的動(dòng)態(tài)加入、離開消息，組成員管理功能維護(hù)HSL表。該表中的交換機(jī)是需要轉(zhuǎn)發(fā)組播流量的交換機(jī)。由SL表中信息可知，組播拓?fù)渚S護(hù)功能已經(jīng)維護(hù)了整個(gè)網(wǎng)絡(luò)拓?fù)浜玩溌分g的實(shí)時(shí)帶寬。以上2張表為組播選路提供了選路依據(jù)，根據(jù)組成員管理功能和組播拓?fù)渚S護(hù)功能維護(hù)的表信息，可以選取合適的算法生成組播轉(zhuǎn)發(fā)樹。在進(jìn)行組播算法選取時(shí)，必須考慮組播通信的擴(kuò)展性問題。為了解決網(wǎng)絡(luò)的鏈路擁塞，最小化網(wǎng)絡(luò)資源利用，解決SDN中組播的可擴(kuò)展性問題，本文提出了根據(jù)組播流量可用帶寬需求選取的最短路徑，對(duì)選擇好的路徑制定轉(zhuǎn)發(fā)規(guī)則，通知控制層對(duì)接收組播流量的交換機(jī)進(jìn)行流表下發(fā)的操作。轉(zhuǎn)發(fā)組播流量的交換機(jī)以Gswitch字段描述存儲(chǔ)在表GSL中。該表維護(hù)了一個(gè)（S，G）組的所有轉(zhuǎn)發(fā)組播流量的交換機(jī)。0001、0002、0003、0004分別代表圖1中的交換機(jī)S1、S2、S3、S4。根據(jù)組播訂閱者加入/離開時(shí)的動(dòng)態(tài)行為，同步添加/刪除所需的交換機(jī)到相應(yīng)的（S，G）組的交換機(jī)集合中。如果一個(gè)（S，G）組對(duì)應(yīng)的交換機(jī)集合中沒有交換機(jī)存在，則表示該（S，G）組沒有訂閱者接收組播流量，可以下發(fā)優(yōu)先級(jí)較高的流表使組播轉(zhuǎn)發(fā)表失效。

表4 GSL表

2.3.1 算法思想

一個(gè)網(wǎng)絡(luò)可以用加權(quán)圖G=(V,E)表示，如圖3示。V表示節(jié)點(diǎn)集合，即交換機(jī)節(jié)點(diǎn)；E(S,t)表示鏈路集合，權(quán)值表示為從源節(jié)點(diǎn)S到組播訂閱者t節(jié)點(diǎn)路徑的可用帶寬，即圖3中的數(shù)字表示。圖3的網(wǎng)絡(luò)示例圖是單播網(wǎng)絡(luò)拓?fù)鋱D。組播生成樹的建立以單播鏈路信息為依據(jù)進(jìn)行組播的選路。S節(jié)點(diǎn)為源端節(jié)點(diǎn)，組播樹的生成與組成員的加入次序有關(guān)，不同的加入次序會(huì)生成不同的組播生成樹。但是，組播路徑選擇的算法不變。根據(jù)組播流量需求帶寬，對(duì)鏈路的帶寬進(jìn)行升序排序，在保證整個(gè)網(wǎng)絡(luò)連通的情況下，依次刪除帶寬最小的路徑，根據(jù)帶寬選取網(wǎng)絡(luò)，如圖4所示。為每一個(gè)加入組播樹的節(jié)點(diǎn)（d1）選擇一個(gè)離轉(zhuǎn)發(fā)組播流量交換機(jī)節(jié)點(diǎn)（ds1）的最短路徑，即以d1為選擇點(diǎn)，找到距離ds1的最短路徑。如果有多條路徑，則選擇路徑帶寬總和較大的路徑。

圖3 示例網(wǎng)絡(luò)

圖4 滿足帶寬約束的單播路由網(wǎng)絡(luò)

2.3.2 算法步驟

步驟1：初始時(shí)，X只包含源點(diǎn)，即X={S}。Y包含除S外的其他頂點(diǎn)，即Y={其余頂點(diǎn)}。X集合和Y集合中節(jié)點(diǎn)之間的可用帶寬，在某一個(gè)時(shí)間是固定的。根據(jù)組播流量需求，提供組播路徑選擇的依據(jù)。

步驟2：當(dāng)Y中的第一個(gè)節(jié)點(diǎn)（d1）加入組播樹時(shí)，為節(jié)點(diǎn)d1選擇一個(gè)離組播源S的最短路徑。如果路徑有多條，則選擇帶寬總和較大的路徑。

步驟3：當(dāng)Y中的其他節(jié)點(diǎn)（d2）加入組播樹時(shí)，為該節(jié)點(diǎn)選擇一個(gè)離轉(zhuǎn)發(fā)組播流量交換機(jī)節(jié)點(diǎn)（除組播源節(jié)點(diǎn)）的最短路徑。如果路徑有多條，則選擇帶寬總和較大的路徑。

步驟4：重復(fù)步驟3，直到所有節(jié)點(diǎn)都加入組播樹。

步驟5：當(dāng)Y中的最后一個(gè)節(jié)點(diǎn)離開組播樹時(shí)，意味組播網(wǎng)絡(luò)中已不存在組播訂閱者，則并行下發(fā)流表，刪除轉(zhuǎn)發(fā)組播流量的交換機(jī)中的轉(zhuǎn)發(fā)表（根據(jù)流表的優(yōu)先級(jí)）。

算法的節(jié)點(diǎn)選擇結(jié)果，如表5所示。根據(jù)節(jié)點(diǎn)加入的次序I、A、B、C、D、E、L、G、H、K、F、J，依據(jù)圖4的路由網(wǎng)絡(luò)，生成組播樹。

依據(jù)算法，根據(jù)加入的節(jié)點(diǎn)次序，生成的組播樹如圖5所示，組播源端只發(fā)送一份流量。

表5 不同節(jié)點(diǎn)加入組播樹的過程

圖5 組播樹生成示例

3 實(shí)驗(yàn)驗(yàn)證

在mininet模擬器[8]環(huán)境下構(gòu)建網(wǎng)絡(luò)拓?fù)鋱D，連接到onos控制器上，并把源端和組播訂閱者的IPv4地址改為IPv6地址，如圖6所示。

在mininet模擬器中通過xterm命令開啟3個(gè)主機(jī)。h1為源端，發(fā)送組播流量；h2、h3為組播訂閱者，接收組播流量。用python命令運(yùn)行發(fā)送和接收組播流量的程序，實(shí)驗(yàn)結(jié)果如圖7所示。其中，h2、h3同一時(shí)刻能收到相同的數(shù)據(jù)。

圖6 實(shí)驗(yàn)網(wǎng)絡(luò)拓?fù)?/p>

圖7 組播實(shí)驗(yàn)結(jié)果

4 結(jié) 語

本文基于傳統(tǒng)網(wǎng)絡(luò)下的IPv6組播思想，利用SDN靈活控制的思路，提出了在SDN控制器下實(shí)現(xiàn)IPv6組播的方案，并結(jié)合鏈路帶寬，提供可保證服務(wù)質(zhì)量的組播路徑選擇，但是沒有考慮時(shí)延、時(shí)延抖動(dòng)等因素，可以作為未來的研究內(nèi)容。

參考文獻(xiàn)：

[1] 左青云,陳鳴,趙廣松.基于OpenFlow的SDN技術(shù)研究 [J].軟件學(xué)報(bào) ,2013,24(05)：1078-1097.ZUO Qing-yun,CHEN Ming,ZHAO Guang-song.Research on SDN Technology Based on OpenFlow[J].Journal of Software,2013,24(05)：1078-1097.

[2] 王亞昕,陳量,康宗緒.用SDN改造GoogleWAN網(wǎng)絡(luò)-GoogleB4網(wǎng)絡(luò)項(xiàng)目研究[J].通信技術(shù) ,2015,48(12)：1432-1436.WANG Ya-xin,CHEN Liang,KANG Zong-xu.Research on the Transformation of Google WAN Network with SDN-Google B4 Network Project[J].Communications Tec hnology,2015,48(12)：1432-1436.

[3] 張琳凱,楊恩眾,姚振.SDN分層組播視頻會(huì)議系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].小型微型計(jì)算機(jī)系統(tǒng) ,2017,38(03)：425-430.ZHANG Lin-kai,YANG En-zhong,YAO Zhen.Design and Implementation of SDN Layered Multicast Video Conference System[J].Miniature Microcomputer Systems,2017,38(03)：425-430.

[4] 田金川,蘭少華,卜祥賀.一種基于OpenFlow的可信可控組播控制器：中國,CN103825828A[P].2014-05-28.TIAN Jin-chuan,LAN Shao-hua,BU Xiang-he A Trusted Controllable Multicast Controller Based on OpenFlow：Ch ina,CN103825828A[P].2014-05-28.

[5] Yu Y,Zhen Q,Xin L,et al.OFM：A Novel Multicast Mechanism Based on OpenFlow[J].Advances in Information Sciences & Service Sciences,2012,9(04)：278-286..

[6] Huang L,Hung H,Lin C,et al.Scalable Steiner Tree for Multicast Communications in Software-Defined Networking[C].Computing Research Repository(CoRR),2014.

[7] 朱秀峰,錢華林,柴政.MLD協(xié)議與PIM-SM協(xié)議實(shí)現(xiàn)IPv6組播[J].微電子學(xué)與計(jì)算機(jī),2005,22(06)：206-209.ZHU Xiu-feng,QIAN Hua-lin,CHAI Zheng.Implementing IPv6 Multicast with MLD Protocol and PIM-SM Protocol[J].Microelectronics &Computer,2005,22(06)：206-209.

[8] Kaur K,Singh J,Ghumman N S.Mininet as Software Defined Networking Testing Platform[C].International Conference on Communiction,Computing &Systems,2014.