快速收敛范文

快速收敛范文（精选4篇）

快速收敛 第1篇

RSTP运行的前提条件必须是在点对点的物理网段上进行, 也就是说必须是交换机接口直接相连, 物理网段上只有两方, 中间不允许有集线器等设备。

2 RSTP端口状态介绍

1) Discarding (丢弃) 状态:能够发送和接收BPDU报文, 不能发送和接收数据报文, 不能进行MAC地址学习。

2) Learning (学习) 状态:能够发送和接收BPDU报文, 不能发送和接收数据报文, 能进行MAC地址学习。

3) Forwarding (转发) 状态:能够发送和接收BPDU报文, 能发送和接收数据报文, 能进行MAC地址学习。

3 RSTP端口角色介绍

1) 根端口:非根交换机上具有到根交换机最小路径开销的端口为根端口。

2) 指定端口:每个交换网段上的具有最小路径开销的端口为指定端口, 且每个物理网段上只有一个指定端口, 根交换机上的每个端口都为指定端口。

3) 替代端口:对根端口的备份, 根端口中断时替代端口将取代根端口。

4) 备份端口:备份端口是对指定端口的备份, 即提供了到同一交换网段的冗余连通性。

5) 边缘端口:连接终端设备的端口。

4 RSTP的报文结构

RSTPBPDU的数据报文结构大体上跟STPBPDU报文结构差不多, RSTPBPDU也是有协议号、报文类型、标记、根交换机ID、根路径开销、发送交换机ID、端口ID、message age、max age、hello time、Forwarddelay等相关参数。端口角色:

00未知

01根端口

11指定端口

RSTP是通过BPDU中的建议位和同意位来进行主动协商的, 从而使得RSTP快速收敛。

5 RSTP的快速收敛机制

5.1 边缘端口快速收敛

边缘端口是直接与终端设备相连的端口, 而且不会引起拓扑的变更。与STP相比, RSTP的边缘端口不需要经过转发时延直接进入转发状态, 直接跳过了监听和学习状态的时间。RSTP里面的边缘端口与思科的Port Fast, 边缘端口收到BPDU报文后, 就好立即失去边缘端口的特性而转变成非边缘端口。

5.2 根端口快速收敛

在STP中, 只有根交换机能通过指定端口主动发送BPDU报文, 其他非根交换机只能通过根端口被动地接收BPDU报文, 因此, 如果根交换机与下游的非根交换机的链路发生故障时, STP中的交换机也不能及时的发现, 而是要经过20秒的老化时间后才能发现链路的故障。而在RSTP中, 根交换机会每隔一个Hello Time (默认2秒) 下发一次BPDU报文, 同时非根交换机也会每隔Hello Time也会发送带有自己信息的BPDU报文, 如果经过三个Hello Time后, 非根交换机没有收到根交换机发来的BPDU报文, 则认为根交换机与它下游的这个非根交换机的链路发生故障, 所以RSTP发现链路故障的时间事三个Hello Time, 也就是6秒, 相对于STP要快得多。因此, 根端口发生故障时, 根端口的备份端口即替代端口不需要进过转发时延而直接进入到转发状态。同样, 当指定端口异常时, 备份端口也会直接进入转发状态。

5.3 RSTP的P/A协商机制

RSTP的P/A协商机制即Proposal/Agreement机制。它的目的是为了加快指定端口从丢弃状态到转发状态的时间。P/A协商机制相对于STP的收敛来说快速了很多, 因为它不依靠任何的计时器, 只是将这一机制快速地向网络边缘扩散, 并且在网络拓扑改变后迅速进入到转发状态。下面就介绍一下P/A协商机制的工作原理:

1) 交换机之间相互交换BPDU报文, 通过BPDU报文中的交换机ID选出根交换机;

2) 选出各交换机的端口角色;

3) 根交换机与下端的交换机A的链路激活后, 它们两个相连的端口就会立刻进入阻塞状态, 然后根交换机的指定端口发送P制位的BPDU报文, 一旦交换机A收到根交换机发送的BPDU报文后, 就会将交换机的所有指定接口都切换到丢弃状态, 但替代端口、备份端口、边缘端口状态不变, 这个过程叫做同步。当交换机A的所有非边缘端口都阻塞完成后, 即同步过程完成, 交换机A打开它的根端口并且向根交换机发送A制位的BPDU报文, 一旦根交换机的指定端口收到A交换机发送的A制位的BPDU报文后, 根交换机的指定端口立刻进入转发状态。

5.4 拓扑变更快速收敛

拓扑变更的触发条件:非边缘端口转变为转发状态。

感知拓扑变更的交换机会主动发送TC置位的BPDU报文, 而不是由根交换机发送。交换机A一旦感知到拓扑变化, 便会采取以下措施:交换机A会在两倍Hello Time内向指定端口和根端口发送TC置位的BPDU报文, 如果超过了两倍的Hello Time就会停止发送TC置位的BPDU报文。收到TC置位的BPDU报文的交换机B会清除除了收到TC置位的BPDU报文的根端口和指定端口的MAC地址, 除此之外, 交换机B还会在两倍Hello Time内向指定端口和根端口发送TC置位的BPDU报文给其他交换机, 重复这一过程, 这样网络中就会产生TC置位的BPDU报文的洪泛。

6 结束语

RSTP是一种网络拓扑结构形成树形结构的协议, 在协议实现的过程中通过协议运算, 来阻断冗余链路从而消除网络中存在的环路, 当链路发送故障时又激活冗余备份链路来恢复网络的连通性。本文主要介绍了RSTP的几种快速收敛机制, 相对于STP, RSTP在收敛速度上还是有很大的提高, 理论上RSTP的收敛时间可以达到秒级。但是RSTP也有它的局限性, 虽然现在的交换机支持快速生成树协议, 但是还是有部分交换机支持生成树协议, 两种协议不能兼容, 如果在一组交换几种有的配置生成树协议, 有的支持快速生成树协议, 则这一组交换机会全部运行生成树协议。

摘要：随着人们对网速需求的不断提升, STP (生成树协议) 收敛速度过慢使得RSTP (快速生成树协议) 应运而生, RSTP是一种在STP基础之上做了更加细致的修改与补充从而能够弥补STP收敛时间过慢的二层协议。RSTP是由IEEE委员会制定的IEEE802.1w标准。本文先简单的介绍RSTP的端口状态和端口角色, 后面再详细地介绍RSTP几种快速收敛机制。

刍议BGP/VPN快速收敛技术 第2篇

在一个MPLS/VPN网络中，通常在两个PE之间建立IBGP邻居，用来交换VPN私网路由，此私网路由的下一跳为PE设备；另外，还需要在物理直连的PE-P、P-P之间建立IGP/LDP邻居，从而建立外层隧道。而最终VPN路由转发表项，则需要将VPNBGP路由的远端下一跳和IGP/LDP外层隧道进行迭代，生成最终的VPN FIB表项，以此来指导PE设备上VPN业务的转发。

当MPLS/VPN网络中发生各种故障后，首先进行公网IGP/LDP路由的收敛，这个收敛在使用IGP/LDP快速收敛技术后，通常可以达到200ms-800ms左右的收敛速度。IGP/LDP收敛之后，新的外层隧道生成，同时原先旧的外层隧道删除，此时所有的BGP/VPN路由需要重新迭代一次，迭代到新的外层隧道后，下发到转发平面，此时VPN业务才能最终收敛。这个收敛迭代时间和VPN的路由数目成正比关系。在VPN路由数目比较多的情况下，通常需要几秒甚至几十秒钟才能完成。

2 关键技术

2.1 P设备IGP/LSP更新

在MPLS/VPN网络中，当P-P链路发生故障时。由于先向PE发送了一个LSP撤销消息，然后再发送新的更新的LSP。这样的过程导致了PE设备公网LSP隧道变化，所以必然要进行一次VPN路由迭代。

新的P设备IGP/LSP更新技术解决了这个问题。在P1设备上，由于使用了IGP/LSP更新技术，IGP/LDP收敛均使用收敛后的新路由直接替换原先的老路由，所以不再向上游的PE设备发送LSP删除以及更新消息，上游的PE设备没有收到影响，所以无需进行VPN路由迭代，这样当P1设备上完成IGP/LDP收敛之后，VPN业务即完成收敛。这样在P-P链路故障，或者P设备故障（不引发PE-P链路故障）的情况，VPN业务端到端收敛时间完全取决于公网IGP/LDP收敛速度，而这个时间通常是200ms-800ms。

2.2 VPN按需迭代

当PE-P链路发生故障后（包括PE设备故障，以及P设备故障引发的PE-P链路故障），由于去往远端PE的LSP发生了故障，所以本地VPN路由需要重新迭代，但并不是所有本地VPN路由都需要迭代，假设PE2-P2链路发生故障，此时PE2至PE1、PE5、PE6的外层隧道没有任何变化，而PE至PE3、PE4的外层隧道则需要重新计算，生成新的LSP。

针对这种情况出现了VPN按需迭代技术。将所有的BGP/VPN路由按照不同的远端下一跳（即不同的PE）分别建立不同的队列，当公网隧道发生变化的时候，只需要对发生变化的外层隧道的BGP/VPN路由进行迭代即可，其他不受影响的VPN路由则无需迭代，这样往往可以节省大量的时间，从而加快网络收敛速度。

2.3 VPN按照优选级的按需迭代

在多业务MPLS/VPN承载网络中，通常会有很多VPN，这些VPN业务有实时类业务，也有非实时类业务，所以它们的收敛速度和要求是有所区别的。针对这种情况，VPN按照优先级的按需迭代功能则能很好的适应和满足这种需求。

2.4 VPN下一跳分离

VPN下一跳分离技术的实现原理在转发平面，将VPN路由转发表按照VPN路由的远端下一跳做分离，将原先的一个VPN路由表分离成两张表，首先查找VPN路由表，查找出远端下一跳，然后再通过远端下一跳查出直连下一跳。当公网发生故障后，公网IGP/LDP收敛，针对每个远端下一跳，直接将原先老的LSP1删除，替换为新的LSP2，这样所有的VPN都会按照新的LSP2进行转发。这样VPN路由不再需要迭代，当IGP/LSP收敛后VPN路由可以立即收敛，即使得VPN路由的收敛速度提升到IGP/LSP收敛的级别上来。

2.5 VPNFRR

VPN FRR技术实现原理如下：对于同一个VPN路由前缀在转发平面同时安装了主用路由和备用路由，同时使用快速检测机制检测主用路由外层隧道状态。一旦检测到某个外层隧道失效，则直接使用备用路由进行报文转发。由于备用路由已经安装在转发表中，所以VPN路由的收敛时间主要取决与外层隧道状态的检测时间。其中对于外层隧道状态检测技术的不同，VPNFRR又可以分为BFD触发的VPN FRR和IGP触发的VPN FRR。其中BFD触发的VPNFRR技术，使用BFD进行外层隧道状态检测，这种方法的优点是检测速度比较快，通常可以做到200ms-500ms，不足点在于，需要整网配置多跳BFD;IGP触发的VPNFRR技术中，当网络发生故障后，IGP/LDP重新收敛，收敛之后即可得知原先的外层隧道失效，此时即可将转发平面中的外层隧道状态置为无效，触发VPN路由切换到备用路由上去。

VPNFRR技术除了可以用来进行PE节点故障保护之外，同时也可以进行PE-P链路、P-P链路、以及P设备故障保护。假设在PE1上部署VPNFRR，其中主用外层隧道为LSP1（去往主用PE3），备用隧道为LSP2（去往备用PE4）。当P1和P2之间链路故障后，检测到LSP1故障，触发VPN FRR切换，流量切换到LSP2上。此后VPN重新迭代，重新迭代生成主用LSP3、备用LSP2的新的VPN路由，流量重新切回到LSP3上来。其中从LSP1切换到LSP2是一个VPNFRR切换过程，而LSP2切回到LSP3是一个路由更新不会造成丢包。因此VPN FRR技术完全可以做到端到端的VPN业务的保护。

2.6 BGP/VPN快速收敛技术总结

下面用一个表格，将这些技术使用的场景、需要的收敛时间，以及需要的网络拓扑做一个综合比较。

BGP/VPN快速收敛比较表

结束语

MPLSVPN作为多业务承载网络的基础，其中BGP/VPN路由的收敛速度当前已经成为端到端业务收敛的瓶颈，而一系列BGP/VPN快速收敛技术的提供必然会大大提高业务保护能力，提高网络的可靠性。使MPLSVPN网络成为语音、视频、数据业务的可靠、高效、易扩展的多业务承载网络。

摘要：作为多业务的承载网络, IP/MPLS VPN技术已经成为当前IP/MPLS网络中的基础技术特性。在一个MPLS VPN网络中, 业务路由是通过BGP技术来承载的, 当前网络中发生链路或者节点故障后, 不但需要公网路由进行收敛, 同时BGP私网路由也需要重新迭代或者收敛, 本文主要描述了BGP/VPN快速收敛的一些技术和方法。

关键词：MPLS,MPLS VPN,BGP/VPN快速收敛

参考文献

一种快速收敛的蚁群算法 第3篇

关键词：蚁群算法,旅行商问题,改进算法

蚁群算法在构造解的过程中, 随机选择策略增加了生成解的随机性, 接受了解在一定程度上的退化, 使得搜索范围在一段时间内保持足够大, 这样影响了算法的收敛速度, 使得算法的收敛速度变慢。另一方面, 蚁群算法采用了正反馈机理, 使得较优解经过的路径上留下更多的信息素, 更多的信息素又吸引更多的蚂蚁, 这个正反馈过程使得较优路径上的信息素不断扩大, 这样又缩小了蚁群的搜索范围, 引导整个系统向着较优解的方向进化, 却容易出现停滞现象。但正是由于这两种机制的互相约束, 才使得基本蚁群算法得以自组织的进化, 从而得到问题在一定程度上的满意解。因此, 要想蚁群算法的模型具有更好的适应性, 使得算法具有更高的搜索效率和更优异的问题解, 对蚁群算法的状态转移概率、信息素更细规则、信息素挥发因子等因素进行改进是一个基本的改进思路, 可在一定程度上克服基本蚁群算法的不足, 为蚁群算法的应用开创更广阔的前景。

1、改进策略

1.1 状态转移概率

通过大量仿真实验发现, 概率选择在一定程度上影响了算法的收敛速度, 在排序蚁群算法的启发下, 本文仍然文献1中的轮盘赌式的随机比例选择规则[1], 但对蚂蚁将要访问的城市进行了限制。即只对将要访问城市中距离当前城市最近的若干个城市进行访问 (基本算法是对所有没有走过的城市进行访问) , 区别于排序算法的是这里将要访问的城市规模是按照平均值来动态更新, 即对将要访问的城市进行减半处理, 从而大大提高了算法的速度。

1.2 信息素全局更新规则

经过n个时刻, 蚂蚁完成一次循环, 各个路径上信息素量根据下式调整

式中, Lg表示当前的全局最优路径长度, Lb表示当前循环的局部最优路径长度, 表示本次循环结束后最优路径上的信息量。

1.3 信息素局部更新规则

基本算法中, 信息素的局部更新是对所有蚂蚁走过的路径进行信息素更新, 也有人提出了只对走过的路径进行信息素更新, 本文在此基础上提出了一种新的更新策略, 该策略在增加算法的熟练速度的同时, 也避免了基本算法中信息量Q的盲目选择。

式中, 表示本次循环中路径 (i, j) 上的信息素增量, 表示第k只蚂蚁在本次循环中留在路径 (i, j) 上的信息量。Lmean表示本次循环结束后所有蚂蚁走过路径的平均值。Lk表示第k只蚂蚁走过路径的长度。

1.4 信息素挥发因子

信息素的挥发, 减小了算法对历史路径上信息素的严重依赖, 同时又不会降低算法的正反馈性。在自适应蚁群算法[3]的基础上, 提出了一种新的信息素挥发因子挥发策略

式中, v表示未能找到新的最优路径的迭代次数, 这里初始值设为1。

2、仿真实例

对来自TSPLIB中的att48, Berlin52两个个实例进行了仿真对比实验。分别采用基本蚁群算法和改进蚁群算法, 采用matlab7.1在pentium 4 CPU3.0GHz, 512MB的电脑上进行仿真实验。实验参数根据经验进行设置。实验结果如表1所示, 通过对比发现, 改进算法明显提高了解的质量。实验收敛曲线如图1所示。

3、结论与展望

本文针对基本蚁群算法存在收敛速度慢及收敛停滞的缺点, 提出了一种改进的蚁群算法, 并通过经典TSP实例仿真验证, 明显提高了算法的收敛速度, 达到了预期的改进效果。但要同时达到收敛速度快, 并且提高解得质量, 还需要深入研究。

参考文献

[1]、段海滨著蚁群算法原理及其应用[u]北京:科学出版社, 2005.12

[2]、李士勇等编著蚁群算法及其应用[u]哈尔滨:哈尔滨工业出版社, 2004.9

快速收敛 第4篇

关键词：视频组播,网络快速收敛,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.