IP视频监控组播组网设计.docx
- 文档编号:14889018
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:20
- 大小:82.48KB
IP视频监控组播组网设计.docx
《IP视频监控组播组网设计.docx》由会员分享,可在线阅读,更多相关《IP视频监控组播组网设计.docx(20页珍藏版)》请在冰点文库上搜索。
IP视频监控组播组网设计
目录TableofContents
1前言
随着数字技术和以IP技术为核心的网络技术的发展,监控系统由原先封闭的模拟系统逐渐向开放和标准的数字化、IP化系统发展。
乘着这股东风,我司基于自身在IP网络、IP音视频应用及IPSAN存储等领域的长期技术积累,在IToIP解决方案理念的指导下,顺理成章的推出了iVS(IPVideoSurveillance)IP智能监控解决方案,成为主流的高端监控设备提供商。
IP视频监控方案其核心理念是以IP为基础架构,实现基于IP的音视频信号传输和存储,从而实现标准、开放、高质的IP化解决方案;同时提供对外的API接口,以充分融合现有的监控系统,保护用户现有投资,以及方便第三方产品的继续开发。
从而快速提升自身在监控系统中的核心地位,提高市场占用率。
标准化和开放化带来了方案的灵活性,同时也带来了效率提升、安全防护、对已有网络的适应性等方面的问题。
本文要讨论的就是其中的一个数据传输问题:
组播。
限于篇幅,我们不准备穷尽所有的组播组网技术,只探讨目前监控实际开局中碰到的常见组播组网设计问题。
2IP监控组播模型
IP监控系统的流量分为控制流和业务流,业务流又可分为实况流、存储流和回放流。
不考虑数据传输所需要的网络协议,监控系统本身的控制流通常采用单播;存储流有可靠性要求,一般基于TCP传输,故也采用单播;回放流类似于VOD点播,每个用户有各自的回放视频段需求,一般也采用单播。
只有实况流是所有用户对监控实际场景的同步实时接收,可采用组播进行传输。
后续我们的组播组网设计都将针对实况流。
目前国内主流的监控系统(我司销售量最高的行业监控的方案架构与此类似)的实况流模型如下图——为方便聚焦组播核心主题,我们省略了与实况流无关的其他部件,例如存储设备等,对模型适当作了下简化:
IP监控实况简化模型
模型包含摄像机、编码器、控制服务器、媒体服务器、点播客户端五个角色。
编码器负责对摄像机接收的视频图像进行编码并作IP封装往外发送组播或单播流,一个编码器可连接多个摄像机并同时为这些视频源进行编码和IP封装。
每个编码器分配一个单播IP地址,一个编码器所连接的多个摄像机各自分配一个组播IP地址——如果共用一个组播IP就会导致多个点播客户端的点播信息出现混乱,接收多余的组播流量,从而浪费带宽并冲击点播客户端。
摄像机和编码器共同构成组播源系统,有多少个摄像机就有多少个组播源,为描述方便,后面我们提组播源就直接说摄像机了。
点播客户端可以是一台安装了监控系统音视频解码播放软件的PC机,也可以是硬件解码的解码器,前者可以在PC机上直接观看画面,后者一般用于电视墙的播放。
在组播实况模型来看,可以统一为一个角色。
媒体服务器是一个非常有用的角色,它负责“单播至单播”、“单播至组播”、“组播至单播”“组播至组播”的转换和一对多的复制工作,为监控媒体流的网络适应性和复制能力扩展性起到了非常关键的作用。
控制服务器负责对监控业务的各个流程进行协调和监管,对编码器、点播客户端、媒体服务器、存储设备等系统部件进行注册管理和权限控制。
组播实况点播的大致流程为:
点播客户端向控制服务器提交点播申请;控制服务器进行权限认证后通知编码器发送实况音视频流,而后对于单播流则通知点播客户端打开端口接收音视频流,对于组播流则通知点播客户端发送IGMP消息进行成员加入。
必要的话可以通过媒体服务器进行转换,即通知媒体服务器接收流并进行复制转发,并通知点播客户端接收来自媒体服务器的音视频流。
编码器的实况组播流发送处理分为按需开播和永久开播两种方式。
按需开播指摄像机只有在有客户点播的情况下才发送组播流;永久开播指即使没有客户点播,摄像机的组播流也一直处于发送状态。
按需开播相对比较节能,且可避免可能存在的网络带宽浪费。
永久开播的好处是当编码器因故重启恢复正常后,客户端可以立即恢复实况流的接收,而不需要等待编码器向控制服务器重新注册和控制服务器下发配置而重新开播。
IP视频监控系统模型通常是摄像机的数量众多——可能达到10K级别,而点播客户端的数量则较少——一般为两位数以下。
这些摄像机和点播客户端往往按照地域的行政划分而分属于不同的管理区域,而点播客户端有跨管理域点播的需求。
由于IP视频监控是一个开放标准化的体系,业务传输往往基于客户已有的网络,需要与客户现有的业务一起运行,而不能随意更改现有的网络架构。
基于上面的IP监控组播实况点播模型,我们来探讨IP监控的组播组网设计
3PIM模式选择
PIM协议是目前主流的组播路由协议,IP监控方案的实况组播组网以PIM作为组播路由协议。
PIM协议有DM、SM、SSM和Bidir-PIM四种运行模式,每一种模式有其各自的适用环境。
PIMDM模式以协议域中所有客户端缺省希望接收组播流为预期假设,路由器往所有使能PIM协议的接口转发组播流,如果某些接口没有接收的需求,则剪枝掉这些分支。
这种模式比较适合远程教育、广播等应用场合,但不适合IP监控的实况点播——DM模式会浪费路由设备大量的转发表项和造成不必要的流量冲击。
Bidir-PIM模式中,组播源的业务流被无条件的转发往RP,再由RP向多个客户机进行转发。
它不需求源注册过程,省去了路由设备对大量组播源进行源状态管理的资源消耗。
在Bidir-PIM协议域中只存在(*,G)表项,而不需要(S,G)表项,从而大大减轻了设备对组播转发表项的维护。
Bidir-PIM特别适合组播终端既为组播源又为接收客户端的应用,例如多方电视电话会议,但这种模式显然也不适合IP监控的实况点播——监控点播客户端只需要选择性的观看某些摄像机画面,而不是同时观看所有的摄像机画面,Bidir-PIM模式会造成带宽资源浪费。
PIMSM模式要求业务接收者根据组播组信息申请想要接收的业务流,路由器根据其申请的组播组转发对应的业务流。
它的机制比较复杂:
需要连接组播源的路由器向汇合点RP发送源注册,以表明目前有这个源在提供这个组播组的业务;需要连接客户机的路由器一跳一跳的向汇合点RP申请接收该组播组的业务流;这两个过程是相互独立的。
最后由RP转发组播业务流,为组播源和接收客户牵线搭桥。
PIMSM是一个应用广泛、机制灵活的协议,对于IP监控与其他组播业务共用的网络环境,PIMSM模式是一个比较好的选择。
PIMSSM模式适合组播源的源IP和组地址都明确的应用。
客户端使用IGMPV3或提供类似功能的其他协议向自己直连的组播路由器发送指定组播源的组加入申请。
由于预先知道组播源的地址,所以可以直接获得来自组播源的业务流,免去了SM模式中组播源向RP进行源注册的过程。
这种模式非常适合IP监控的实况点播,因为对应摄像机的源IP和组地址都可以从控制服务器获得。
相对于SM模式其优势非常明显:
免去了SM模式中的RP、BSR等功能角色,减少了潜在的故障点;免去了源注册过程和PIMSM的SPT切换过程,保证组播流路径最优的同时减少了协议交互的过程;可大量节省组播组地址,若一个编码器最多支持N个摄像机,就只需要N个组播组地址;此外,在永久开播的情况下,控制服务器的协调和监管流程也可以大大简化,提高点播效率。
后面的讨论中,我们还可以看到SSM模式带来的其他更多的好处。
综上所述,对于IP监控,PIMSSM协议的运行效率最高,PIMSM的灵活性最好——毕竟大部分应用和路由设备仅支持IGMPV1和V2。
我司IP监控方案目前仅支持PIMSM模式,后续的讨论若无特指,则缺省以SM模式为背景。
4组播接入
监控方案中,摄像头数量众多,编码器直接连接在核心设备上显然是不现实的,比较经济合理的方式是对监控组网进行分层。
典型的层次为:
接入、汇聚、核心,接入层负责二层组播交换,汇聚层和核心层负责三层组播路由转发。
实际组网可根据需求对层次进行裁减,例如直接由汇聚层交换机连接编码器或客户端,也可以在每一层次内根据需要进行多层级联。
典型的模型如下图:
监控组网层次图
4.1点播客户端接入
点播客户端可以连接在二层接入交换机上,也可以直接连接在三层设备上。
设计时需要注意的是应避免让点播客户端收到无关的组播流,否则会冲击点播客户端,干扰正常音视频流的播放。
直连点播客户端的设备应开启IGMP或IGSP协议的快速离开特性。
IGMP和IGSP协议的正常处理机制要求查询器在收到IGMP离开消息时发送IGMP特定组查询报文以确认该端口下是否还存在有点播需求的客户端机。
此机制会导致点播客户端在切换摄像机时前一个摄像机的“残留”组播流冲击点播者,干扰新视频流的正常播放。
由于边缘设备一个端口只会连接一台点播客户端,所以查询器没有必要发送确认消息,快速离开特性让IGSP交换机和IGMP设备在收到IGMP离开消息后不再发送IGMP特定组查询报文而立即将该端口(接口)从出接口集合中删除,消除“残留”组播流。
连接点播客户端的VLAN应开启IGSP特性。
当一个客户端点播了摄像机,IGSP特性可使对应组播流只往点播了该组播流的客户端和路由器端口转发,而避免冲击VLAN内的其他客户端。
当点播客户端与组播源同处一个VLAN时,该VLAN除了开启IGSP特性,还应开启“Nonflooding”或“未知组播丢弃”特性,以免无关组播流冲击点播客户端——这个问题在两种情况下会出现:
组播源永久开播的时候以及组播源按需开播但被其他网络的客户端点播时候,此时该组播流对于未点播的本地客户端来说就是无关组播流。
两个特性均可使组播流避免在本地客户端未点播的情况下广播,唯一的区别是在本地客户端未点播的情况下前者使组播流可以向路由器端口转发而后者完全丢弃组播流。
当本地客户端点播的时候两个特性均可使组播流向路由器端口和点播了的客户端转发。
前者适用于二层网络连接路由器且其他网络存在点播客户端的情况——因为PIMSM协议的DR路由器需要收到组播流才能向RP进行源注册,其他网络的客户端才能点播到组播流;后者适用于没有路由器或者路由器的其他网络不存在点播客户端的情形。
当点播客户端和组播源连接在同一台二层交换机,而二层组播交换机不支持“Nonflooding”或“未知组播丢弃”特性的时候,此时可将组播源和点播客户端分别划分到两个VLAN内,两者可通过上行三层设备进行PIM路由互访。
4.2编码器接入
普通编码器的各个端口用来发送单组播的音视频流;带存储功能的编码器的端口或者用来发送单组播流或者专门用来接收单播流提供存储功能。
组播组网设计时要避免发送组播流的端口受到其他组播流的冲击,造成不必要的资源消耗。
所以当多个编码器端口连在同一个VLAN时,交换机需要对这些端口进行隔离,但同时这些端口需要与其他端口进行互通。
一种比较理想的方法是采用端口隔离组。
隔离组内的各个端口相互隔离,而与非隔离组的其他端口可以相互通信。
如果VLAN内同时连接了点播客户端,设计时需满足上一节的要求。
另一种方法是配置静态IGSP表项进行组播流的隔离。
如果每个端口要发出的组播流的组地址可预知,则可以在VLAN内配置静态IGSP表项,将这些发送端口配置为对应组播组的成员端口。
如果连接了路由器则需配置静态IGSP路由器端口。
如果VLAN内同时还连接了点播客户端,设计时需满足上一节的要求。
此外还有一种方法是将各个编码器端口划分到不用的VLAN中,实现业务流的二层隔离。
编码器端口与点播客户端的通信采用上行三层设备PIM转发。
这个方案要求各个编码器端口的IP编址使用不同的网段,比较消耗VLAN和IP资源。
实际组网设计可根据需要灵活采用上述的三种方法。
4.3无用组播流泛滥问题
当组播源和点播者同时连接在一台二层组播交换机的同一个VLAN时,当本地点播者点播了组播源,组播流就会向成员端口和路由器端口转发。
此时,虽然上行PIM路由器的其他网络的点播客户端未曾点播组播源,组播流也会占用二层组播交换机连接上行PIM路由器的通道。
当本地点播客户端点播了一定数量的组播源,这些组播流对该通道的带宽占用就会比较可观,如果这个通道带宽较小就会导致远端点播客户端无法正常点播其所需要的组播源。
此时,这些组播流似乎显得“无用”,然而这些“无用”的组播流对于PIM协议的运行却是必须的——PIMSM的DR得依靠这些组播流知道组播信息,其他模式的PIM协议也各有需求。
这个问题比较合适的解决方案是:
上行的PIM路由器在连接组播源的接口上禁止PIM消息和IGMP通用查询消息的发送,并在该接口上启用IGMP加入/离开消息与PIM表项的联动功能,即当PIM路由器生成PIM表项时往该接口发送对应组的IGMP加入消息,否则发送IGMP离开消息。
此时PIM协议的模式最好选择SSM模式,DR路由器具体运作过程是:
当DR收到(S,G)PIM加入消息生成(S,G)转发表项时,根据S找到对应的出接口,在该接口上周期性发送IGMP加入消息;当DR的(S,G)转发表项消失,则在该接口上发送IGMP离开消息。
——如果采用SM模式,这个上行PIM路由器必须是RP路由器,而且必须往所有配置了联动功能的接口发送IGMP加入或离开消息,这就缺乏可扩展性了。
如此,二层组播交换机将只往上行PIM路由器发送需要的组播流,可比较完善的解决这个问题。
上行PIM路由器若不支持上述特性,则可行的解决方案是:
一、扩大通道带宽;二、将二层交换机更改为三层交换机,进行三层组播接入。
5可靠与分担
5.1安全与可靠组播
安全方面,我们这里主要探讨下组播传输层面的问题。
目前业界的组播转发设备其转发表项容量普遍较小,中端设备一般支持512至1K个表项,高端设备一般支持K级或10K级个表项,对于组播源数量庞大的监控系统来说,设备的转发表项容量显得捉襟见肘。
而且即便是核心设备的表项容量满足了组播源数量的要求,边缘中低端设备的表项容量也时刻存在着不足的风险,因为点播客户端进行组播源轮切会消耗大量的组播转发表项,这些转发表项不会立即删除,而需要过一段时间才会老化。
所以,就整个监控系统来说,组播转发表项永远是稀缺资源,组播传输层面的安全主要是防止潜在攻击对转发表项的消耗而造成DOS攻击的效果。
监控系统中的控制服务器会对接入节点进行权限控制,所以监控业务层面对于节点的接入具有一定的安全保障。
但是组播是一个开放的系统,攻击者模拟组播源接入系统就可以消耗DR路由器和RP路由器的表项,攻击者模拟点播客户端接入系统就可以从消耗接入路由器到RP路由器之间的所有路由器的表项,以及二层接入交换机的IGSP表项和接入路由器的IGMP表项。
所以我们从组播源端和组播接收端两方面进行限制。
组播源方面,接入设备需要对非法接入节点进行阻断,不允许其接入,同时禁止接收合法接入节点发送的非法组播流。
组播接收端方面,接入设备同样需要对非法接入节点进行阻断,同时禁止接收合法接入节点权限之外的组播组加入请求。
可靠组播指的是组播所承载的业务的可靠性,目前业界有多种方案。
监控的实况视频点播更追求实时性,所以重传机制不值得推荐;在带宽允许的情况下,实况流中携带前向纠错的冗余信息可以大大改善接收效果,同时不会影响实时性。
目前我司监控不支持可靠组播,在此不详细展开讨论。
5.2BSR/RP备份与分担
在PIMSM协议中,BSR和RP是两个非常关键的角色,这两个角色的备份和负荷分担设计是十分有意义的。
BSR的备份可以通过在PIM协议域内配置多个候选BSR(Candidate-BSR)来实现。
一旦某个BSR发生故障能够切换到另外一个。
候选BSR通过自动选举产生BSR,优先级高的候选BSR成为BSR,优先级相同则选IP地址大的候选BSR成为BSR。
RP部署过多可能会使BSR负担过重,此时需要进行BSR分担设计。
分担可按照网络空间区域进行划分,也可以按照所服务的组播组地址进行划分。
按照空间区域进行划分,需配置BSR边界,此时每个BSR仅为自己区域的PIM路由器服务,每个区域内可以设置多个候选BSR进行备份,域间的组播点播需由MSDP/MBGP协议负责传播组播源信息。
按照组播组地址进行划分,需配置BSR管理域,此时每个BSR只为自己的组播组地址服务,每个BSR管理域内可以配置多个候选BSR进行备份。
BSR管理域的设计思想导致域间组播的点播需求无法实现,此时需要媒体服务器负责进行组播流的组播组地址转换。
RP备份和分担设计的一种方法是通过在PIM-SM网络中配置多个候选RP(Candidate-RP)来实现,每个候选RP负责转发目的地址在一定范围内的组播报文,配置多个候选RP可以实现RP的负载分担,若一个RP失效其所负责的组播组可由他RP可以继续承担。
所有的组播路由器收到BSR通告的候选RP消息后,可根据相同的哈希算法针对任一组播组计算出同一个RP。
RP备份和分担设计的另一种方法是在PIM-SM域内配置AnycastRP,要求两台路由器之间建立MSDP对等体,在两台路由器上分别配置向外发送SA消息所使用环回地址——两个地址不相同,再在两台路由器上分别配置另一环回接口为候选RP,并配置AnycastRP地址——两个地址相同,以达到当有组播组成员加入时,与主机直接相连的路由器能够向拓扑距离最近的RP发起加入的目的。
5.3组网分担
对于组播网络,除了组播流的转发流量,设备支持的组播转发表项容量是一个关键瓶颈——大部分设备的组播表项都远远少于单播表项。
如果一个局点摄像机的数量不断增加,持续升级设备肯定不是个好方法,也保护不了现有的投资。
此时需要进行组播转发设备的组网负荷分担设计,既可降低成本保护投资,又可提高网络的可靠性。
负荷分担设计需要关注以下几个方面:
分担组播源;分担RP点的注册表项;分担点播接收者;分担组播流路径。
分担组播源:
对于二层交换机,若只连接组播源和三层转发设备,由于没有IGMP加入,则不会消耗其二层组播转发表项,即IGSP表项;而三层转发设备则需要消耗(S,G)转发表项,所以每台三层转发设备的本地组播源数量不应超过其三层组播转发表项的容量限制。
分担RP点:
PIMSM协议中,RP点是一个重要的角色。
连接组播源的DR路由器会向RP路由器进行源注册,在RP点生成(S,G)表项。
所以一台RP路由器其所服务的组播源数量不应超过其自身的三层组播转发表项容量。
分担点播接收者:
连接组播点播者的二层交换机和三层转发设备都会消耗其转发表项,所以连接二层交换机的点播者的组播组点播数量不应超过其二层转发表项,连接三层转发设备的点播者的组播组点播数量不应超过其三层转发表项。
分担组播流路径:
组播转发表项的负荷分担设计还需要关注组播转发路径的分担,使组播转发表项数量不超过转发设备的容量限制。
这需要进行仔细的网络规划,充分考虑路由、STP、可靠性等相关因素。
一个典型的运行PIMSM协议的组播组网负荷分担案例:
某局点的摄像机数量达到1100个,核心交换机选择75E,接入设备选择S3600SI或者S3600EI。
分析:
一台75E的三层组播表项为1024个,所以考虑用两台75E进行核心层的负荷分担,分别承接550个摄像机,同时为各自的550个组播组提供RP服务;摄像机众多而75E端口有限,考虑成本计,采用S3600SI进行二层接入。
点播PC采用S3600EI进行三层接入——若采用S3600SI进行二层接入存在诸多问题,因分析较繁琐此处不再详述;监控客户端软件支持同时点播16路摄像机,而一台S3600EI只支持256个三层转发表项,所以一台S3600EI所连接的点播PC不应超过16台。
组网如下:
组网分担案例组网图
功能配置如下:
1、使用S3600SI作为编码器的二层接入,开启IGSP+Nonflooding+端口隔离;
2、使用S3600EI作为点播PC机的三层接入,开启PIMSM+IGMP+快速离开;每台3600EI连接PC的数量不超过16台;
3、两台75E(如果为了降低成本,也可以是一台75,另一台为低端三层转发设备,此时75E所承担的摄像机可多一些,低端三层转发设备所连接的摄像机可少一些)作为核心设备,开启PIMSM+RP+BSR功能;每台75E各承担550台摄像机;每台75成为候选BSR;每台75都作为RP,但只为自己承担的组播源的组播组服务。
6单组播转换
用户现场的网络情形纷繁复杂,可能有些网络不适合运行组播,这段网络可能处在组播源侧,可能处在部分点播客户端侧。
一个方法是让编码器同时发送单播和组播实况流,但这对于带宽紧张的链路可能无法承受,对于编码器的压力也很大——因为它需要为每一个无法进行组播点播的客户端生成单播流。
此外支持组播的网络情况也不简单。
例如在多个管理域的网络中,域管理员可能会使用组播地址239.X.X.X/8来控制业务流不超出域边界,也可能使用TTL值进行组播流传播范围的控制,于是其他域的点播者就无法进行域间点播;同一个管理域也可能因为划分了BSR管理域而无法实现域间的组播点播。
此时前面提到的媒体服务器就有用武之地了,它可以提供“单播流-单播流”、“单播流-组播流”、“组播流-单播流”、“组播流-组播流”的业务流转换服务和一对多的业务流复制。
它拥有多个接口,可以跨越不同的网络,从而可十分灵活的解决IP监控组网所碰到的各种问题。
7NAT穿越
IPv4网络中NAT转换是组网经常碰到的情形。
从监控业务的角度看,可分为业务流直接穿越和乘坐VPN穿越两种方案。
本节我们先讨论前者,后者在下章中详细讨论。
业务流直接穿越又有媒体服务器转换和直接穿越两种方案。
对于数量有限的连接,媒体服务器转换是一个比较好的解决方案。
媒体服务器出两个接口,一个在私网侧,一个在公网侧,负责公私网连接之间的相互转换;对于组播业务,两个接口则分别担任点播者和组播源的角色。
如此就可以旁路NAT设备,不管组播流还是单播流,都可以根据需要顺利地进行转换,唯一的缺点是需要管理员静态配置,可维护性不好。
可维护性比较好的方案还是通过NAT设备进行穿越。
对于组播业务,我们分“点播者在私网侧,组播源在公网侧”和“点播者在公网侧,组播源在私网侧”两种情形进行讨论。
其中的控制服务器,对于“点播者在私网侧,组播源在公网侧”的情况,可以放在公网或放在开启内部服务器功能的NAT设备的私网侧;对于“点播者在公网侧,组播源在私网侧”的情况,则控制服务器必须放在公网——目前我司方案的实现是控制服务器通过消息内部字段告诉点播客户端自己的IP地址,让客户端按照这个地址查询数据库,由于是私网地址,公网的点播者无法寻址。
点播者在私网侧,组播源在公网侧,可采用如下几个方案。
方案一:
NAT设备两侧均运行PIMSSM协议。
方案二:
NAT设备两侧均运行PIMSM协议,BSR和RP处公网侧——因为候选RP地址包含在候选RP通告消息里。
方案三:
NAT设备私网接口运行PIMSM和IGMP协议,私网侧其他设备运行IGMP或IGMPPROXY协议,公网接口及公网侧其他设备运行PIMSM协议,BSR和RP处公网侧。
方案四:
NAT设备运行IGMPPROXY协议,公网接口为私网接口做IGMP代理,公网侧的其他设备运行PIM协议,BSR和RP处公网侧。
点播者在公网侧,组播源在私网侧。
此时公网侧的其他设备不能运行PIM协议,因为DR发出的组播源注册消息里包含了数据包,其组播源地址是一个私网地址,如果RP在公网,RP到DR的SPT树则无法建立,如果RP在私网,公网侧的PIM设备则无法访问RP。
方案一:
NAT设备公网接口运行PIMSM和IGMP协议,公网侧其他设备运行IGMP和IGMPPROXY协议,NAT私网接口及私网侧的其他设备运行PIMSM协议,RP/BSR放置在私网侧。
方案二:
NAT设备运行IGMPPROXY协议,私网接口为公网接口做IGMP代理,私网侧的其他设备运行PIMSM协议,RP/BSR放置在私网侧。
8VPN承载
用户的网络纷繁复杂,需求也多样化,加上安全性要求,VPN是一个比较好的组网方式,可以使网络的具体实现对监控业务透明化。
但是VPN也会带来封装的消耗,而往往需要VPN封装的网络
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IP 视频 监控 组网 设计