CMACast流媒體廣域網(wǎng)轉(zhuǎn)播方案的設(shè)計

周帆　曾繼榮　繆星宇　萬占蠢　郭海峰

摘要：為解決在CMACast衛(wèi)星廣播系統(tǒng)中，氣象流媒體組播數(shù)據(jù)在局域網(wǎng)轉(zhuǎn)發(fā)時存在的高帶寬占用，以及無法轉(zhuǎn)發(fā)到其他局域網(wǎng)或廣域網(wǎng)的問題。本論述通過合理劃分和配置VLAN 并使用QoS 技術(shù)，達到降低帶寬占用、保障網(wǎng)絡(luò)流暢傳輸?shù)哪康?。另外，通過設(shè)計開發(fā)組播代理軟件，利用組播技術(shù)，解決組播數(shù)據(jù)只能在本地局域網(wǎng)轉(zhuǎn)發(fā)的問題，實現(xiàn)更靈活、可靠的網(wǎng)絡(luò)架構(gòu)設(shè)計，驗證了可以用最小的帶寬占用和系統(tǒng)資源，實現(xiàn)CMACast流媒體數(shù)據(jù)跨網(wǎng)段傳輸?shù)目尚行浴?/p>

關(guān)鍵詞：通信網(wǎng)絡(luò);CMACast轉(zhuǎn)播;廣播風(fēng)暴;組播代理;流媒體轉(zhuǎn)播

中圖分類號：TP393.07文獻標(biāo)志碼：A

0 引言

目前CMACast（China Meteorological Administration Cast，中國氣象局衛(wèi)星廣播）系統(tǒng)下發(fā)的流媒體數(shù)據(jù)主要有兩種，一種是氣象頻道，另外一種是全國天氣會商的實時轉(zhuǎn)播，只有同 VLAN（Virtual Local Area Network，虛擬局域網(wǎng)）的計算機能夠收看CMACast接收機以組播方式轉(zhuǎn)播的氣象頻道和全國天氣會商的實時畫面[1]。組播在局域網(wǎng)中會以廣播的方式轉(zhuǎn)發(fā)數(shù)據(jù)造成廣播風(fēng)暴，嚴重影響局域網(wǎng)性能。但如果將CMACast接收機與業(yè)務(wù)機劃分在不同的 VLAN 中，業(yè)務(wù)機又無法收看流媒體畫面。經(jīng)過與中國局相關(guān)技術(shù)人員溝通也沒有得出有效的解決方案，因此需要分析問題原因，研究設(shè)計一套可行的CMACast流媒體廣域網(wǎng)轉(zhuǎn)播方案。

1 背景及需求

1.1 背景

各級氣象部門通過CMACast衛(wèi)星小站接收流媒體數(shù)據(jù)，如圖1 所示。為使氣象臺業(yè)務(wù)機能夠順利調(diào)取資料、觀看全國天氣會商，一般CMACast接收機與氣象臺業(yè)務(wù)機會劃分在同一個 VLAN 中。正因此，我局曾出現(xiàn)過因CMACast流媒體廣播風(fēng)暴導(dǎo)致局域網(wǎng)癱瘓的先例，這種情況在全國其他的氣象部門都有發(fā)生。

省氣象局發(fā)文明確要求各級氣象部門在汛期收看CMACast全國天氣會商，但因CMACast系統(tǒng)維護成本大、縣局技術(shù)力量欠缺、氣象數(shù)據(jù)集約化要求，該系統(tǒng)在許多縣局已停止運行，在現(xiàn)有技術(shù)條件下，無法滿足省局的要求。

1.2 需求

對于技術(shù)能力較強的省、市級氣象部門，需要解決CMACast接收機廣播風(fēng)暴問題，提升局域網(wǎng)性能。對于技術(shù)力量較弱縣級氣象部門，需要在現(xiàn)有網(wǎng)絡(luò)架構(gòu)下不增加額外成本解決縣局收看全國天氣會商的需求。

2 目標(biāo)、內(nèi)容及難點分析

2.1 目標(biāo)

從先進性、實用性、可靠性、擴展性、低成本等方面著手，綜合系統(tǒng)性能等多方面因素，在不影響其他核心業(yè)務(wù)（如自動站數(shù)據(jù)實時傳輸、全省天氣會商系統(tǒng)、實時資料調(diào)取等）的前提下，使用最小的帶寬、最小的系統(tǒng)資源消耗以及可控的流量實現(xiàn)CMACast流媒體數(shù)據(jù)跨網(wǎng)段流暢傳輸，是本方案的主要設(shè)計目標(biāo)。

2.2 內(nèi)容

該方案從網(wǎng)絡(luò)架構(gòu)、組播代理到流量控制3 方面著手，設(shè)計內(nèi)容如下：

（1） 優(yōu)化現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)，將CMACast接收服務(wù)器與氣象臺局域網(wǎng)劃分到不同的 VLAN 中[2-3]，以實現(xiàn) CMA? Cast 接收服務(wù)器與氣象臺業(yè)務(wù)網(wǎng)絡(luò)的邏輯隔離，從而減少廣播對網(wǎng)絡(luò)帶寬的占用，提高網(wǎng)絡(luò)傳輸效率，同時防止因局域網(wǎng)爆發(fā)廣播風(fēng)暴而導(dǎo)致服務(wù)器無法訪問的風(fēng)險。

（2） 利用組播技術(shù)解決CMACast流媒體數(shù)據(jù)的跨網(wǎng)段傳輸問題[4]，實現(xiàn)全國天氣會商、氣象頻道向市縣廣域網(wǎng)及其他 VLAN 的實時轉(zhuǎn)播。

（3）利用 QoS（Quality of Service，服務(wù)質(zhì)量）技術(shù)提高CMACast流媒體數(shù)據(jù)的轉(zhuǎn)發(fā)質(zhì)量[5]，提升視頻畫面的流暢度和清晰度，并且防止組播數(shù)據(jù)占用大量帶寬從而影響其他正常業(yè)務(wù)數(shù)據(jù)的傳輸。

2.3 難點分析

（1） 在組播網(wǎng)絡(luò)配置之前，根據(jù)現(xiàn)有條件從先進性、實用性、可靠性、擴展性、低成本等方面做好組播數(shù)據(jù)網(wǎng)絡(luò)的架構(gòu)設(shè)計，是實現(xiàn)組播數(shù)據(jù)廣域網(wǎng)轉(zhuǎn)發(fā)的基礎(chǔ)。

（2） 在測試中發(fā)現(xiàn)CMACast組播數(shù)據(jù)默認 TTL （ Time To Live，生存時間值）值為1，也就是說組播數(shù)據(jù)只能在局域網(wǎng)中傳播，不能跨網(wǎng)段傳輸，修改CMACast流媒體數(shù)據(jù)流的 TTL 值是該方案的一個難點。

（3）組播屬于點到多點的傳輸，如果設(shè)計不當(dāng)，極易出現(xiàn)整個廣域網(wǎng)組播數(shù)據(jù)流的泛濫，這將極大影響其他業(yè)務(wù)的數(shù)據(jù)傳輸，因此合理的針對組播數(shù)據(jù)進行流量控制，使用最小的帶寬、最小的系統(tǒng)資源消耗以及可控的流量來實現(xiàn)CMACast流媒體數(shù)據(jù)跨網(wǎng)段的流暢傳輸也是本方案設(shè)計的難點之一。

3 技術(shù)方法介紹

3.1 組播技術(shù)

組播是將信息發(fā)送給多個有接收需求的主機而非所有主機，其基本思想是：源主機只發(fā)送一份數(shù)據(jù)，其目的地址為組播組地址。組播組中的所有接收者都可收到同樣的數(shù)據(jù)拷貝，并且只有組播組內(nèi)的主機可以接收該數(shù)據(jù)。組播技術(shù)有效地解決了單點發(fā)送、多點接收的問題，實現(xiàn)了 IP （Internet Protocol，網(wǎng)際互連協(xié)議）網(wǎng)絡(luò)中點到多點的高效數(shù)據(jù)傳送，能夠大量節(jié)約網(wǎng)絡(luò)帶寬、降低網(wǎng)絡(luò)負載。

組播協(xié)議主要包含主機和路由器之間的協(xié)議，路由器和路由器之間的協(xié)議，以及組播域之間的協(xié)議?？紤]到兼容性以及應(yīng)用擴展，本方案使用目前應(yīng)用廣泛的協(xié)議技術(shù)，組播組管理協(xié)議使用 IGMP（Internet Group Management Protocol，Internet 組管理協(xié)議），組播路由協(xié)議使用 PIM （Protocal Independent Multicast，無協(xié)議組播）。

3.2 QoS技術(shù)

在通信網(wǎng)絡(luò)領(lǐng)域，服務(wù)質(zhì)量的衡量標(biāo)準(zhǔn)主要有帶寬、延遲、抖動、以及丟包率這四個方面，不同的業(yè)務(wù)應(yīng)用對網(wǎng)絡(luò)服務(wù)質(zhì)量的要求有很大區(qū)別，見表1 所列。視頻點對于帶寬的要求比較高，對網(wǎng)絡(luò)延遲和抖動很敏感。所有的應(yīng)用對丟包率的要求都較高，視頻應(yīng)用中過多的丟包會造成圖像錯位和“馬賽克”等多方面的問題。

QoS 就是利用有限的網(wǎng)絡(luò)資源針對不同的業(yè)務(wù)應(yīng)用優(yōu)化網(wǎng)絡(luò)轉(zhuǎn)發(fā)，利用增加緩沖、對數(shù)據(jù)包進行壓縮、優(yōu)先轉(zhuǎn)發(fā)某些數(shù)據(jù)流的數(shù)據(jù)包等方法提升網(wǎng)絡(luò)服務(wù)質(zhì)量[6]。優(yōu)先轉(zhuǎn)發(fā)某些數(shù)據(jù)流的數(shù)據(jù)包是 QoS 一個主要的功能，本方案中針對視頻點播需求采用 EF （Expedit? ed Forwarding，加速轉(zhuǎn)發(fā)）技術(shù)。

4 方案設(shè)計實現(xiàn)

4.1 調(diào)整優(yōu)化現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)

如圖2 所示，將CMACast接收服務(wù)器、CMACast數(shù)據(jù)服務(wù)器、國突系統(tǒng)等對內(nèi)服務(wù)器歸類到 VLAN310中，氣象臺 VLAN30專門用于氣象臺業(yè)務(wù)使用，這樣就實現(xiàn)了服務(wù)器與業(yè)務(wù)的廣播域隔離，氣象臺業(yè)務(wù)機內(nèi)的廣播數(shù)據(jù)不影響服務(wù)器帶寬的使用，同樣，服務(wù)器內(nèi)的廣播數(shù)據(jù)也不影響氣象臺業(yè)務(wù)機的使用。

4.2 利用組播技術(shù)實現(xiàn)組播數(shù)據(jù)的廣域網(wǎng)轉(zhuǎn)發(fā)

在接收者直連的三層接口上啟動 IGMP 協(xié)議，實現(xiàn)組播組成員的管理，如圖 2所示。在 VLAN20、 VLAN40、VLAN50對應(yīng)的 VLAN 接口上啟動 IGMP 協(xié)議。然后在核心層（S7506E、S5800）、主干路由器（MSR5660）以及縣局的專線路由器以及核心層之間的三層接口上配置 PIM-SM 協(xié)議，從而實現(xiàn)組播報文轉(zhuǎn)發(fā)路徑的構(gòu)建。

4.3 利用QoS實現(xiàn)組播報文的加速轉(zhuǎn)發(fā)以及帶寬限制

在本方案中，CMACast多媒體數(shù)據(jù)主要有兩路，一路為氣象頻道，一路為全國天氣會商視頻，而全國天氣會商視頻是雙流視頻，因此可以說一共有三路組播流數(shù)據(jù)。在組播數(shù)據(jù)源到核心交換機的入口處部署 QoS 流量監(jiān)管[7]、流量重標(biāo)記限制組播數(shù)據(jù)流使用帶寬和組播數(shù)據(jù)流的分類標(biāo)記，在 MSR5660到縣局的專線出接口使用 EF 技術(shù)。為組播數(shù)據(jù)流提供低延遲、低抖動、低丟包率的保證帶寬的優(yōu)先轉(zhuǎn)發(fā)服務(wù)，同時限制組播流量占用過多的網(wǎng)絡(luò)帶寬，從而達到組播流的順暢播放的同時不影響其他關(guān)鍵性業(yè)務(wù)的數(shù)據(jù)傳輸?shù)哪康摹?.4 使用組播代理方法實現(xiàn)CMACast組播數(shù)據(jù)的二次轉(zhuǎn)發(fā)

在前期配置調(diào)試階段，遇到了一個比較難解決的問題。路由器及三層交換機均已正確配置，PIM- SM（Protocol- independent multicast sparse mode，協(xié)議無關(guān)組播稀疏模式）、IGMP 等協(xié)議都已啟用，但是CMACast流媒體數(shù)據(jù)始終收不到，這是因為組播默認的 TTL 值為 1。數(shù)據(jù)每次經(jīng)過路由器時 TTL 值都會減1，減到0 時這個報文就被丟棄了。這就是組播數(shù)據(jù)不能在廣域網(wǎng)傳播的原因。

解決方法有兩種：一種是修改CMACast接收軟件，將 TTL 值改大。但這需要和CMACast接收機軟件開發(fā)商聯(lián)系，協(xié)商修改源程序，這種很難實現(xiàn)。因此我們采用第二種，自主開發(fā)一套組播代理軟件，將從CMACast接收到的流媒體數(shù)據(jù)修改其 TTL 值以及組播組、端口號等信息后再進行二次組播轉(zhuǎn)發(fā)，如圖3 所示。

5 驗證

5.1 測試環(huán)境說明

組播源服務(wù)器 IP 地址為10.169.206.11（以下簡稱 S1），所在的 VLAN 為 VLAN310，氣象頻道組播組地址為 239.0.1.45，全國天氣會商組播組地址為239.0.1.46。在此次驗證測試中，以靈臺縣局為例，各接收端詳細信息見表3 所列。

5.2 驗證組播功能

在靈臺縣局接收主機（PC3）上啟用 VLC 播放器并打開氣象頻道（udp：//@239.0.1.45：8000），在縣局核心交換機 S5560上查看組播路由表，如圖4 （a）所示。在核心交換機 S5560組播路由對應(yīng)的出接口為Vlan-inter? face4，該接口下連縣局 MSR3640路由器。在縣局MSR3640路由器（PL_LT_XianJu_MSR3640）查看組播路由表，如圖4 （b）所示。發(fā)現(xiàn)氣象頻道組播數(shù)據(jù)出接口為 GE0/2.20，GE0/2.20與 PC3直連，說明組播數(shù)據(jù)已轉(zhuǎn)發(fā)至 PC3。

5.3 驗證組播代理功能

在圖3 自主開發(fā)的組播代理工具的界面中，設(shè)置 TTL 值為8 。那么在到達 PC3時TTL 應(yīng)該會變?yōu)?，因為從組播源 S1到 PC3經(jīng)過的路由器為：S1—— S7506E——MSR5660——靈臺縣站 MSR3640——靈臺縣站 S5660——靈臺縣局 MSR3640——PC3，共經(jīng)過5 個路由器。抓取 PC3上的數(shù)據(jù)包發(fā)現(xiàn)，如圖5 所示， TTL 值變?yōu)? 。因此，利用組播代理工具實現(xiàn)了 TTL 值得修改以及組播數(shù)據(jù)的二次轉(zhuǎn)發(fā)。

5.4 驗證QoS對組播流量的控制

在 MSR5660去往各縣局的出接口處配置了 QoS 的 EF策略，配置及運行情況如圖6所示，從圖中紅色框中可以看到組播流的轉(zhuǎn)發(fā)速率為1.8 Mbps，而配置的EF CIR 平均帶寬為4 Mbps，能夠達到組播數(shù)據(jù)的流暢轉(zhuǎn)發(fā)。

通過以上測試，組播轉(zhuǎn)發(fā)、流量控制等功能都已經(jīng)完全實現(xiàn)，CMACast流媒體數(shù)據(jù)不僅得到精準(zhǔn)轉(zhuǎn)發(fā)，而且使得組播流量變得可控，不僅阻止了組播流量過大的問題，還對組播流量進行了加速轉(zhuǎn)發(fā)，有效的解決了流媒體數(shù)據(jù)對網(wǎng)絡(luò)延遲、抖動敏感的問題。

6 結(jié)論

該方案利用了最小的帶寬、最小的系統(tǒng)資源消耗以及可控的流量，在不影響其他核心業(yè)務(wù)傳輸性能的前提下，實現(xiàn)了CMACast流媒體數(shù)據(jù)跨網(wǎng)段的流暢傳輸。解決了縣局無法實時觀看全國天氣會商的難題，以及因氣象臺網(wǎng)絡(luò)結(jié)構(gòu)優(yōu)化后導(dǎo)致CMACast流媒體數(shù)據(jù)無法收看的問題，為市縣氣象服務(wù)提供了有力的保障。

但是在測試的過程中因為條件所限，只選擇了一個縣局進行了測試，沒能測試六縣一區(qū)同時接收 CMA? Cast 流媒體數(shù)據(jù)時流媒體數(shù)據(jù)是否能夠流暢播放，這需要在今后業(yè)務(wù)應(yīng)用過程中再進行測試，若出現(xiàn)流媒體播放不流暢的問題，只需重新修改 QoS 策略中的參數(shù)即可解決。

參考文獻：

[1]董如根，杜世燁，孫雪麗. 局域網(wǎng)CMACast流媒體數(shù)據(jù)的正常播控[J]. 軟件導(dǎo)刊，2011，10（10）：114-115.

[2]杭州華三通信技術(shù)有限公司. 路由交換技術(shù)：第3 卷[M].北京：清華大學(xué)出版社，2012.

[3]杭州華三通信技術(shù)有限公司. 路由交換技術(shù)：第4 卷[M].北京：清華大學(xué)出版社，2012.

[4]劉玄. 組播路由控制與轉(zhuǎn)發(fā)分離機制的設(shè)計與實現(xiàn)[D]. 北京：北京郵電大學(xué)，2018.

[5]孟學(xué)軍，于紅增，郭巍，等. 基于區(qū)分服務(wù)的專用 IP 網(wǎng) QoS部署策略設(shè)計[J]. 計算機與網(wǎng)絡(luò)，2020，46（17）：66-69.

[6]湯萍萍. QoS 感知的網(wǎng)絡(luò)流分類和聚集方法研究[D]. 南京：南京郵電大學(xué)，2021.

[7]趙政權(quán). 面向服務(wù)的端到端 QoS 路由策略研究[D]. 北京：北京郵電大學(xué)，2021.