IP组播技术范文

IP组播技术范文（精选7篇）

IP组播技术 第1篇

随着信息技术的不断发展,IP网络视频监控系统已经在智能化交通、交通监控等领域得到了充分的应用。IP网络视频监控系统是随着计算机技术、多媒体技术、监控技术有机结合起来的一种全新的监控系统。语音和视频数据在IP网络中传输如果都采用点对点的单播,由于单播技术自身的特点,将产生大量的冗余数据在网络中传输。而且服务器也将由于处理大量的用户访问信息,造成处理能力下降甚至宕机。IP组播技术的出现,解决了这些问题。

2 IP组播

2.1 IP组播技术的产生

传统的IP通信有两种方式:第一种是在一台源IP主机和一台目的IP主机之间进行,即单播(Unicast);第二种是在一台源IP主机和网络中所有其它的IP主机之间进行,即广播(Broadcast)。传统情况下,如果要将数据发送给网络中的多个主机而非所有主机,则要么采用广播方式,要么由源主机分别向网络中的多台目标主机以单播方式发送IP包。采用广播方式实现时,不仅会将数据发送给不需要的主机而浪费带宽,也可能由于路由回环引起严重的广播风暴;采用单播方式实现时,由于IP包的重复发送会白白浪费掉大量带宽,也增加了服务器的负载。所以,传统的单播和广播通信方式不能有效地解决单点发送多点接收的问题。IP组播技术能够很好的解决单点对多点传输数据的问题。

2.2 IP组播及其优缺点

IP组播是指在IP网络中将数据包以尽力传送(Best-Effort)的形式发送到一个构成组播群组的主机集合,这个主机集合是网络中的某个确定节点子集,这个子集称为组播组(MulticastGroup)。组播组的各个成员可以分布于各个独立的物理网络上。IP组播的基本思想是源主机只发送一份数据,这份数据中的目的地址为组播组地址;组播组中的所有接收者都可接收到同样的数据拷贝,并且只有组播组内的主机(目标主机)可以接收该数据,网络中其它主机不能收到。IP组播群组中成员的关系是动态的,主机可以随时加入和退出群组,群组的成员关系决定了主机是否接收送给该群组的组播数据包,不是某群组的成员主机也能向该群组发送组播数据包。

由于网络用户的增多、涉及面扩大,大量的用户经常要在大致相同的时间里访问相同的信息。这种情况下,组播的优势就显现出来了。构建一种具有组播能力的IP网络,允许中间路由器将数据包复制到几个输出接口上,这样一个服务器只需向一组终端用户发送单一流,并利用网络层提供的组播路由功能将数据包传递到每一个加入该组播组的接收者,从本质上减少整个网络带宽的需求,减轻服务器的负担。另外,组播传送的数据能同时到达用户端,延时小,而且网络中的服务器不需要知道每个客户机的地址。所有的接收者使用一个网络组播地址,可实现匿名服务。

与IP组播系统执行程序相关联的主要缺点包括不可靠的数据包交付、数据包复制以及网络阻塞。由于IP组播假定一对多的通信方式,它不使用TCP的端到端的机制。IP组播数据包使用用户数据报协议(UDP)作为传输层协议,不同于TCP,UDP不提供可靠性、流控和错误恢复功能。因此,一个使用IP组播的应用一定会遇到偶然的数据包丢失。组播的可靠性由接收方和网络中的Qos负责管理。

单播和组播之间的关键差别是路由器主动地发送组播数据包的拷贝到多个接口。这增加了多个拷贝的组播数据包到达某一接收点的可能性。如果设计不当,可能会导致关键的控制命令在IP组播数据包被执行多次。就TCP单播来说,标准TCP补偿和慢开启窗口机制自动地调整数据传送的速度,因此在一定程度上避免了网络阻塞。因为IP组播不使用TCP,所以没有内建的阻塞避免机制防止组播流耗尽链路带宽或者其他关键的路由器资源。

2.3 IP组播通信

在组播中,用户按不同的应用分为不同的用户组,组成员要向组播服务器(一般为路由器)注册,用户主机发出请求报文,表明所要加入的组。每个组播群组有惟一的D类地址。其地址范围从224.0.0.0到239.255.255.255。IP最多可提供多达228个同步组播群组的地址,因此,实际群组数受路由表的大小而不是编址的约束。

转发IP组播需要特殊的组播路由器(Multicast Router)。通常是给常规路由器添加这种能力。组播路由器会周期性地对该组进行查询,检查组内的成员是否还参与其中,只要还有一个主机仍在参与,组播路由器就继续接收数据。当所有的主机都离开了组后,组播路由器会收到一个Internet组管理协议(InternetGroupManageProtocol,IGMP)的“离开”消息报文,组播路由器就会马上查询组中是否还有活动的组成员。如果有活动的组成员,组播路由器就继续转发数据;如果没有,就不再转发数据。

2.4 IP组播路由协议

在路由式网络中,对于传递组播信息流,一个至关重要的问题是IP组播路由协议,它克服了利用单播通信模型传递组播信息带来的带宽瓶颈,减少了发送相同数据信息到多个接收者的通信费用,这也是IP组播应用得到发展的主要原因。组播网内数据的流动必须根据组播路由协议建立生成树,使发送源和组播组成员之间形成一条单独的转发路径,确保每个数据包都能转发到目的地。

IP组播路由协议分为域内协议和域间协议。域内协议包括PIM-SM、PIM-DM、DVMRP、CBT等。域间协议包括MBGP、MSDP、BGMP等。

根据网络中主机的分布,IP组播域内路由协议一般可以分为三类。第一类称为密集型模式,这种模式指组播成员在网络中密集分布,有足够的带宽,所以密集协议通过扩散技术传播信息至整个网络,它包括DVMRP、MOSPF和PIM-DM,属于数据驱动型。第二类称为松散型模式,这种模式指组播成员在网络中分散分布,没有足够的带宽,例如广域网或用户使用ISDN线上网,但松散型模式并不意味群组有很少的成员,只不过它们是分散分布的,它包括CBT和PIM-SM。此时,使用扩散技术将浪费带宽,通过发出加入请求申请,在含有集中点或核心点的空生成树上添加树枝形成组播生成树,属于接收者驱动型。第三类成为稀疏-密集型模式,这种模式可以同时对某些多播组采用密集运行模式,而对其他多播组采用稀疏运行模式。稀疏-密集型模式允许根据是否有RP信息来选择对多播组使用稀疏模式还是密集模式。如果路由器获悉了多播的RP信息,则对其使用稀疏模式,否则对其使用密集模式。

使用DVMRP、MOSPF组播路由协议时,单播路由协议相应必须使用RIP、OSPF,这就造成了一定的局限性,DVMRP使用距离向量路由协议建立生成树,MOSPF使用链路状态数据库建立生成树;PIM和CBT独立于单播路由协议,但依赖于单播路由表,其中PIM-SM和CBT有一个集中点或核心,连接源和接收者之间的各个路由器而形成路由。

3 IP组播在视频监控系统中的应用

如果要将组播通信应用在视频网络中,网络里的发送和接收主机、网络路由器以及它们之间的网络结构必须支持组播,防火墙设置成允许组播通过。

每个节点主机需有一个网络接口卡(NIC)要能支持组播,能有效滤出由网络层IP组播地址被映射成的数据链路层地址;需装有加入组播组请求的IGMP的软件和路由器通信,加入组播群;需有支持IP组播传送和接收的TCP/IP协议栈;再装上如视频会议这样的组播应用软件,主机就可以进入组播组进行组播通信。若发送音频,主机需要一个麦克风和相应的音频软件;若发送视频,主机需要帧控制卡和摄相机。

在视频网络中IP组播通信的过程如图1所示。

(1)主机发出一条IGMP加入消息到相邻路由器,主机的MAC地址映射为将要加入的D类组地址,并包含在IGMP数据报中,路由器知道主机想加入组播组。

(2)相邻路由器接收加入消息后,动态跟踪这些组播组,使用组播路由协议,在源端和接收端各个路由器之间建立组播生成树,从每个发送者伸展到所有接收者。

(3)在源端和接收端建立组播路由后,源就开始沿着组播路由发送数据给各个接收者。

主机接收到了源发送来的数据,网络接口卡滤出组播群组的MAC地址,网络驱动器对此地址做出反应后,把数据传递到TCP/IP协议栈,进入用户的应用层,就可以进行视频通信了。

4 结束语

IP组播技术有效地解决了单点发送到多点、多点发送到多点的问题,实现了IP网络中点到多点的高效数据传送,能够有效地节约网络带宽、降低网络负载,基于IP组播技术可以很好地开展流媒体、视频等各种宽带增值业务。随着下一代互联网技术的广泛应用,IP组播技术会拥有更广大的应用空间。

摘要：对IP组播技术和其在视频监控系统中的应用作了介绍,采用IP组播技术实现监控视频的多点传输,可以大大节省网络带宽资源,提高数据传送的效率。

IPV6组播技术的研究 第2篇

摘要：

文章在简介IPv6和组播技术的基础上，详细介绍了IPv6下的组播新特性，指出目前IPv6组播技术的几个研究方向，最后介绍了有关IPv6组播技术的研究成果。

关键词：

IP版本6；组播；群组管理协议；组播路由；组播主干网；组播地址

ABSTRACT:

Based on the brief introduction to IPv6 and the multicast technology, this article presents new features of IPv6 multicast in detail, points out key fields for the research of the present IPv6 multicast technology, and ends with some research results in the field of IPv6 multicast.

KEY WORDS:

IPv6; Multicast; IGMP; Multicast route; Mbone; Multicast address

1 IPv6的产生

互联网络协议(IP)产生于20世纪70年代，经过20年的发展，目前已经成为最主流的网络层协议。但它的很多设计已经制约了互联网的进一步发展。

早在1992年，人们就开始讨论制订下一代互联网络协议(IPng)。1995年，IETF(因特网工程任务组)采用了SIPP(简单因特网协议)作为IPng的制订基础。IPng被IANA(因特网编号管理局)正式赋予版本号6，即IPv6。1996年，IPv6的基本协议规范发表，并于1998年发表了修订版。IPv6扩展了地址空间，并提供了对数据传输的完整性和安全性的支持，支持规模更大的网络结构，以及网络的自动配置、更快的路由选择、更有效的路由聚合、增强的组播技术等。目前工业界广泛认可IPv6的优势，并且开始进行IPv4向IPv6的演进工作。各大路由器厂商已经开始提供IPv6路由支持，各种操作系统也开始嵌入IPv6协议栈。由于目前IPv4网络的商业化运行，在演进过程中会出现多种不同类型的混合网络，主机会同时具备IPv4和IPv6双协议栈，然后逐渐进化到纯IPv6网络。

2 组播技术的产生和发展

近年来互联网的飞速发展产生了很多新应用，特别是高带宽需求的多媒体应用。为了缓解网络“瓶颈”问题，业内提出了以下4种主要解决方案：增加网络带宽；采用QoS(服务质量)机制，控制不同业务的带宽使用；服务器的分散和集群；IP组播(IP Multicast)技术。其中，IP组播技术由于它所具有的独特优越性——在IP组播网络中，即使用户数量成倍增加，主干网络带宽不需要随之增加，而成为通行的网络技术之一。

如图1所示，组播是一种允许一个或多个发送者(组播源)发送同一报文到多个接收者的技术。组播源将一份报文发送到特定组播地址，组播地址不同于单播地址，它并不特定属于某单个主机，而是属于一组主机。一个组播地址表示一个群组，需要接收组播报文者加入这个群组。这样，无论有多少个组播报文接收者，整个网络中任何一条链路只传送单一的报文，大大节省了带宽。

(1)组播群组管理

IGMP(群组管理协议)被用来动态地管理群组成员加入和退出。当一台主机希望加入一个群组，它向本地的组播路由器发送IGMP消息。组播路由器监听IGMP消息，并作出相应的操作。同时它还周期性地发送查询，以维持当前活跃的群组。

IGMP有多个版本。其中IGMPv1只有两种消息，分别是成员查询和成员报告。通过这两种消息以完成最基本的群组加入和群组维护工作。IGMPv2基本上与IGMPv1相同，主要的区别是增加了一个离开群组的消息，这样就以通告的方式退出一个群组，而在IGMPv1中要通过组播路由器发出查询请求，发现没有响应才能确定群组成员的离开。目前正在制订的IGMPv3增加了源点过滤的功能，它允许一个群组加入者通知组播路由器所希望接收的组播数据源点，即只有该源点的数据才会被接收[1，2]。

(2)组播路由

在组播中，报文由组播源发送到一组主机。为了保证所有加入群组的主机都能接收到报文，需要一种描述报文在网络中所经过路径的方法，这就是组播分发树。组播树有3种基本类型：泛洪法、有源树和共享树。组播路由就是确定从组播源到群组的接收方所有成员的组播分发树。为了提高分发效率，组播路由方法必须在保证接收群组所有成员都能接收到组播报文的条件下，尽量减少网络资源占用量和组播的发送范围。组播路由协议可以分为稠密模式和稀疏模式两大类。

3 IPv6对组播技术的

继承和增强

由于组播技术的优越性，IETF在制订IPv6协议时保留了组播，而取消了广播；并且为了更好地使用和管理组播应用，IPv6对组播作了进一步的增强，主要表现在以下方面。

3.1 组播地址

IPv6组播地址格式如图2所示。IPv6组播地址的前8位为11111111；4位的组播标志用于区分众所周知组播地址(值为0)和临时组播地址(值为1)，该字段的高3位保留；4位的范围字段决定了组播报文能游走的范围。已分配的范围字段值如下（其他值或者还没有分配，或者已经保留）：

*9誗1：节点局部——节点局部报文禁止从端口输出

*9誗2：链路局部——链路局部报文不能被路由器转发

*9誗5：网点局部——网点的定义由该网点的组播路由器管理员决定

*9誗8：组织局部——组织的定义由该组织的组播路由器管理员决定

*9誗14：全球

从IPv6的组播地址格式定义，可见其相对于IPv4所具有的优越性：

(1)具有足够的地址空间。IPv4所定义的地址空间只相当于16个A类地址，对于全球的组播应用来说是远远不够的。而IPv6的地址空间从理论上来说，可以达到2 120个。

(2)范围字段的应用。组播地址不同于单播地址，它不专属于某一个主机或应用。除了少数为协议实现而预留的地址外，其他地址都是根据需求动态地分布给组播应用的用户。这样会出现一个组播地址同时被多个组播应用所使用的情况，这就需要保证它们之间传播的范围不会重叠。IPv4虽然使用了TTL(报文存活时间)来控制组播报文传送的范围，但是TTL不够精确，还是会存在不同应用间报文范围重叠的情况。而IPv6在地址格式中规定了范围字段，这样就可以很方便地划分组播域，根据组播域来控制组播应用的传播范围。

每个组播域有自己的组播地址空间，该地址空间的组播报文只在本组播域中转发，域的边界路由器不向域外转发该地址空间的组播报文。这样可以划分范围从小到大、依次包含的多层次组播域，即多个处于相同层次的范围较小的组播域组成一个更高层次的范围较大的组播域。不同层次的组播域的组播地址空间不相互重叠，相同层次的组播域可以有相同的组播地址空间。其优点在于用户可以根据自己的要求选择使用适当组播域的组播地址，使组播报文在期望范围内转发，以保证组播应用的有序运行[3]。

3.2 MLD协议

MLD协议(组播监听发现协议)是从IGMPv2协议中派生出来，专门用于IPv6组播群组的管理。其主要功能为：IPv6路由器利用MLD协议发现直接相连的链路上是否有组播组成员，以及相邻的路由器正在监听哪些组播地址。IPv6路由器上运行的组播路由协议根据这些信息，保证组播报文能发送给正确的接收者。

虽说MLD协议的前身是IGMPv2，但是MLD协议不使用IGMP报文格式，而是使用全新的ICMPv6的报文格式(ICMPv6协议是为IPv6网络定义的一套控制信息协议)。从某种意义上说，MLD协议就是ICMPv6协议的一个子集[4，5]。

4 IPv6组播技术的研究方向

随着IPv6网络的逐步演进以及组播应用的飞速增长，组播服务势必会成为下一代IPv6 Internet上的一种主要的网络服务。目前许多制订关于组播技术的协议标准，在服务于IPv4的基础上，都充分考虑了对IPv6的支持。虽然它们目前的研究重点环境是IPv4，但是作为IPv6的研究者来说，需要将更多的注意力放在组播在IPv6环境下所体现的新特性上。

4.1 组播地址管理

组播应用需要一个组播地址管理方法来得到地址。组播服务可以通过3种方法来得到组播地址，分别是：

(1)编码方式：将组播地址写入程序代码，使之成为程序的一部分，或者固化在ROM中。该方法适用于IANA静态分配的组播地址。

(2)通告方式：组播服务随机挑选一个组播地址，然后在使用该地址之前向网络通告它将要使用的地址。目前Mbone(组播主干网)中的组播服务就是使用这种方式，其代表工具为SDR(会议目录工具)。

(3)算法推导方式：使用一种程序化的算法为组播服务分配一个在全球范围内不与其他服务冲突的组播地址。

组播地址管理中的另一个主要问题是组播域的发现。组播域是一个组播服务的有效传播范围，不同的组播域有不同的组播地址空间，所以组播域的发现也就是用户选择组播地址空间的过程。

目前，IETF在组播地址管理方面成立了MALLOC(组播地址分配)工作组。该工作组的工作重点是制订与组播地址相关的一系列协议规范，为全球范围的组播地址分配提供保证。其主要工作成果包括：Internet组播地址分配体系结构(MAAA)、组播地址动态分配协议(MADCAP)、组播地址分配协议(AAP)、组播地址集申请协议(MASC)等等。同时，IETF的Mbone工作组制订了关于组播域发现的组播域声明协议(MZAP)。上述协议的制订充分考虑了IPv6组播地址的特性，并制订了相关的IPv6组播地址分配标准[6—8]。

4.2 组播网络管理

网管早已成为网络技术的一个热点，在这方面的研究成果和产品都很多。但是到目前为止，网管的重点主要集中在对单播流量的管理上，而对于组播流量却鲜有涉及。虽然有些技术在单播模式的网管和组播模式的网管上是同样适用的，但是，单播通信与组播通信在机制上的根本区别必然要求组播模式网管采用不同的技术。这就造成了主要针对单播流量进行管理的网络管理产品无法对组播流量进行有效的管理。同时，随着组播技术的广泛使用，组播流量在网络流量中所占的比重越来越大，对组播流量进行管理的需求也越发迫切。所以目前针对组播流量的网管技术研究正在成为一个新兴的热点。

虽然SNMP(简单网络管理协议)通过MIB(管理信息库)定义被管理对象，它本身和网络传输协议无关，可以完全应用于IPv6环境下(目前IETF已经制订了IPv6相关的MIB)，但是IPv6环境下的组播网管具有更多的新特性。例如规模更大的IPv6网络需要更健壮的网络管理，SNMP信息的处理需要更高的安全性等等。目前绝大多数路由器厂商提供IPv6路由支持，这为IPv6环境下的组播网管的研究提供了很好的条件[9-11]。

4.3 可靠组播传输

组播报文是通过UDP(用户数据报协议)进行传输的，所以它缺乏TCP(传输控制协议)所提供的可靠传输的功能。有些组播服务(如视频/音频服务)是可以容忍一定的丢包率的，而对于另一些组播服务如MFTP(Multicast FTP)，则要求可靠的组播服务。虽然目前有许多可靠组播协议，例如：SRM(可升级可靠组播)协议、RMTP(可靠组播传输协议)、TMTP(基于树的组播传输协议)，并且一些已经被商业化，但都还没形成标准。

IETF的RMT(可靠组播传输)工作组和IRTF(因特网研究部)的RMRG(可靠组播研究组)也正在进行相关协议标准的制订。其内容包括：如何在大规模组播环境下保证可靠的组播传输，其中又包括：设计基于负确认机制(NACK)的可靠组播协议、设计基于树型确认机制的可靠组播协议、设计使用前向纠错机制的异步分层编码协议等；支持延期加入的接收者；可靠组播的安全问题等[12-14]。

4.4 组播网络安全

网络安全不论是对单播网络还是对组播网络的正常运行都是至关重要的。组播网络安全与单播网络安全有着相似的要求：用户认证，数据一致性检查，数据加密，用户授权等方面。但是，考虑到组播技术的特点，如多点到多点传输，无需加入群组就可以向群组中发送数据等，在组播网络中实现网络安全的难度更大。组播网络安全的内容包括：限制发送者、限制接收者、限制访问、验证组播内容、保护接收者、穿越防火墙。

IETF的MSEC工作组(组播安全研究组)和IRTF的GSEC工作组(组安全研究组)也正在进行组播安全的相关协议标准的制订。其工作内容包括：定义组播安全总体结构(包括总体功能模块及其间的相互关系)；定义组播密钥管理方法等等[15，16]。

5 结束语

在1999年9月，东南大学与清华大学、华南理工大学合作承担国家“863”计划通信技术主题“九五”第2期研究课题：IPv6示范网络的建设及其关键技术的研究。在该研究项目中，我们的工作重点是建设IPv6示范网络的CERNET华东(北)地区中心节点，为华东(北)地区单位加入IPv6示范网络创造条件，并且承担了IPv6组播技术的研究。

我们成功地将Mbone中著名的音频会议工具vat移植到IPv6的环境下，并自行开发了支持IPv6的组播服务器mcastmp3。该工具组播MP3格式的音频文件，实现了在IPv6示范网络上传输组播多媒体数据流的要求，而且充分注意了协议无关性，可以支持IPv6和IPv4双协议，为开发与协议无关的网络通信软件进行了有益的尝试。上述工具的源代码可以在http://www.njnet6.edu.cn获得。

根据IETF制订的组播地址分配体系，我们开发了组播地址动态分配服务器，用于对CERNET华东(北)地区提供IPv4和IPv6组播地址的分配和管理，为组播应用的展开(例如远程教育)提供了支持。

IPv6协议和组播技术作为目前热门的研究领域，相应的协议和标准还在不断的制订、讨论和变化中，这些都需要我们积极地参与研究、开发和实践。□

参考文献

1 Fenner W.Internet Group Management Protocol. Version 2.IETF RFC2236, 1997

2 Cain B.Internet Group Management Protocol. Version 3.Internet-Drafts,2002

3 Hinden R, Deering S.IP Version 6 Addressing Architecture.Internet-Drafts,2001

4 Conta A, Deering S. Internet Control Message Protocol(ICMPv6) for the Internet Protocol Version 6(IPv6)Specification. IETF RFC 2463, 1998

5 Deering S, Fenner W. Multicast Listener Discovery(MLD) for IPv6. IETF RFC 2710,1999

6 Thaler D, Handley M, Estrin D. The Internet Multicast Address Allocation Architecture. IETF RFC 2908, 2000

7 Hanna S, Patel B, Shah M. Multicast Address Dynamic Client Allocation Protocol (MADCAP). IETF RFC 2730, 1999

8 Handley M, Stephen R H. Multicast Address Allocation Protocol (AAP). Internet-Drafts, 2000

9 Almeroth K.Managing IP Multicast Traffic: A First Look at the Issues, Tools, and Challenges. IP Multicast Initiative white paper, 1999

10 Diot C, Levine B, Lyles J, et al. Deployment issues for the IP multicast service and architecture. IEEE Networks, 2000

11 Sarac K, Kevin C A. Supporting Multicast Deployment Efforts: A Survey of Tools for Multicast Monitoring. Journal of High Speed Networking——Special Issue on Management of Multimedia Networking, 2001

12 Handley M, Whetten B, Kermode R, et al.The Reliable Multicast Design Space for Bulk Data Transfer. IETF RFC 2887, 2000

13 Whetten B, Vicisano L, Kermode R, et al. Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer. IETF RFC 3048, 2001

14 Luby M, Vicisano L, Gemmell J, et al. The Use of Forward Error Correction in Reliable Multicast. Internet-Drafts, 2001

15 Hardjono T, Canetti R, Baugher M, et al. Secure IP Multicast: Problem Areas, Framework and Building Blocks. Internet-Drafts, 1999

16 Harney H，Colegrove A，Harder E, et al. Group Secure Association Key Management Protocol. Internet-Drafts, 2001

(收稿日期：2002-04-05)

作者简介

梅飞，东南大学计算机系助研。2000年6月毕业于东南大学计算机系计算机应用专业。研究领域有：网络管理、IPv6、组播。曾参与国家“863”通信主题课题项目研究。

IP组播技术在流媒体传输中的应用 第3篇

以前人们在网络上观看电影或收听音乐时，必须先将整个影音文件下载并存储在本地计算机上，然后才能收看。与传统的播放方式不同，流媒体在播放前并不下载整个文件，只将部分内容缓存，使流媒体数据边传送边播放，这样就节省了下载等待时间和存储空间。常见的流媒体的应用主要有：视频点播（VOD）、视频广播、视频监控、视频会议、远程教学、交互游戏等。丰富的流媒体应用对用户有很强的吸引力。

语音和视频数据在网络中如果都采用点对点的单播，将产生大量的冗余数据，而且路由器、服务器也由于要处理大量的信息，造成处理能力下降甚至无法处理。IP组播技术的出现，很好地克服了这些问题。

1、IP组播技术介绍

1.1 IP数据包传输类型

IPv4定义了3种IP数据包的传输：单播（unicast）、广播（broadcast）和组播（multicast）ㄢ

单播传输：在发送者和每一接收者之间实现点对点的网络连接。如果一个发送者同时给多个接收者传输相同的数据，则必须相应地将数据包复制成多份后再分别投递。如果有大量主机希望获得数据包的同一份拷贝，将导致发送者负担沉重、延时长、网络拥塞，为保证一定的服务质量需要增加硬件和带宽。这种传输是最常见的IP传输，使用的非常广泛。

广播传输：是指在IP子网内广播数据包，所有在子网内部的主机都将收到这些数据包，不管它们是否乐于接收。广播的使用范围非常小，只在本地子网内有效，因为路由器通常会封锁广播通信。广播传输会增加非接收者的开销。由于使用的场合受到了限制，较少使用。

组播传输：在发送者和每一接收者之间实现一点对多点的网络连接。如果一个发送者同时给多个接收者传输相同的数据，只需投递一份数据包就可以了。组播提高了数据的传输效率，减少了骨干网络出现的拥塞的可能性。组播可以大大节省网络带宽，因为无论有多少个目标地址，在整个网络的任何一条链路上只传送单一的数据包。

同单播或广播相比，组播效率非常高，因为任何给定的链路至多用一次，可以节省网络带宽和资源。单播和组播数据传送过程的区别如图：

如图1所示，建立一个视频服务器和远程客户端的通信。假设网络中有N个用户，一个视频信息流需要占用1.5Mbps的带宽。

一个单播环境里，服务器依次送出N个信息流，由网络中的用户接收，共需要1.5M*Nbps的带宽；如果服务器处于10M的以太网内，6-7个信息流就占满了带宽；若在一个高速的以太网里，最多只能容纳250-300个1.5Mbps的视频流，所以服务器与主机接口间的容量是一个巨大的瓶颈。

在一个组播环境里，不论网络中的用户数目有多少，服务器只发出一个视频流，由网络中的路由器或交换器同时复制出N个视频流，广播到每个用户，仅需1.5Mbps的带宽。

1.2 IP组播原理

IP组播是对硬件组播的抽象，是对标准IP网络层协议的扩展。它通过使用特定的IP组播地址，按照最大投递的原则，将IP数据报传输到一个组播群组的主机集合。它的基本方法是：当某一个人向一组人发送数据时，它不必将数据向每一个人都发送数据，只需将数据发送到一个特定的预约的组地址，所有加入该组的人均可以收到这份数据。这样对发送者而言，数据只需发送一次就可以发送到所有接收者，大大减轻了网络的负载和发送者的负担。

组播报文的目的地址使用D类IP地址，范围是从224.0.00到239.255.255.255。D类地址不能出现在IP报文的源IP地址字段。单播数据传输过程中，一个数据包传输的路径是从源地址路由到目的地址，利用"逐跳"（hop-by-hop）的原理在IP网络中传输。然而在IP组播环中，数据包的目的地址不是一个，而是一组，形成组地址。所有的信息接收者都加入到一个组内，并且一旦加入之后，流向组地址的数据立即开始向接收者传输，组中的所有成员都能接收到数据包。组播组中的成员是动态的，主机可以在任何时刻加入和离开组播组；每一台主机都可以同时加入到多个组中，每一个组播地址可以在不同的端口或者不同的Socket上有多个数据流，同时许多实际应用可以共享一个组地址。

D类地址划分为局部链接组播地址、预留组播地址、管理权限组播地址等，分配如下：

·局部链接组播地址：224.0.0.0～224.0.0.255，用于局域网，路由器不转发此范围内的IP包。

·预留组播地址：224.0.1.0～238.0.0.255，用于全球范围或网络协议。

·管理权限地址：239.0.0.0～239.255.255.255，组织内部使用，用于限制组播范围。

2、IP组播技术在流媒体传输中的应用

如果要使组播通信流媒体传输中得以应用，网络里的发送和接收主机、网络路由器以及它们之间的网络结构必须支持组播，放火墙设置成允许组播通过。这是IP组播技术在流媒体传输中的应用的前提条件。

流媒体传输实际上牵涉到两方面的技术。其一就是服务器与客户端的通信技术，包括多媒体数据的传输、命令控制等；其二就是客户端对接收到的多媒体流实时解码后播放的技术。显然，网络通信可以使用Windows Socket技术，多媒体流的解码播放可以使用Directshow技术。本文重点讨论Windows Socket网络传输技术。

2.1 系统架构

流媒体在网络中的应用一般采用服务器/客户端的架构。这样只需要对有限的服务器进行更改、设置，即可满足所有客户端的要求。

一个IP组播的源主机一般都是音频、视频、金融等各种各样类型的流数据进入网络的多媒体服务器。应用程序会根据事先的设置自动分配一个D类多路广播地址给服务器以及它的所有成员。当一个客户端想要加入组播时，可以通过发送一条IGMP报文给它的本地子网开始，这条报文包含它想加入的组的D类地址。在与源主机建立连接后，本地有组播能力的路由器，就把所有的给目标主机组的组播数据传送到本客户端的子网。

2.2 IP组播技术的实现

服务器和客户端之间有一个Socket通信协议的问题。由于流媒体传输需要注意实时性，媒体数据的实时性比正确性更重要。因此服务程序使用套接字编程和多线程完成。它利用TCP套接字作为控制通道实现控制信息的传递及其客户端的交互。利用UDP实现流媒体数据的传输通道。

在具体实现时，采用多线程技术。首先服务器在指定的端口上进行监听。当发现有客户端请求时，建立一个线程使用UDP协议专门负责组播数据的发送。本线程只需要建立一次，在第一个客户请求时建立，后续客户请求则不用新建。同时，服务器也需要和每个客户端建立一个TCP连接，这样能够随时接受客户端的控制信息。此操作需要在每个客户请求时，建立一个线程来完成TCP的连接。这样，在服务器正常工作时，大部分时间运行的是一个监听线程，来响应新的客户的请求；一个UDP传输的线程，实现组播数据的发送；多个TCP连接的线程，完成服务器和客户端控制信息的交互。

与单播协议相比，组播没有补包机制，因为流媒体数据采用的是UDP的传输方式，并且不是针对一个接受者，所以无法有针对的进行补包。所以直接用组播协议传输的数据是不可靠的。在需要时，我们可以在应用层上适当增加质量控制。

3、结语

我们可以看出，IP组播技术有效地解决了单点发送到多点、多点发送到多点的问题，实现了IP网络中点到多点的高效数据传送，它能够有效地节约网络带宽、降低网络负载。基于IP组播技术我们可以更好地开展流媒体、视频等各种宽带增值业务。

参考文献

[1]陆其明.DirectShow实务精选[M].科学出版社北京科海电子出版社, 2004.

[2]于海生.组播在视频监控系统中的应用[J].吉林交通科技, 2008年第2期.

IP组播技术 第4篇

传统监控系统通过流媒体服务器进行视频的转发来解决多路查看, 但是每次视频流分发通过流媒体服务器之后, 都会增加几百毫秒的延时。大系统需要的流媒体服务器也就越大, 这就出现了设备管理、均衡负载等问题, 同时流媒体服务器巨大的视频分发压力使其性能大打折扣[2]。在存储方面, 传统监控系统采用DVR的PC级硬盘进行数据存储, 大码流的视频数据不间断读写会导致硬盘故障率变高, 可靠性差; 而且硬盘可扩展性能差不利于数据备份和数据量扩容[3]。数据管理方面, 传统监控方案在编解码、传输、存储、网络至少需要集成三到四个厂家的产品, 很难做到统一管理, 一旦丢失摄像头信号故障定位非常困难[3]。

当前, 城域范围内的监控规模不断扩大, 对视频监控系统的要求也在不断提高[4]。本文将IP网络、IP视频应用及IP SAN存储技术与视频监控系统进行了融合, 并提出了一种IP智能监控系统 ( IP Video Surveillance) , 依靠成熟的IP技术, 能弥补传统系统的上述不足, 更能迎合市场的性能需求, 特别是大范围的监控系统。

1 IP网络智能监控系统的构成

1. 1 系统组网

该系统主要由以下部分组成: 视频监控管理服务器VM Server、数据管理服务器DM Server、监控终端、客户端软件VC、IP-SAN网络存储设备和EPON无源光网络设备等[5]; 各个部分之间可以实现分散部署和统一管理, 系统组成如图1所示。

从图中可以看出系统组成在分布上和传统视频监控类似, 监控终端进行数据采集, 将数据通过IP网进行传输给控制管理服务器进行处理转换, 通过IP网的SAN进行储存, 在现实终端进行视频显示。

1. 2 工作原理

系统各个组成部分通过IP网络有机地融合为一体, 实现了更有效更快捷的视频监控效果。首先视频源完成视频和音频信号的采集工作, 视频源的类型很多, 有球形摄像机、枪型摄像机、高速智能球机等。视频信号被传输给监控终端进行数据信号的编码, 比传统系统优化的地方是在这里还可以进行i SCSI存储和网络接入[6]。信号被打包成IP数据包传送给IP网中, 在这里不仅能传输数据还能进行视频流的交换。本文对传输部分进行了组播支持优化和安全策略的设计, 使信号能够完整快速地传递给控制管理中心服务器, 实现了视频交换的流畅性和安全性。

数据流到达控制管理中心服务器后就相当于数据进入了大脑, 通过VM服务器可以实现对任何一个终端的管理、调度、控制及编码解码控制, 通过DM服务器可以实现对大量数据的存储管理、动态分配、查询资源、存储状态报警等功能。

本文设计的智能监控系统的数据存储是通过IP SAN存储, 可以实现视频数据的点播和下载, 所有功能都能通过DM服务器管理。系统最后的部分是显示, 不仅能像传统系统那样通过电视墙等媒体终端显示, 还能通过IP组播的形式进行数字化解码在调音台等设备上输出。图2 为该IP智能监控系统的组网拓扑结构图。

2 基于IP网络智能监控系统的实现

基于IP网络智能监控系统利用了NGN控制与交换互相分离的思想, 将IP网络、视频传输及SAN存储技术进行了有机的综合。系统不仅能完成传统系统的视频监控的功能, 还能实现视频回放、SAN存储等智能化功能, 使视频监控系统技术更能满足用户的需要。主要功能实现流图如图3所示。

系统实现视频监控实时监控, 要在VC终端上进行视频监控实时监控的命令下达, EC接收到经过VM服务器的控制指令后, 进行视频流的传输。本系统中视频流传输是以IP组播的形式进行的区别于传统系统。用户将输出终端加到想要监控的组中就可以实时地查看该组播的监控画面了。通过IP组播可以节省整个系统中的网络带宽。同时, 视频监控数据的存储可以在DM服务器中事先设定, 并将设定的计划发放给SAN存储器, 通过TCP/IP i SCSI就可以实现将需要存储的数据进行自动快速地存储。

3 IP智能监控系统的评价

IP智能监控系统将传统的视频切换矩阵变成了IP网络, 简化了系统构造, 将指令控制和视频流处理互相分离, 使视频服务器性能瓶颈得到了有效地回避, 使系统更稳当、更可靠; 融入了组播等优化设计, 系统进行编码的同时可以实现全网络终端数据的交换, 使视频监控画面质量更高、实时性更强、响应时间更短; SAN存储技术使视频监控数据的存储更快、管理更集中并且存储性能可扩展; 更能适应当前市场对视频监控系统的视频画面质量高、实时性好、查询历史视频速度快等性能的需求。

传统系统虽然也能完成实时监控画面的显示等功能, 但是每次查看用户的数量有限, 监控画面模糊、质量差, 没有起到视频监控拍摄有利信息的效果, 而且查询历史记录时间较长, 往往耽搁了最佳查询时间[7]。

本系统与传统视频监控系统功能和性能比较如表1所示。

4 结论

本文将视频设备、IP网络及监控视频软件有机地整合为一体, 设计了基于IP网络的组播智能监控系统, 引入了IP组播进行视频分发, 解决多路查看的问题, 提高了编码效率。该系统应用了最新的网络传输与存储技术, 采用IP网中的分布式概念和组播管理方式来实现IP监控的控制和管理, 优化了数据管理模式。系统试运行效果良好, 能够保证监控图像的跨域查看响应时间在300 ms以内, 并且存储速度快, 视频监控画面清晰质量高, 能够满足专业监控的需求。

摘要：将视频设备、IP网络及监控视频软件有机地整合为一体, 设计了基于IP网络的组播智能监控系统, 引入了IP组播方式进行视频分发, 解决多路查看的问题, 提高了编码效率。该系统应用了最新的网络传输与存储技术, 采用IP网中的分布式概念来实现IP监控的控制和管理, 优化了数据管理模式。

关键词：IP网络,视频监控,数据传输

参考文献

[1]李威, 田联房, 李向阳.嵌入式网络视频监控系统的硬件设计与实现[J].微计算机信息, 2012 (8) :69-70.

[2]蒋玉峰.安防企业进入IP视频监控时代[J].中国公共安全 (综合版) , 2014 (8) :70-72.

[3]余梦璐.安防视频监控系统概述[J].长江大学学报 (自然科学版) 理工卷, 2013 (2) :296-297.

[4]RAO Yuan, WANG Ruchuan.Qo S Routing Based on Mobile Agent for LEO Satellite IP Networks[J].The Journal of China Universities of Posts and Telecommunications, 2012 (6) :57-63.

[5]李刚健.基于IP网络远程监控系统的设计与实现[J].微计算机信息, 2014 (14) :57-59.

[6]吴静, 郭成城, 晏蒲柳.IP网络生存性研究综述[J].计算机科学, 2013 (5) :8-13.

IP组播技术 第5篇

[1]王嵩, 薛全, 张颖, 等.H.264视频编码新标准及性能分析[J].电视技术, 2003, 27 (6) :25-27.

[2]谢希仁.计算机网络[M].5版.北京:电子工业出版社, 2008:164-170.

[3]王伟.IP组播在CMMB单频网中的应用与实践[J].电视技术, 2012, 36 (2) :9-11.

[4]高升, 陈兴蜀.基于NDIS的数据包安全传输模型[J].电子科技大学学报, 2007, 36 (6) :1453-1456.

[5]微软公司.Microsoft Windows 2000 driver development kit documentation[EB/OL].[2013-03-29].http://www.microsoft.com/mspress/books/sampchap/4119.aspx.

IP组播技术 第6篇

关键词：视频组播,网络快速收敛,MTBF,MTRR,马尔科夫

0 引言

基于IP组播技术的网络应用正在不断普及, 其中, IP视频网络是此类组播应用中最为常见的技术之一, 如在平安城市、交通监控和机场港口等关键部门的应用等。近几年随着视频编码技术的发展和视频节点规模的扩大, 对组建一个不仅高速而且可靠的IP组播网络提出了更高的要求。其所依赖的网络基础设施, 不仅要求快速和互联互通, 而且要求网络有很好的高可靠度, 特别一些关键部门对IP视频的连续性有很高的要求, 以及对断网的零容忍度, 故视频网络的高可靠度已经成为此类组播应用的核心议题。可靠性可通过平均无故障时间MTBF (Mean Time Between Failures) 和平均修复时间MTTR的计算作为预估的量化值。在MTBF数值固定的情况下, 如何降低MTRR成为了提高视频组播网络可靠性的关键手段。

一个未经合理优化的组播网络在发生故障切换时, 其所需的收敛时间要远远长于常见OA办公自动化网络的单播环境, 并大大低于一般预期值, 表现在视频网络应用时, 视频画面轻则产生马赛克现象, 重则黑屏。

结合作者曾主持设计实现的机场和公安等视频网络重大国内项目建设、优化和排错经验, 系统性地提出了如何降低IP视频组播网的MTRR的多种方法, 并得到更高预期的可靠度值。

1 网络快速收敛理论研究

网络快速收敛技术是指在网络发生故障时, 网络设备能自动快速恢复原有的路由表项并使数据正常转发。MTBF和MT-TR是该领域通常关注的可靠性量化指标;同时, 由于马尔科夫链 (Markov) 模型反应了系统变化的过程, 因此, 也常被用于网络高可靠性研究。

1.1 网络快速收敛概述

根据采用的技术不同, 其性能在秒级乃至亚秒级。

本文考虑的网络收敛时间可以用一个集合C表示, C={C1, C2, , Cn}, 其中元素Ci表示各类影响网络收敛的因素。目前i可以为1~3, 即C1表示物理层因素, C2表示协议层因素, C3表示设备层。而各个元素又可以定义成一个子集合。C1={T1, T2, , Tn}, 其中子元素Tj表示物理层类的因素, 目前j可以为1~2, 即T1表示故障检测, T2表示光电转换, 网络传输。C2={t1, t2, , tn}, 其中子元素ts表示物理量类的因素, 目前s可以为1~5, 即t1表示产生新的LSP/LSA, t2表示到最远的路由器距离, t3表示的是网络泛洪过程, t4表示网络泛洪到最远路由器, t5表示的是采用最短路径树算法计算路由表。C3={D1, D2, , Dn}, 其中子元素Dn表示设备类的因素, 目前n可以为1-2, 即D1表示设备更新路由表和转发表, D2表示把转发表下发到线卡上。

据此, 得到网络收敛时间如下:

具体可表示为:

其中, Tc:全网收敛时间, Tlink:故障检测所需时间, Ttrans:网络传输所需时间, Tlsp:产生新的LSP/LSA所需时间, Thop:到最远的路由器距离跳数, Tflood:网络泛洪到最远路由器所需时间, Tspf:最短路径树计算所需时间, Trib:设备更新路由表和转发表所需时间, Tlc:转发表下发到线卡上所需时间[1]。

整个过程的时序可以如图1所示[2]。

图1中从左到右, 可以看到在每个时间节点上所对应的收敛操作细节和其所需时间。

1.2 高可靠性分析

高可靠性研究领域常见的量化因子是MTBF和MTTR。设备故障次数少, 恢复时间快是高可靠性的特点。结合统计学概念, 可以用“可靠性 (Availability) ”这个参数来进行量化度量:

从上述公式可以看出, 如果要提高可靠性, 可以通过提高MTBF, 或者降低MTTR来实现。

对于用户体验, 一般常用每百万单位缺陷数DPM (Defects Per Million) 表示, 通俗的说法就是4个9 (99.99%) 或者5个9 (99.999%) 的可靠性。不同数量的9意味着不同的可靠度。4个9意味着1年宕机1小时, 5个9意味着1年宕机5分钟。DPM如下式所示:

设备的MTBF值可以采用基于设备元器件的预知可靠性的Telcorida (即原来的Bellcore) 部件计算法[3], 来获得预估值或者根据现实设备故障率来获得实际值, 为达到更加精确的MTBF值也可以将二者结合起来。

设备元器件可以是系统元件 (如电路板等) , 也可以是网络元件 (如交换机, 路由器等) 。所以高可靠性的计算可以计算设备单体, 也可以计算由若干设备单体所搭建的网络整体。

如果任何元器件是必须运行的, 而且任何一个元器件的失效会导致整个系统发生故障, 则这种连接方式称之为串联方式。其计算公式如下:

如果是多个元器件结合起来, 只要有一个元器件能工作, 即使其他元器件失效, 系统也能正常工作, 则这种连接方式称之为并联方式。其计算公式如下:

在现实中, 系统都是复杂的, 不是那么单纯的, 一般会是串联和并联结合的混合系统, 其可靠度为:

其中, A为总可用性, n是设备数量。

一般对于网络可靠性的预测分析计算正是基于上述理论, 但操作起来会比较繁杂, 为便于实际工程使用计算, 根据式 (7) , 采用Excel宏命令编制的面向单机可靠度计算的SHARC工具 (System HW (and SW) Availability and Reliability Calculator) 和面向整体网络可靠度计算的NARC工具 (Network Availability&Reliability Calculator) 会有较强的实用性。这2个工具在使用时, 只需要输入关键参数, 如相应产品的MTBF值等, 就可以得到最终计算值。

由于MTBF取决于设备本身的质量, 这在出厂时就已经确定, 当系统本身的MTBF到达极限时, 就无法纯粹依靠通过提高MTBF数值来获得更高的可靠性, 那么通过减小MT-TR数值来实现高可靠性, 便成为可为人所控制调整的因素的方法。

1.3 马尔科夫链模型讨论

马尔科夫链模型研究了系统不同状态变化的过程, 这和可靠性研究的领域非常类似, 所以马尔科夫链模型被广泛应用于可靠性模型研究中[4]。常见的1:N备份 (1个设备做专用备份, 保护N个主用设备, 平时不使用) 采用马尔科夫链模型的表述, 如图2所示。

其中, N代表所有激活的设备, λ代表单体设备的失效率, μ代表失效设备维修率, β代表从失效设备切换到备份设备的成功率, C代表切换率。

该模型下的5个不同状态分别是, 状态1:正常工作;状态2:检测到1个设备发生故障;状态3:备份设备接替工作;状态4:在第1个设备被修好前第2个设备发生故障;状态5:激活设备失效, 无法切换到备份设备。

可以看出1:N备份可靠度不高。作为对上述的改进, N+1主备方式 (指N台主用, 1台作为备份, 并同时使用) 如图3所示。

在这改进模型中的5个不同状态分别是, 状态1:正常工作;状态2:检测到1个设备发生故障;状态3:N个备份设备接替工作;状态4:在第1个设备被修好前第2个设备发生故障;状态5:可以切换到备份设备。

假设F0是备份系统正常时的概率, F1是主系统故障, 备份系统正常时的概率, F2是主备系统都故障时的概率, 按照马尔科夫链原理, 其状态转移方程为:

对上述方程组求解:

故系统的正常概率是F0+F1, 即系统的可靠度为:

对于IP视频网, 通常要求可靠度是99.99%, 则λ是0.01%。所以从上述公式可以看出, 和纯粹的单机相比, 存在冗余的系统的可靠度会大大提高。从上述理论计算上看, 一般有冗余度的情况下, 可以提高约一个数量级, 也就是说如果单机的可靠度是90%, 那么冗余系统就可达到99%;如果单机达到99%, 那么冗余系统可以达到99.9%。因此为达到更高的可靠度, 多采用N+1冗余系统。这里的N+1包括单机内部的N+1冗余, 也就是多引擎, 多电源等;还包括系统整体的N+1, 也就是多机冗余等。同时也要采取其他各种措施降低MTRR才能达到理论上的10%的性能提高。

2 网络快速收敛技术应用

网络快速收敛技术包括单播和组播2种应用场景。其目的是从各个收敛的层面, 减少等待时间, 并加速收敛过程。但值得注意的是, 由于减少等待时间, 一般都会加快设备CPU检测的轮询时间, 所以要在轮询频度和CPU负荷之间找到平衡点, 避免由于过度频繁地检测网络状态而造成的设备负担, 但又能及时感应并响应状态的变化。

2.1 单播路由MTRR优化

从MTTR的角度看, 要想减小其数值主要有2种手段, 一是以最快的速度感知故障;二是以最快的速度从故障状态中恢复出来。因此构建高可靠性网络的基础就是要实现快速故障检测和快速故障恢复。

由于IP组播网在路由寻路的时候, 要进行反向路径检查RPF (Reverse Path Forwarding) , 而这又是建立在传统IP单播网络的基础上的, 所以IP组播网在网络路由表项恢复时, 也就是收敛时, 需要经历IP单播网络内部网关协议IGP (Interior Gateway Protocol) 的收敛, 然后再是IP组播网络的收敛, 故其复杂度和时间敏感度都较高。加快单播路由收敛的主要手段如下[5,6,7]:

加快线路检测:当物理端口发生状态改变后, 系统加速将此状态通知后续进程。

端口事件处理:当物理端口不稳定, 反复发生状态改变, 将该端口关闭不可用。

端口多种自适应功能:将端口的多种自适应功能处于强制设置状态。

端口汇聚:将端口汇聚时采用的负载均衡哈希算法设置为网络第4层。

快速生成树:设置快速生成树功能。

基于状态的引擎切换:在主备引擎切换过程中, 将主引擎的路由表项复制到备份引擎上。

开放式最短路径优先OSPF (Open Shortest Path First) 时间参数优化:降低OSPF标准的hello时间参数。

OSPF运算优化:降低OSPF标准的链路状态通告LSA (Link-state advertisement) 计算的延迟时间和采用增量的最短路径优先SPF (Shortest Path First) 计算方法。

路由协议被动端口:减少不必要的冗余的OSPF邻居关系。

NSF (Non Stop Forwarding) 不间断转发:在主备引擎切换过程中, 通过采用GR (graceful restart) 方式。

上述加速单播路由收敛的方法, 是从物理层, 链路层和网络层这3个层面进行的。物理层实现感知链路变化, 链路层对2层协议进行收敛, 网络层对3层协议进行收敛。3者关系是顺序执行的。只有前者加速完成了, 才能进入到后一个层面运行。所以他们之间的关系是相辅相成的。

2.2 组播路由MTRR优化

在完成了上述单播路由快速收敛, 组播协议进行了反向路径检查后, 组播协议开始其路由恢复收敛进程。

提高组播本身收敛速度, 可从以下组播环节入手:

组播邻居轮询速度:加快因特网组管理协议IGMP (Internet Group Management Protocol) 组播邻居轮询的时间, 及时触发更新组播表项。

组播路由表项缓存:清除组播路由表项缓存, 避免使组播数据流继续使用无效的缓存表项。

组播路由表项复制:在主备引擎倒备过程中, 将主引擎的组播表项同步到备份引擎, 从而减少备份引擎启动后需要对相关组播表项进行重新计算而消耗的时间。

3 组播高可靠网络的实现

运用上文所述的单播快速收敛原理和相关的组播快速收敛理论, 从组播性能、可达性和可靠性角度指导了一些现实且重大的IP视频网项目的整体设计;并在项目实施中, 取得了良好的效果。

3.1 IP视频网实例

在国内某亚太枢纽机场的IP视频网项目中, 笔者采用上述理论和方法, 对该网络进行了整体设计、建设和优化等工作。

该项目在单一园区中部署了2 100多个IP摄像头, 采用MPEG2编码, 码流6~8 M, 网络有十多台核心交换机和约上百台接入交换机。采用中央集中网络录像存储方式。全网采用组播。大屏总控室所连接的核心交换机组播表项约600多个。

在项目设计阶段, 搭建了测试实验环境, 使用和项目部署完全一致的设备, 全面仿真了该IP视频网的核心节点拓扑, 并采用专业测试仪取得量化测试数据。

为实现客户提出的高可靠度要求, 组合使用了上文提及的多种网络快速收敛手段, 反复测试验证, 最终大幅降低了MTRR值, 并为后续实际部署取得了最佳实践配置参数。由此客户在项目实施前, 就对最终结果值的数量级有了量化了解, 从而为科学设定系统可靠度值提供了真实而有效的依据。

在项目实施阶段, 采用上述验证测试得到的最佳实践参数值, 一次统调成功。在测试科目设置的多项故障切换预案演练中, 其在真实网络流量环境下的测试值和验证测试数值接近吻合。同时由于网络设备本身具有丰富且可靠的调试检测能力, 反而作为验证其他配套设备, 如IP视频编码器的组播功能指标的工具。

正是由于设备具有上述丰富的组播参数调整能力, 在实际调试运行阶段, 针对真实环境, 对其他配套产品本身, 如IP视频编码器的网络参数优化调整过程中, 进行了验证。

该项目自正式投产后, IP视频效果的用户体验非常良好, 而且可靠性非常高, 在历经了多个国内国际重大活动时高客流量期间, 均未发生意外, 达到了客户预期的可靠度目标, 得到好评。

整个项目拓扑如图4所示。

在后续的国内特大新型交通枢纽项目中, 其IP视频监控网, 以此项目为蓝本, 采用了类似的IP视频网高可靠设计, 并再次获得成功。

3.2 IP视频网设计

对于该IP视频网设计, 从多个角度着手。

首先是如何保证IP视频的性能, 也就是画面的流畅性。为得到网络设备能支持的组播流的理论数量值, 尤其是上下联端口可以支持的IP视频组播流的数量, 进行了以下量化计算:

假定码流6 M, 其吞吐量pps (packet per second) 为6 000000 (pps) /1 338 byte (视频流数据报文的字节长度) /8 (byte到bit转换) =560 pps。

已知该测试模块, 24GE线卡在1 510字节下组播的吞吐量为1.3 Mpps, 则其可以支持的码流数量, 近似为1 300 000 (pps) /560 (pps) =2 321个码流, 平均每个端口2 321/24=97个流。所以在设计时, 需要考虑到, 核心或者汇集层下联端口, 不应超过97个组播流, 或者说就是97个IP摄像头。也就是说该光纤端口下面无论是单台还是级联的交换机所连接的摄像头数量不宜超过97个。在具体实施时, 也的确是按照这个量化原则进行部署的, 得到了实际验证, 达到了最佳性能。

其次是如何保证IP视频的可达性, 也就是组播网的大小。组播和单播不同, 一般来说, 硬件产品支持的单播表项会很大, 往往可以达到几百K的规模, 而组播却很小, 从几K到十几K不等。而在网络监控中心, 由于采用对摄像头轮询显示的方式, 故监控中心所属的核心网络设备的组播表项会很大。由于组播表项建立过程中会生成 (*, G) 和 (A, G) 2个表项, 所以1个摄像头会占用2个组播表项。实际工程表明, 摄像头和组播组对应关系会有1∶4, 而且一般不会让设备的表项等超过最大值的50%, 所以经验法则是组播表大小至少是摄像头的8倍。

最后, 最重要的就是本文所讨论的组播高可靠性。

3.3 验证测试

在该IP视频监控网设计阶段, 为获得最佳可靠度, 在优化MTRR过程中, 事先搭建了全真模拟测试环境如下:

网络设备:Cisco6509系列交换机共4台, 成口字型通过千兆模块网状L3/L2连接, 2端L2连接2960交换机。2960连接到测试仪上。

连接方式:Cisco6509之间采用4组交叉连接, 每组4条GE组成的多端口绑定网状互相连接。

测试仪表:Sprient Test Center 2000带16个GE端口, 8发8收。

流量:测试仪模拟320台服务器和320个客户端, 均为不同IP地址, 加入到不同的组播组 (320组) , 速率为每个流6-8M带宽, 数据流字节数从256 Byte开始随机产生。

测试模块:Sup720-3BXL, 6748模块, Native IOS 12.2.18SXF4 (IP service) 。

每个测试科目至少运行10次, 记录10次。测试拓扑如图5所示。

本文进行了引擎切换, 链路切换和节点切换测试, 每个科目均有若干不同参数的配置测试[8,9]。由于单机的故障率最高, 代表性较强, 同时也为减少篇幅, 本文只提供了单机的引擎切换的测试结果, 但其优化方法在其他的测试中都得到验证, 这些结果均对降低MTRR有帮助。

4 组播网络的可靠性分析

根据上文的原理分析, 在搭建完全真实的网络环境中, 对快速收敛技术进行了比较验证测试, 取得了一手的最佳实践结果。同时关注了快速收敛和CPU负荷的平衡问题。最后对实验数据进行了高可靠度分析对比计算, 验证了上文的理论分析。

4.1 测试结果

4.1.1 未优化测试

测试仪8个发送端模拟产生311个不同的服务器加入到311个不同的组, 8个接收端模拟产生320个不同的客户端加入到各个不同的组, (其中一个组为组播复制10个客户端) 关闭6509#2和6509#4, 确定流量只在6509#1上。6509#1上有2个引擎, 配置SSO/NSF, 进行引擎切换。采用默认组播轮询时间30s。分数据源在6509#1端 (组播上游) , 或在6509#3端 (组播下游) , 共2种情况, 结果如图6所示。

图6显示了未经优化的组播收敛时间约在1.5至3 s (10次测试) 。这个时间对于连续视频效果体验来说, 由于中断时间较长是很不理想的。

4.1.2 优化测试1

降低组播轮询时间为10 ms, 重复上述测试, 结果如图7所示。

图7显示了经组播轮询时间优化的组播收敛时间约在0.4至1.4 s (10次测试) , 这个时间对于连续视频效果体验来说, 中断时间减少了, 相比前者有了一定进步。

4.1.3 优化测试2

在降低组播轮询时间为10 ms基础上, 同时关闭组播路由表的cache, 重复上述测试, 结果如图8所示。

图8显示了经二次优化的组播收敛时间约在0.22至0.65 s (10次测试) , 这个时间, 相比前二者, 有了很大的进步, 由于比较接近人眼视觉暂留时间 (0.2~0.4 s) , 所以较为理想。

4.1.4 轮询时间和CPU负荷平衡点

加快组播轮询频率, 会导致CPU的负荷增加, 经过实验研究, 选取了合适的组播轮询时间, 但也不会过高增加CPU负荷, 可以看到轮询时间小于10 ms时, 会造成CPU负荷极具上升, 而低于10 ms时, CPU的变化不明显。结果如图9所示。

图9显示了组播时间轮询和CPU的对应关系。反应出如果轮询频率过高的话, 设备的CPU就会忙于应付轮询工作, 导致CPU负荷过高。

测试小结:

由于采用了尽可能多的手段, 大幅降低了MTRR。

4.2 可靠性计算分析

4.2.1 未优化前结果

1) 单体的可用性

采用前文提及的SHARC工具 (根据公式7编写) 进行理论计算, 得出本项目所采用的Cisco6509单机的MTBF约为99.9%, 如表1所示。

表1是Cat6509交换机的各个部件在数据库中的MTBF值, 注意, 随着时间的推移, 产品使用时间的增加, 故障率会增加, 该数值会降低。

其中Part是指单机元器件, n是指元器件数量, HA是指冗余方式, N是指没有冗余, A是指主备热备份, L是指负载均衡, Part MTBF是指预测的元器件MTBF值, Part MTTR是指预测的元器件MTTR。SHARC只支持无备份方式。

根据式 (7) 可以计算出:

系统可靠性=99.98862415%

系统不可用性=0.01137585%

年均宕机时间 (min) =59.83

系统MTBF (hrs) =8 790

2) 系统的可用性

采用NARC工具 (根据式 (7) 编写) , 进行理论计算, 得出其所采用的整体网络环境的MTBF约为99.6%, 如表2所示。

表2是整个网络系统中各个设备的MTBF。其中System是指系统各单机, n是指单机数量, Redundancy是指冗余方式, N是指没有冗余, A是指主备热备份, L是指负载均衡, System MT-BF是指预测的系统MTBF值, System MTTR是指预测的系统MTTR。NARC只支持无备份方式。该表中各个单体设备的MTBF值由SHARC工具计算得出。根据式 (7) 可以计算出:

网络可靠性=99.65452372%

网络不可用性=0.34547628%

年均宕机时间 (min) =1 817

网络MTBF (hrs) =964

该整体网络预测值和客户的高可靠性要求是有一定差距的。

4.2.2 优化后结果

在采用带有元器件冗余方式和MTTR参数优化的改进的SHARC+工具 (根据式 (7) 编写) , 并结合上述MTRR值后, 理论计算出其所采用的Cisco6509单机的MTBF约为99.99%, 如表3所示:

系统可靠性=99.99191404%

系统不可用性=0.00808596%

年均宕机时间 (min) =42.53

系统MTBF (hrs) =10 277

该工具和SHARC相比, 冗余参数全部可用。

采用带有系统设备和MTRR参数优化的改进的NARC+工具 (根据式 (7) 编写) , 并结合上述MTTR值后, 理论计算出其所采用的整体网络环境的MTBF约为99.99%, 如表4所示。

网络可靠性=99.99603660%

网络不可用性=0.00396340%

年均宕机时间 (min) =20.85

网络MTBF (hrs) =1 275

该工具和NARC相比, 冗余参数全部可用。

从上述预测的计算值可以看到, 通过增加冗余度和多种手段降低MTRR, 无论是单体设备还是整个系统的可靠性都提高约10%, 和马尔科夫理论计算值较为吻合。经客户运行, 和实际情况也较为接近。

5 结语

高可靠性和MTBF与MTTR有直接关系。在系统已经开发完毕, 不能再改变系统本身的MTBF值的情况下, 要获得更好的可靠性, 只有通过降低MTRR来实现[10]。

本文以降低网络设备MTTR为提高网络MTBF的切入点, 系统地将和IP组播快速收敛各主要关键环节相关的配置参数进行调优, 并搭建了真实测试环境进行验证实验。此外, 该研究成果在多个重大IP视频网项目中得以采用, 取得了良好的效果。

参考文献

[1]Francois P, Filsfils C, Evans J, et al.Achieving sub-second IGP convergence in large IP Networks[J].ACM SIGCOMM Computer Communication Review 2005, 35 (3) :35-44.

[2]郭宋.毫秒级IGP网络路由快速收敛的研究[EB/OL].[2008-09-03].中国科技论文在线.www.paper.edu.cn/download/downPaper/200809=-66.

[3]Bellcore.Reliability Prediction Procedure for Electronic Equipment[R].Technical Reference TR-332, Issue 6, December 1997.Bellcore, 1997.

[4]Haihong Zhu.Reliability and availability analysis for large networking system:Reliability and Maintainability Symposium (RAMS) , 2012 Proceedings-Annual[C].IEEE.2012 (1) :23-26.

[5]张志华, 于群.IP承载网的高可靠性技术与实现[J].邮电设计技术, 2011 (8) :60-64.

[6]李园花, 李健, 赵凯.基于链路状态路由快速收敛技术的研究[J].网络安全技术与应用, 2009 (3) :9-11.

[7]姚林燕.IGP_OSPF路由协议网络优化技术[J].电脑与电信, 2012 (Z1) :39-41.

[8]陈晶.多业务网络可靠性关键技术探讨[J].中国新通信, 2007 (1) :83-85.

[9]李昕.IP网络生存性技术研究[J].电信科学, 2009 (10) :42-46.

组播技术应用 第7篇

随着数字技术和以IP技术为核心的网络技术的发展, 监控系统由原先封闭的模拟系统逐渐向开放和标准的数字化、IP化系统发展。IP网络、IP音视频应用及IPSAN存储等领域的IP智能监控应运而生。

IP视频监控方案其核心理念是以IP为基础架构, 实现基于IP的音视频信号传输和存储;同时提供对外的API接口, 以充分融合现有的监控系统, 保护用户现有投资, 以及方便第三方产品的继续开发1。

标准化和开放化带来了方案的灵活性, 同时也带来了效率提升、安全防护、对已有网络的适应性等方面的问题。本文要讨论的就是监控中碰到的常见组播组网设计问题。

1 IP监控组播模型

1.1 业务流的实现

IP监控系统的流量分为控制流和业务流, 业务流又可分为实况流、存储流和回放流。不考虑数据传输所需要的网络协议, 监控系统本身的控制流通常采用单播;存储流有可靠性要求, 一般基于TCP传输, 故也采用单播;回放流类似于VOD点播, 每个用户有各自的回放视频段需求, 一般也采用单播。只有实况流是所有用户对监控实际场景的同步实时接收, 可采用组播进行传输。

1.2 点播监控实况简化模型

1.2.1 摄像机与编码器

模型包含摄像机、编码器、控制服务器、媒体服务器、点播客户端五个角色。编码器负责对摄像机接收的视频图像进行编码, 并作IP封装后, 往外发送组播或单播流, 一个编码器可连接多个摄像机并同时为这些视频源进行编码和IP封装。每个编码器分配一个单播IP地址, 一个编码器所连接的多个摄像机各自分配一个组播IP地址, 如果共用一个组播IP就会导致多个点播客户端的点播信息出现混乱, 接收多余的组播流量, 从而浪费带宽并冲击点播客户端。摄像机和编码器共同构成组播源系统, 由于有多少个摄像机就有多少个组播源。

1.2.2 点播客户端

点播客户端可以是一台安装了监控系统音视频解码播放软件的PC机, 也可以是硬件解码的解码器, 前者可以在PC机上直接观看画面, 后者一般用于电视墙的播放。在组播实况模型来看, 可以统一为一个角色。

1.2.3 媒体服务器

媒体服务器是一个非常有用的角色, 它负责“单播至单播”、“单播至组播”、“组播至单播”“组播至组播”的转换和一对多的复制工作, 为监控媒体流的网络适应性和复制能力扩展性起到了非常关键的作用。

1.2.4 控制服务器

控制服务器负责对监控业务的各个流程进行协调和监管, 对编码器、点播客户端、媒体服务器、存储设备等系统部件进行注册管理和权限控制。

1.3 组播

1.3.1 组播技术

组播实况点播的大致流程为:点播客户端向控制服务器提交点播申请;控制服务器进行权限认证后通知编码器发送实况音视频流, 而后对于单播流则通知点播客户端打开端口接收音视频流, 对于组播流则通知点播客户端发送IGMP消息进行成员加入。必要的话可以通过媒体服务器进行转换, 即通知媒体服务器接收流并进行复制转发, 并通知点播客户端接收来自媒体服务器的音视频流2。

1.3.2 组播流的发送技术

编码器的实况组播流发送处理分为按需开播和永久开播两种方式。按需开播指摄像机只有在有客户点播的情况下才发送组播流;永久开播指即使没有客户点播, 摄像机的组播流也一直处于发送状态。按需开播相对比较节能, 且可避免可能存在的网络带宽浪费。永久开播的好处是当编码器因故重启恢复正常后, 客户端可以立即恢复实况流的接收, 而不需要等待编码器向控制服务器重新注册和控制服务器下发配置而重新开播。

2 组播接入

监控方案中, 摄像头数量众多, 编码器直接连接在核心设备上显然是不现实的, 比较经济合理的方式是对监控组网进行分层。典型的层次为:接入、汇聚、核心, 接入层负责二层组播交换, 汇聚层和核心层负责三层组播路由转发。实际组网可根据需求对层次进行裁减, 例如直接由汇聚层交换机连接编码器或客户端, 也可以在每一层次内根据需要进行多层级联。典型的模型如图2:

3 可靠与分担

3.1 安全与可靠组播

安全方面, 目前组播转发设备其转发表项容量普遍较小, 中端设备一般支持512至1K个表项, 高端设备一般支持K级或10K级个表项, 对于组播源数量庞大的监控系统来说, 设备的转发表项容量显得捉襟见肘。而且即便是核心设备的表项容量满足了组播源数量的要求, 边缘中低端设备的表项容量也时刻存在着不足的风险, 因为点播客户端进行组播源轮切会消耗大量的组播转发表项, 这些转发表项不会立即删除, 而需要过一段时间才会老化3。所以, 就整个监控系统来说, 组播转发表项永远是稀缺资源, 组播传输层面的安全主要是防止潜在攻击对转发表项的消耗而造成DOS攻击的效果。

监控系统中的控制服务器会对接入节点进行权限控制, 所以监控业务层面对于节点的接入具有一定的安全保障。但是组播是一个开放的系统, 攻击者模拟组播源接入系统就可以消耗DR路由器和RP路由器的表项, 攻击者模拟点播客户端接入系统就可以消耗从接入路由器到RP路由器之间的所有路由器的表项, 以及二层接入交换机的IGSP表项和接入路由器的IGMP表项。

所以从组播源端和组播接收端两方面进行限制。组播源方面, 接入设备需要对非法接入节点进行阻断, 不允许其接入, 同时禁止接收合法接入节点发送的非法组播流。组播接收端方面, 接入设备同样需要对非法接入节点进行阻断, 同时禁止接收合法接入节点权限之外的组播组加入请求。

可靠组播指的是组播所承载的业务的可靠性。监控的实况视频点播更追求实时性, 所以重传机制不值得推荐;在带宽允许的情况下, 实况流中携带前向纠错的冗余信息可以大大改善接收效果, 同时不会影响实时性。

3.2 BSR/RP备份与分担

在PIM SM协议中, BSR和RP是两个非常关键的角色, 这两个角色的备份和负荷分担设计是十分有意义的4。

BSR的备份可以通过在PIM协议域内配置多个候选BSRCandidate-BSR) 来实现。一旦某个BSR发生故障能够切换到另外一个。候选BSR通过自动选举产生BSR, 优先级高的候选BSR成为BSR, 优先级相同则选IP地址大的候选BSR成为BSR。

RP部署过多可能会使BSR负担过重, 此时需要进行BSR负载分担设计。

RP备份和负载分担设计的一种方法是通过在PIM-SM网络中配置多个候选RP (Candidate-RP) 来实现, 每个候选RP负责转发目的地址在一定范围内的组播报文, 配置多个候选RP可以实现RP的负载分担, 若一个RP失效, 其所负责的组播组可由其它RP继续承担。所有的组播路由器收到BSR通告的候选RP消息后, 可根据相同的哈希算法针对任一组播组计算出同一个RP。

RP备份和负载分担设计的另一种方法是在PIM-SM域内配置Anycast RP, 要求两台路由器之间建立MSDP对等体, 在两台路由器上分别配置向外发送SA消息所使用环回地址-两个地址不相同, 再在两台路由器上分别配置另一环回接口为候选RP, 并配置Anycast RP地址-两个地址相同, 以达到当有组播组成员加入时, 与主机直接相连的路由器能够向拓扑距离最近的RP发起加入的目的。

3.3 组网分担

对于组播网络, 除了组播流的转发流量, 设备支持的组播转发表项容量是一个关键瓶颈, 大部分设备的组播表项都远远少于单播表项。如果一个局点摄像机的数量不断增加, 持续升级设备肯定不是个好方法, 也保护不了现有的投资。此时需要进行组播转发设备的组网负荷分担设计, 既可降低成本保护投资, 又可提高网络的可靠性。

负荷分担设计需要关注以下几个方面:分担组播源;分担RP点的注册表项;分担点播接收者;分担组播流路径。

分担组播源:对于二层交换机, 若只连接组播源和三层转发设备, 由于没有IGMP加入, 则不会消耗其二层组播转发表项, 即IGSP表项;而三层转发设备则需要消耗 (S, G) 转发表项, 所以每台三层转发设备的本地组播源数量不应超过其三层组播转发表项的容量限制。

分担RP点:PIM SM协议中, RP点是一个重要的角色。连接组播源的DR路由器会向RP路由器进行源注册, 在RP点生成 (S, G) 表项。所以一台RP路由器其所服务的组播源数量不应超过其自身的三层组播转发表项容量。

分担点播接收者:连接组播点播者的二层交换机和三层转发设备都会消耗其转发表项, 所以连接二层交换机的点播者的组播组点播数量不应超过其二层转发表项, 连接三层转发设备的点播者的组播组点播数量不应超过其三层转发表项。

分担组播流路径:组播转发表项的负荷分担设计还需要关注组播转发路径的分担, 使组播转发表项数量不超过转发设备的容量限制。这需要进行仔细的网络规划, 充分考虑路由、STP、可靠性等相关因素。

4 NAT穿越

IPv4网络中NAT转换是组网经常碰到的情形。从监控业务的角度看, 可分为业务流直接穿越和VPN承载穿越两种方案。本节只讨论业务流直接穿越, 业务流直接穿越又有媒体服务器转换和直接穿越两种方案5。

对于数量有限的连接, 媒体服务器转换是一个比较好的解决方案。媒体服务器出两个接口, 一个在私网侧, 一个在公网侧, 负责公私网连接之间的相互转换;对于组播业务, 两个接口则分别担任点播者和组播源的角色。如此就可以旁路NAT设备, 不管组播流还是单播流, 都可以根据需要顺利地进行转换, 唯一的缺点是需要管理员静态配置, 可维护性不好。

可维护性比较好的方案还是通过NAT设备进行穿越。对于组播业务, 我们分“点播者在私网侧, 组播源在公网侧”和“点播者在公网侧, 组播源在私网侧”两种情形进行讨论。其中的控制服务器, 对于“点播者在私网侧, 组播源在公网侧”的情况, 可以放在公网或放在开启内部服务器功能的NAT设备的私网侧;对于“点播者在公网侧, 组播源在私网侧”的情况, 则控制服务器必须放在公网。

5 结束语

IP监控的业务模型对于组播来说具有很多新颖的业务特征, 给组播的组网设计和协议机制带来了独特的要求。虽然本文因篇幅所限无法面面俱到的展开讨论, 但在我司这几年监控产品的开发过程中, 研发人员针对组播业务在多个环节的实现细节中都提出了不少新颖的思路。相信随着产品和方案的不断成熟, 组播会成为IP监控产品实际开局应用中主要的业务传输模式。

参考文献

[1].吴恩平.基于SIP的IP视频终端的实现[D], 浙江大学, 2004.

[2].李炳彰.IP组播技术研究与实现[J].无线电通信技术.2005 (2)

[3].孙延涛, 吴志美, 石志强.基于地址转发表的交换式以太网拓扑发现方法[J].软件学报.2006 (12) .

[4].黄舒, 董喜明, 郭云峰.基于PIM-SM协议IP组播安全技术[J].计算机系统应用.2014 (6)