[发明专利]快速检测通信路径故障的系统和方法

说明书

技术领域

本发明涉及快速检测通信路径故障的系统和方法。

背景技术

在VoIP系统中，通常利用诸如传输控制协议(TCP)或用户数据报协议(UDP)之类的传送协议来建立因特网协议公共分支交换(iPBX)服务器和因特网协议(IP)电话客户端之间的通信路径。对任一情况，应用层心跳方案(heartbeat scheme)是监控端到端的路径连通性的普及方法。

可以基于在宣告特定路径故障之前检测到的连续心跳丢失数(m)、发送定时器值(t_x)以及接收定时器值(t_r)来确定典型的心跳方案的定时。这些值可以被概括为(t_x，t_r，m)。在操作期间，通常在t_x定时器终止之后发送心跳。可以在t_r定时器终止之后对心跳丢失事件进行报告。任何消息发送活动都可以复位和重启相应的Tx定时器。任何消息接收活动都可以复位和重启相应的RX定时器。

可以假设延迟时间t_delay＝t_r-t_x为心跳系统等待时间，心跳系统等待时间表明了心跳沿着网络路径被逐端递送和处理所需要的估计出的最大时间。可以认为默认值类似于往返时间的TCP默认值(3秒)，因此，可以假设t_delay＝3秒。

鉴于此，一般意味着t_delay为基于典型心跳方案检测心跳丢失或路径故障所需要的最小或下限时间。

在单向心跳模型中，仅一侧发送心跳；另一侧倾听心跳。如果倾听侧的RX定时器在t_r秒中终止，则倾听侧断言心跳丢失(heartbeat miss)；当丢失m个连续心跳时，倾听侧宣告其路径断裂。单向模型中检测路径故障所需的时间为：

[(m-1)×t_r+t_delay]＜T＜＝m×t.

在单向心跳模型中，两侧独立地交换心跳。两侧都倾听心跳并且监控路径状态。

在图1所示的典型的iPBX客户端-服务器系统中，不失一般性，双向心跳模型通过(t_x，t_r，m)＝(27，30，2)的特定心跳值来例示。

在图1所示的模型下，iPBX服务器102和IP电话104通过TCP链路106每27秒交换心跳。如果TCP链路已经空闲了30秒则报告心跳丢失。在TCP链路上丢失两个连续的心跳表明链路损坏(down)或者主iPBX不可到达。电话随后可以通过关闭到主iPBX的当前TCP连接并建立到辅iPBX 108的新的TCP连接来启动故障切换(failover)处理。故障检测时间T_detect对于IP电话网络中的系统可用性是至关重要的因数。对于任何链路，T_detec在如下范围中

当m＝2时，33秒＜＝T_deec＜＝60秒；

当m＝1时，3秒＜＝T_detec＜＝30秒。

针对图1讨论的应用层心跳方案不同于TCP协议栈方案。一种标准类型的TCP协议栈方案是Keepalive(保持活动)方案。在这种方案中，每个Keepalive消息期待来自路径的远端的Keepalive应答(ACK)。如果在多次重发之后未接收到ACK，则断言路径故障。TCP Keepalive是TCP协议的可选特征。其默认为禁用。存在关于Keepalive的三个参数：tcp_keepidle、tcp_keepintvl和tcp_keepretry。

tcp_keepidle参数指定了使得TCP为请求发KEEPALIVE送的应用生成KEEPALIVE发送的不活动(inactivity)的间隔。tcp_keepidle默认为2小时。tcp_keepintvl参数指定了如果发送未被确认则被尝试的重试之间的间隔。tcp_keepintvl默认为75A秒。tcp_keepretry是在宣告远程端不可用之前要执行的重发的次数。tcp_keepretry默认为8。

TCP Keepalive方案不是针对TCP链路中的快速检测而设计的。其是具有系统范围的行为的内核层控制的TCP栈，系统范围的行为不适于每链路或每应用接口目的。