[发明专利]面向业务的故障检测与定位方法

说明书

技术领域

本发明主要针对IP网络中的故障检测与定位技术，特别是应用于IP网络的一种面向业务的故障检测与定位提供了技术方案。

背景技术

随着通信技术的发展和用户对业务QoS(Quality of Service，服务质量)的期望不断提升，业务成为通信网络发展的主要驱动力，这里提到的业务是指用户对网络的具体传输请求，要求网络建立满足用户请求的传输链路并承载由用户发起的的业务。在这样的大背景下，新型业务层出不穷，日常生活中常见的VoIP业务、IPTV业务、3G业务等等，都是在IP技术的基础上建立的。但是，在业务传输过程中出现的某些突发因素，会导致网络中正在传输的业务的QoS性能严重下降，不能满足用户的业务体验，即出现了业务故障。这些业务故障包括因软、硬件中某些参数的错误配置等导致的业务中断，以及不恰当的路由策略等导致的业务拥塞。如果业务故障得不到及时高效的处理，就会成为运营商提高用户体验的严重障碍，势必导致用户满意度的下降。为了保障业务的可靠传输，运营商有必要在IP网络中引入面向业务的故障检测与定位方法，以期在网络中提供良好的故障检测和定位能力，以利于业务故障的快速恢复，从而提高网络生存性，提升业务的服务质量，提高用户的满意度。

IP网络中现已应用的故障检测和故障定位方法分别是借助Hello机制和环回机制来实现的，然而，它们的检测时间都在秒级，且不支持面向业务的故障检测与定位，存在着一定的局限性。

IP网络中现有的故障检测方式有以下两种：

一种是慢Hello机制。IP路由时，在没有硬件帮助的情况下，该机制的检测时间很长。例如，OSPF(Open shortest Path First，开放最短路径优先协议)Hello和IS-IS(Intermediate System to Intermediate System，中间系统到中间系统协议)Hello都需要秒级的检测时间，而RSVP(Resource Reservation，资源预留协议)Hello甚至需要10秒级的检测时间。慢Hello机制主要应用于WWW、FTP、Email等传统互联网业务，然而对于网络游戏、VoIP、IPTV、3G等新型实时业务，这样的检测时间是用户无法忍受的。

两外一种是快Hello机制。面对传统网络在故障检测方面的不足，IETF提出的双向转发检测协议(Bidirectional Forwarding Detection，BFD)，提供一种轻负荷、毫秒级、独立的Hello检测机制，用来检测相邻节点之间的通道故障。这些故障包括接口故障、数据链路故障，以及节点本身的故障。BFD能够对任何媒介、任何协议层进行实时检测，而且它的检测时间与开销范围规定得比较宽，可以根据实际情况做出动态调整。具体来说，BFD能够在给定目的地址以及其他参数的前提下，创建、删除、修改一个BFD会话，检测故障并得到故障信息。BFD有两种工作模式和Echo功能，可以降低部分的网络开销，但也存在着一定的局限性。

上述两种故障检测方法存在着如下的不足：a.相邻系统之间周期性地向彼此发送探测报文，不能实现秒级以下的快速间歇性的故障检测；b.由于是在邻居节点之间运行检测方法，故引起比较严重的网络抖动；c.通过大量发送报文来实现检测故障，故在比较恶劣的网络环境下，它们带来的网络负荷不容忽视；d.虽然现有检测方法能够维护网络良好的连通性，但并不支持面向业务的故障检测。

IP网络的故障定位技术主要采用环回方法：

当两个端节点检测到路径存在故障时，其中一个端节点向该路径发送环回报文，该端节点为环回报文的源端节点，路径上的每一个节点接收到环回报文后，向源端节点返回该报文。源端节点可以根据路径中的节点是否返回环回报文来确定路径故障所在的位置。

上述故障定位方法存在着如下的不足：a.采用逐级递归的方式寻找故障位置，但只能单方向地查找故障，无法沟通故障两端的定位信息，即无法具体地定位出是节点故障或是链路故障；b.有一定的定位能力，但并不支持面向业务的故障定位。

发明内容

本发明的主要目的在于提供一种面向业务的故障检测与定位方法，通过业务QoS来触发故障检测与定位方法，这样，只需要发送很少的探测报文就能够确定业务故障的类型是拥塞还是中断。若为拥塞，则对部分业务流进行“分流”；若为业务中断，则应判断业务中断的是由链路故障还是节点故障引起的，并确定故障发生的具体位置。

为了达到上述目的，本发明的具体技术方案如下：

总的来看，本发明提供了一种面向业务的故障检测与定位方法，该方法包括以下步骤：