CMACast流媒体广域网转播方案的设计
2022-07-16周帆曾继荣缪星宇万占蠢郭海峰
周帆 曾继荣 缪星宇 万占蠢 郭海峰
摘要:为解决在CMACast卫星广播系统中,气象流媒体组播数据在局域网转发时存在的高带宽占用,以及无法转发到其他局域网或广域网的问题。本论述通过合理划分和配置VLAN 并使用QoS 技术,达到降低带宽占用、保障网络流畅传输的目的。另外,通过设计开发组播代理软件,利用组播技术,解决组播数据只能在本地局域网转发的问题,实现更灵活、可靠的网络架构设计,验证了可以用最小的带宽占用和系统资源,实现CMACast流媒体数据跨网段传输的可行性。
关键词:通信网络;CMACast转播;广播风暴;组播代理;流媒体转播
中图分类号:TP393.07文献标志码:A
0 引言
目前CMACast(China Meteorological Administration Cast,中国气象局卫星广播)系统下发的流媒体数据主要有两种,一种是气象频道,另外一种是全国天气会商的实时转播,只有同 VLAN(Virtual Local Area Network,虚拟局域网)的计算机能够收看CMACast接收机以组播方式轉播的气象频道和全国天气会商的实时画面[1]。组播在局域网中会以广播的方式转发数据造成广播风暴,严重影响局域网性能。但如果将CMACast接收机与业务机划分在不同的 VLAN 中,业务机又无法收看流媒体画面。经过与中国局相关技术人员沟通也没有得出有效的解决方案,因此需要分析问题原因,研究设计一套可行的CMACast流媒体广域网转播方案。
1 背景及需求
1.1 背景
各级气象部门通过CMACast卫星小站接收流媒体数据,如图1 所示。为使气象台业务机能够顺利调取资料、观看全国天气会商,一般CMACast接收机与气象台业务机会划分在同一个 VLAN 中。正因此,我局曾出现过因CMACast流媒体广播风暴导致局域网瘫痪的先例,这种情况在全国其他的气象部门都有发生。
省气象局发文明确要求各级气象部门在汛期收看CMACast全国天气会商,但因CMACast系统维护成本大、县局技术力量欠缺、气象数据集约化要求,该系统在许多县局已停止运行,在现有技术条件下,无法满足省局的要求。
1.2 需求
对于技术能力较强的省、市级气象部门,需要解决CMACast接收机广播风暴问题,提升局域网性能。对于技术力量较弱县级气象部门,需要在现有网络架构下不增加额外成本解决县局收看全国天气会商的需求。
2 目标、内容及难点分析
2.1 目标
从先进性、实用性、可靠性、扩展性、低成本等方面着手,综合系统性能等多方面因素,在不影响其他核心业务(如自动站数据实时传输、全省天气会商系统、实时资料调取等)的前提下,使用最小的带宽、最小的系统资源消耗以及可控的流量实现CMACast流媒体数据跨网段流畅传输,是本方案的主要设计目标。
2.2 内容
该方案从网络架构、组播代理到流量控制3 方面着手,设计内容如下:
(1) 优化现有网络结构,将CMACast接收服务器与气象台局域网划分到不同的 VLAN 中[2-3],以实现 CMA⁃ Cast 接收服务器与气象台业务网络的逻辑隔离,从而减少广播对网络带宽的占用,提高网络传输效率,同时防止因局域网爆发广播风暴而导致服务器无法访问的风险。
(2) 利用组播技术解决CMACast流媒体数据的跨网段传输问题[4],实现全国天气会商、气象频道向市县广域网及其他 VLAN 的实时转播。
(3)利用 QoS(Quality of Service,服务质量)技术提高CMACast流媒体数据的转发质量[5],提升视频画面的流畅度和清晰度,并且防止组播数据占用大量带宽从而影响其他正常业务数据的传输。
2.3 难点分析
(1) 在组播网络配置之前,根据现有条件从先进性、实用性、可靠性、扩展性、低成本等方面做好组播数据网络的架构设计,是实现组播数据广域网转发的基础。
(2) 在测试中发现CMACast组播数据默认 TTL ( Time To Live,生存时间值)值为1,也就是说组播数据只能在局域网中传播,不能跨网段传输,修改CMACast流媒体数据流的 TTL 值是该方案的一个难点。
(3)组播属于点到多点的传输,如果设计不当,极易出现整个广域网组播数据流的泛滥,这将极大影响其他业务的数据传输,因此合理的针对组播数据进行流量控制,使用最小的带宽、最小的系统资源消耗以及可控的流量来实现CMACast流媒体数据跨网段的流畅传输也是本方案设计的难点之一。
3 技术方法介绍
3.1 组播技术
组播是将信息发送给多个有接收需求的主机而非所有主机,其基本思想是:源主机只发送一份数据,其目的地址为组播组地址。组播组中的所有接收者都可收到同样的数据拷贝,并且只有组播组内的主机可以接收该数据。组播技术有效地解决了单点发送、多点接收的问题,实现了 IP (Internet Protocol,网际互连协议)网络中点到多点的高效数据传送,能够大量节约网络带宽、降低网络负载。
组播协议主要包含主机和路由器之间的协议,路由器和路由器之间的协议,以及组播域之间的协议。考虑到兼容性以及应用扩展,本方案使用目前应用广泛的协议技术,组播组管理协议使用 IGMP(Internet Group Management Protocol,Internet 组管理协议),组播路由协议使用 PIM (Protocal Independent Multicast,无协议组播)。
3.2 QoS技术
在通信网络领域,服务质量的衡量标准主要有带宽、延迟、抖动、以及丢包率这四个方面,不同的业务应用对网络服务质量的要求有很大区别,见表1 所列。视频点对于带宽的要求比较高,对网络延迟和抖动很敏感。所有的应用对丢包率的要求都较高,视频应用中过多的丢包会造成图像错位和“马赛克”等多方面的问题。
QoS 就是利用有限的网络资源针对不同的业务应用优化网络转发,利用增加缓冲、对数据包进行压缩、优先转发某些数据流的数据包等方法提升网络服务质量[6]。优先转发某些数据流的数据包是 QoS 一个主要的功能,本方案中针对视频点播需求采用 EF (Expedit⁃ ed Forwarding,加速转发)技术。
4 方案设计实现
4.1 调整优化现有网络结构
如图2 所示,将CMACast接收服务器、CMACast数据服务器、国突系统等对内服务器归类到 VLAN310中,气象台 VLAN30专门用于气象台业务使用,这样就实现了服务器与业务的广播域隔离,气象台业务机内的广播数据不影响服务器带宽的使用,同样,服务器内的广播数据也不影响气象台业务机的使用。
4.2 利用组播技术实现组播数据的广域网转发
在接收者直连的三层接口上启动 IGMP 协议,实现组播组成员的管理,如图 2所示。在 VLAN20、 VLAN40、VLAN50对应的 VLAN 接口上启动 IGMP 协议。然后在核心层(S7506E、S5800)、主干路由器(MSR5660)以及县局的专线路由器以及核心层之间的三层接口上配置 PIM-SM 协议,从而實现组播报文转发路径的构建。
4.3 利用QoS实现组播报文的加速转发以及带宽限制
在本方案中,CMACast多媒体数据主要有两路,一路为气象频道,一路为全国天气会商视频,而全国天气会商视频是双流视频,因此可以说一共有三路组播流数据。在组播数据源到核心交换机的入口处部署 QoS 流量监管[7]、流量重标记限制组播数据流使用带宽和组播数据流的分类标记,在 MSR5660到县局的专线出接口使用 EF 技术。为组播数据流提供低延迟、低抖动、低丢包率的保证带宽的优先转发服务,同时限制组播流量占用过多的网络带宽,从而达到组播流的顺畅播放的同时不影响其他关键性业务的数据传输的目的。4.4 使用组播代理方法实现CMACast组播数据的二次转发
在前期配置调试阶段,遇到了一个比较难解决的问题。路由器及三层交换机均已正确配置,PIM- SM(Protocol- independent multicast sparse mode,协议无关组播稀疏模式)、IGMP 等协议都已启用,但是CMACast流媒体数据始终收不到,这是因为组播默认的 TTL 值为 1。数据每次经过路由器时 TTL 值都会减1,减到0 时这个报文就被丢弃了。这就是组播数据不能在广域网传播的原因。
解决方法有两种:一种是修改CMACast接收软件,将 TTL 值改大。但这需要和CMACast接收机软件开发商联系,协商修改源程序,这种很难实现。因此我们采用第二种,自主开发一套组播代理软件,将从CMACast接收到的流媒体数据修改其 TTL 值以及组播组、端口号等信息后再进行二次组播转发,如图3 所示。
5 验证
5.1 测试环境说明
组播源服务器 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组播路由对应的出接口为Vlan-inter⁃ face4,该接口下连县局 MSR3640路由器。在县局MSR3640路由器(PL_LT_XianJu_MSR3640)查看组播路由表,如图4 (b)所示。发现气象频道组播数据出接口为 GE0/2.20,GE0/2.20与 PC3直连,说明组播数据已转发至 PC3。
5.3 验证组播代理功能
在图3 自主开发的组播代理工具的界面中,设置 TTL 值为8 。那么在到达 PC3时TTL 应该会变为3,因为从组播源 S1到 PC3经过的路由器为:S1—— S7506E——MSR5660——灵台县站 MSR3640——灵台县站 S5660——灵台县局 MSR3640——PC3,共经过5 个路由器。抓取 PC3上的数据包发现,如图5 所示, TTL 值变为3 。因此,利用组播代理工具实现了 TTL 值得修改以及组播数据的二次转发。
5.4 验证QoS对组播流量的控制
在 MSR5660去往各县局的出接口处配置了 QoS 的 EF策略,配置及运行情况如图6所示,从图中红色框中可以看到组播流的转发速率为1.8 Mbps,而配置的EF CIR 平均带宽为4 Mbps,能够达到组播数据的流畅转发。
通过以上测试,组播转发、流量控制等功能都已经完全实现,CMACast流媒体数据不仅得到精准转发,而且使得组播流量变得可控,不仅阻止了组播流量过大的问题,还对组播流量进行了加速转发,有效的解决了流媒体数据对网络延迟、抖动敏感的问题。
6 结论
该方案利用了最小的带宽、最小的系统资源消耗以及可控的流量,在不影响其他核心业务传输性能的前提下,实现了CMACast流媒体数据跨网段的流畅传输。解决了县局无法实时观看全国天气会商的难题,以及因气象台网络结构优化后导致CMACast流媒体数据无法收看的问题,为市县气象服务提供了有力的保障。
但是在测试的过程中因为条件所限,只选择了一个县局进行了测试,没能测试六县一区同时接收 CMA⁃ Cast 流媒体数据时流媒体数据是否能够流畅播放,这需要在今后业务应用过程中再进行测试,若出现流媒体播放不流畅的问题,只需重新修改 QoS 策略中的参数即可解决。
参考文献:
[1]董如根,杜世烨,孙雪丽. 局域网CMACast流媒体数据的正常播控[J]. 软件导刊,2011,10(10):114-115.
[2]杭州华三通信技术有限公司. 路由交换技术:第3 卷[M].北京:清华大学出版社,2012.
[3]杭州华三通信技术有限公司. 路由交换技术:第4 卷[M].北京:清华大学出版社,2012.
[4]刘玄. 组播路由控制与转发分离机制的设计与实现[D]. 北京:北京邮电大学,2018.
[5]孟学军,于红增,郭巍,等. 基于区分服务的专用 IP 网 QoS部署策略设计[J]. 计算机与网络,2020,46(17):66-69.
[6]汤萍萍. QoS 感知的网络流分类和聚集方法研究[D]. 南京:南京邮电大学,2021.
[7]赵政权. 面向服务的端到端 QoS 路由策略研究[D]. 北京:北京邮电大学,2021.