IP视频监控组播组网设计.docVIP

目 录Table of Contents 1 前言 5 2 IP监控组播模型 5 3 PIM模式选择 7 4 组播接入 8 4.1 点播客户端接入 8 4.2 编码器接入 9 4.3 无用组播流泛滥问题 10 5 可靠与分担 11 5.1 安全与可靠组播 11 5.2 BSR/RP备份与分担 11 5.3 组网分担 12 6 单组播转换 14 7 NAT穿越 14 8 VPN承载 15 8.1 GRE 16 8.2 L2TP 16 8.3 IPSEC 18 8.4 DVPN隧道 19 8.5 SSL VPN隧道 20 8.6 MPLS VPN 20 9 结束语 21 前言 随着数字技术和以IP技术为核心的网络技术的发展，监控系统由原先封闭的模拟系统逐渐向开放和标准的数字化、IP化系统发展。乘着这股东风，我司基于自身在IP网络、IP音视频应用及IP SAN存储等领域的长期技术积累，在IToIP解决方案理念的指导下，顺理成章的推出了iVS（IP Video Surveillance）IP智能监控解决方案，成为主流的高端监控设备提供商。 IP视频监控方案其核心理念是以IP为基础架构，实现基于IP的音视频信号传输和存储，从而实现标准、开放、高质的IP化解决方案；同时提供对外的API接口，以充分融合现有的监控系统，保护用户现有投资，以及方便第三方产品的继续开发。从而快速提升自身在监控系统中的核心地位，提高市场占用率。 标准化和开放化带来了方案的灵活性，同时也带来了效率提升、安全防护、对已有网络的适应性等方面的问题。本文要讨论的就是其中的一个数据传输问题：组播。限于篇幅，我们不准备穷尽所有的组播组网技术，只探讨目前监控实际开局中碰到的常见组播组网设计问题。 IP监控组播模型 IP监控系统的流量分为控制流和业务流，业务流又可分为实况流、存储流和回放流。不考虑数据传输所需要的网络协议，监控系统本身的控制流通常采用单播；存储流有可靠性要求，一般基于TCP传输，故也采用单播；回放流类似于VOD点播，每个用户有各自的回放视频段需求，一般也采用单播。只有实况流是所有用户对监控实际场景的同步实时接收，可采用组播进行传输。后续我们的组播组网设计都将针对实况流。 目前国内主流的监控系统（我司销售量最高的行业监控的方案架构与此类似）的实况流模型如下图——为方便聚焦组播核心主题，我们省略了与实况流无关的其他部件，例如存储设备等，对模型适当作了下简化： IP监控实况简化模型 模型包含摄像机、编码器、控制服务器、媒体服务器、点播客户端五个角色。 编码器负责对摄像机接收的视频图像进行编码并作IP封装往外发送组播或单播流，一个编码器可连接多个摄像机并同时为这些视频源进行编码和IP封装。每个编码器分配一个单播IP地址，一个编码器所连接的多个摄像机各自分配一个组播IP地址——如果共用一个组播IP就会导致多个点播客户端的点播信息出现混乱，接收多余的组播流量，从而浪费带宽并冲击点播客户端。摄像机和编码器共同构成组播源系统，有多少个摄像机就有多少个组播源，为描述方便，后面我们提组播源就直接说摄像机了。 点播客户端可以是一台安装了监控系统音视频解码播放软件的PC机，也可以是硬件解码的解码器，前者可以在PC机上直接观看画面，后者一般用于电视墙的播放。在组播实况模型来看，可以统一为一个角色。 媒体服务器是一个非常有用的角色，它负责“单播至单播”、“单播至组播”、“组播至单播” “组播至组播”的转换和一对多的复制工作，为监控媒体流的网络适应性和复制能力扩展性起到了非常关键的作用。 控制服务器负责对监控业务的各个流程进行协调和监管，对编码器、点播客户端、媒体服务器、存储设备等系统部件进行注册管理和权限控制。 组播实况点播的大致流程为：点播客户端向控制服务器提交点播申请；控制服务器进行权限认证后通知编码器发送实况音视频流，而后对于单播流则通知点播客户端打开端口接收音视频流，对于组播流则通知点播客户端发送IGMP消息进行成员加入。必要的话可以通过媒体服务器进行转换，即通知媒体服务器接收流并进行复制转发，并通知点播客户端接收来自媒体服务器的音视频流。 编码器的实况组播流发送处理分为按需开播和永久开播两种方式。按需开播指摄像机只有在有客户点播的情况下才发送组播流；永久开播指即使没有客户点播，摄像机的组播流也一直处于发送状态。按需开播相对比较节能，且可避免可能存在的网络带宽浪费。永久开播的好处是当编码器因故重启恢复正常后，客户端可以立即恢复实况流的接收，而不需要等待编码器向控制服务器重新注册和控制服务器下发配置而重新开播。 IP视频监控系统模型通常是摄像机的数量众多——可能达到10K级别，而点播客户端的数量则较少——一般为两位数以下。这些摄像机和点播客户端往往按照地域的行政划分而分属于不同的