CN102164051A - 面向业务的故障检测与定位方法 - Google Patents

Abstract

本发明公开了一种面向业务的故障检测与定位方法，该方法首先提出了补弦和业务QoS(Quality of Service，服务质量)触发的概念，通过实时监测业务转发路径的QoS指标，在不满足业务传输需求时启动该方法，然后检索路径中QoS达不到要求的位置，再确认业务故障的类型并通知源节点，最后分析故障发生位置。该方法不仅能够满足不同种类业务的故障检测与定位需求，降低了检测与定位故障引起的网络开销，还能够确定业务故障的类型，判断引起业务故障的原因，并给出故障发生的具体位置。

Description

面向业务的故障检测与定位方法

技术领域

本发明主要针对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来触发故障检测与定位方法，这样，只需要发送很少的探测报文就能够确定业务故障的类型是拥塞还是中断。若为拥塞，则对部分业务流进行“分流”；若为业务中断，则应判断业务中断的是由链路故障还是节点故障引起的，并确定故障发生的具体位置。

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

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

【301】建立端到端的业务转发路径并补“弦”，所述的补“弦”是指建立从源节点到目的节点的最优业务转发路径后，寻找其他在源节点和目的节点之间可以传输数据的路径的集合，该集合就是所补的“弦”，为了保证“弦”的连通性需在“弦”上运行多跳保活报文；再由目的节点负责实时监测业务的QoS，并将QoS突降的信息反馈给源节点，触发检测与定位方法；

【302】源节点向下游节点，同时目的节点向上游节点检索路径中报文可达的最后一个节点；

【303】上述最后一个节点向它不可达的邻居节点周期性发送确认报文，以判断是业务拥塞还是中断；

【304】上述最后一个节点生成业务中断或拥塞告警，并发送给源节点；

【305】上述最后一个节点生成业务故障定位报文并发送给源节点，源节点通过分析给出业务故障原因和位置。

所述的故障检索报文和故障确认报文中，均携带着触发该故障检测与定位方法的业务数据，回传的响应报文需要剔除这些业务数据，以减小网络传输负荷。

该技术方案的具体实施方案如下：

【301】源节点接收到目的节点的某类业务请求后，综合网络的各项参数和该业务的QoS请求等信息，建立一条从源节点到目的节点的最优业务转发路径，同时在源节点和目的节点之间补“弦”，所补的“弦”是指源节点与目的节点之间除了工作路径以外的可达传输路径的集合，然后再由目的节点负责实时监测业务的QoS指标。当QoS性能突然下降时，目的节点生成QoS触发报文，通过事先建立的“弦”反馈给源节点，触发故障检测与定位方法。

所述业务包括宽带互联网业务、IPTV、VoIP、网络游戏，以及3G业务等。虽然为不同业务建立最优转发路径的技术可能存在着某些差异，但是这并不是本发明关注的重点。

所述业务QoS指标，包括带宽、时延、抖动和丢包率。

所述对某类业务的QoS指标的监测，是按如下的方式进行的：首先在源节点上依据QoS将业务数据划分为不同的等级，然后使用IPv4/IPv6报头中ToS(Type of Service，业务类型)字段的最后6位生成64种不同的DSCP(Distributed Service Code Point，差分服务代码点)值来标记它们的优先级。如果网络拓扑中的各个节点均被配置为根据DSCP标记进行数据分类，则这些节点就可以非常容易地识别出来白源节点的数据包，并对途经本节点的分类和标记后的业务的QoS进行实时监测。例如，网络中有多条端到端的业务转发路径在某个节点上存在着交叉重合的情况，该节点根据数据包中的DSCP值、源IP地址、目的IP地址可以成功区分出不同的业务转发路径，监测不同业务数据的QoS参数。

所述QoS触发报文中携带着QoS诊断信息，即业务QoS突然下降的某一项或者某几项的性能指标，如业务的丢包率突然变大。

所述补“弦”的过程。源节点综合网络参数和业务的QoS以后，为业务建立最优业务转发路径，记为Path。源节点和目的节点之间能够转发数据的所有路径的集合记为A，A中除Path以外的其他所有路径的集合称为”弦”，记为B，当然B中的不同路径可能有不同程度的重叠。其中Path是A的元素，B是A的子集。它们之间有以下的关系：

在“弦”B上从源节点向目的节点，或者目的节点向源节点周期性地发送多跳保活报文，只要能接收到对端发回的响应报文，就表明源节点和目的节点之间的转发路径是实时连通的，即可认为“弦”B正常工作，而并不需要关心报文转发过程中所经过的中间节点。此时，“弦”B中的所有路径统称为保活路径。

【302】源节点生成故障检索报文，并逐跳向下游各个节点发送该报文，用于查找转发路径中检索报文可达的最后一个节点。下游节点收到检索报文后，向上一跳节点回复响应报文，并将本节点是否可用的信息封装到检索报文中向，并下一跳节点发送，该过程一直重复下去，直到某一节点在检索时间内未收到它下一跳节点回复的响应报文为止。与此同时，目的节点也生成故障检索报文，再逐跳向上游各个节点发报，其操作与源节点发送故障检索报文类似。

所述源节点和目的节点各自生成的一个故障检索报文，分别沿着业务转发的路径和逆路径转发。

所述未收到响应报文的节点称为检索报文可达的最后一个节点，记为U_E(Upstream End node，上游检索可达端节点)和节点D_E(Downstream End node，下游检索可达端节点)。

所述的检索时间为(1+0.1×N₁)×t_ETI。其中，t_ETI为节点向其邻居节点发送检索报文直到它收到邻居节点回复的响应报文的时间间隔，N₁为大于等于0的任一整数，N₁值的选取依据QoS触发报文中携带的QoS诊断信息进行综合考量，如业务对QoS指标中的时延要求较高时，N₁取值较小。

【303】节点U_E生成故障确认报文，并向它不可达的下一跳节点周期性地发送该报文。如果下一跳节点能够收到确认报文立即向节点U_E回复响应报文，节点U_E在故障确认时间内收到任意一个响应报文，说明业务QoS性能下降是由业务拥塞引起的，即业务发生的故障为业务拥塞。反之，如果可达端节点在确认时间内未收到任意一个响应报文，则认为业务QoS性能下降是由业务中断引起的，即业务发生的故障为业务中断。节点D_E在业务转发的逆路径上也按照上述方式进行操作。

所述的确认时间为N₂×t_ETI，N₂值的选取依据该类业务期望的QoS等级进行考量，如业务对QoS指标中的时延要求较高时，N₂取值较小。

所述业务拥塞的起因为多个链路向一个链路突发、高速链路向低速链路传输、非关键业务抢占关键业务、业务流量过大等。

所述业务中断的起因为节点故障，或者链路故障。

所述检索可达端节点经过上述阶段的处理后，更名为故障定位节点，它们位于故障发生位置的两侧，且与发生故障的位置相邻。其中位于故障发生位置上游的称为上游故障定位节点，位于故障发生位置下游的称为下游故障定位节点。

【304】上游故障定位节点生成业务故障告警报文并发送给源节点，该告警携带业务拥塞或业务中断的信息。源节点收到上游故障定位节点发送的告警报文后，即可获知业务故障的类型。在此阶段，下游故障定位节点不做处理。

【305】确认业务故障的类型后，上、下游故障定位节点生成故障定位报文并发送给源节点。该过程中，定位报文途经的正常节点将本节点ID(Identification Code，身份鉴别码)封装到该定位报文中，源节点收到来自两个方向上的定位报文后通过相应的运算即可判断出业务故障发生的位置。

所述上游故障定位节点生成的定位报文，由该节点沿着业务转发路径的逆路径发送给源节点；所述下游节点生成的定位报文，由该节点沿着业务转发路径的方向发送给目的节点，然后由目的节点沿着事先建立的“弦”发送给源节点。

该技术方案进一步包括：

源节点将来自两个方向的定位信息同自身存储的承载业务的显式路由进行比较，如果发现这些定位信息中缺少某一个节点的信息，则认为业务在该节点处发生了业务拥塞或者中断；如果发现节点信息完整，则认为业务在上、下游故障定位节点之间的链路上发送了业务拥塞或者业务中断。即这些定位信息中显示上、下游故障定位节点为邻居节点时，表明业务故障是由它们之间的链路发生了故障所引起的；定位信息中显示它们不为邻居节点，表明业务故障是由它们之间的节点发生故障引起的：将它们和存储的显示路由做“异或”运算即可得到这些故障节点的ID。

附图说明

图1为面向业务的故障检测与定位报文的数据结构；

图2为面向业务的故障检测与定位方法各个阶段的运行区间，以及对应报文的发送方向；

图3为面向业务的故障检测与定位方法的流程图；

图4为具体实施例中的网络拓扑图；

图5为建立的业务转发路径和选取的“弦”，以及三种业务故障的场景；

图6为面向业务的故障检测与定位的系统结构示意图。

具体实施方式

为使本发明的目的、技术方案、以及优点更加清楚明白，下面结合附图和具体实施例对本发明做进一步详细阐述。

本发明适用于检测业务路径上正在传输的业务突然发生故障的情况，能够区分出业务故障的类型是拥塞还是中断，同时可以诊断业务发生故障的原因并定位出故障发生的位置。

图1为面向业务的故障检测与定位报文的数据结构示意图，本发明需要关注的字段如下：

Vers字段，全称Version。用来指示该报文的版本信息，长度为3bit。目前该报文为第1版，故该字段置位为001。

M字段，全称Multi-Hop-Alive。源节点开始向目的节点传输业务时置位，长度为1bit。该字段为1时对应多跳保活报文，只在“弦”上周期性地传输，负责“弦”的实时连通性。

Q字段，全称QoS Trigger。目的节点监测到某类业务的QoS性能突降时置位，长度为1bit。该字段为1时对应QoS触发报文，标志着进入QoS触发阶段，启动面向业务的故障检测和定位方法

S字段，全称Search。源节点收到目的节点反馈的QoS触发消息时置位，长度为1bit。该字段为1时对应故障检索报文，标志着进入故障检索阶段，用于查找检索可达端节点。

C字段，全称Confirm。查找到检索可达端节点时置位，长度为1bit。该字段为1时对应故障确认报文，标志着进入故障确认阶段，用于确认业务故障的类型。

A字段，全称Alarm。确认出业务故障类型时置位，长度为1bit。该字段为1时对应故障告警报文，标志着进入故障告警阶段，由上游故障定位节点将故障告警发送给源节点，告知源节点业务故障的类型。

L字段，全称Location。确认出业务故障类型时，与A字段同时置位，长度为1bit。该字段为1时对应故障定位报文，标志着进入故障定位阶段，由上、下游故障定位节点各自将该故障定位信息发送给源节点，负责告知源节点上、下游故障定位节点的ID，以及业务转发路径中正常工作的节点ID。

E字段，全称Echo。需要回复响应时置位，长度为1bit。该字段为1时表示需要报文发送者回复响应报文，为0时不需要。

QD字段，全称QoS Alarm Diagnostic。与Q字段配套使用，给出业务QoS性能的哪一项或者哪几项指标突降了，长度为4bit。从低位到高位依次为时延、丢包率、包抖动、带宽，即0001表示时延、0010表示丢包率、0100表示包抖动、1000表示带宽，当有多个指标突降时将对应位置位即可，如0111表示时延、丢包率和包抖动状况同时下降。

C/I字段，全称Service Congestion/Interruption。与Q字段配套使用，给出业务故障的类型，长度为2bit。该字段为01表示业务拥塞，为10表示业务中断，为00和11表示业务没有出现故障。

N字段，与S字段配套时用于选取故障确认时间，表示t_ETI的倍数；与C字段配套时用于选取故障检索时间，表示N₂×t_ETI的倍数，长度为8bit。N₂值的大小依据业务期望的QoS等级进行考量。

Length字段，用于指示该故障检测与定位报文的长度，字段长度为8bit。

ID字段，全称Session Identification Code。发送方产生的一个唯一非0值，用于标识不同的会话，长度为32bit。

ETI字段，全称Echo Receive Time Interval。从发送方向其邻居节点发送该报文，到它收到邻居节点回复的响应报文的时间间隔，长度为32bit。

LDI字段，全称Location Diagnostic Information。用于存放上、下游故障定位节点的ID，以及定位报文途径的各个正常节点的ID，长度为32bit。

SDP字段，全称Service Data Patch。发送检索和确认报文时用来存放传输的数据，该字段的长度依不同的业务而定。

Reserve字段，保留字段，长度为32bit。

所述所有字段，如果均置为0表示当前报文无效，或者表示不需要做任何操作。

图2为面向业务的故障检测与定位方法各个阶段的运行区间，以及对应报文的发送方向，首先定义源节点为S，通过所补的“弦”到达源节点时定义源节点为S`，目的节点为D，上游检索可达端节点为U_E，下游检索可达端节点为D_E。对应报文的发送方向包括：

QoS触发阶段，运行区间为D→S`，QoS触发报文由D沿着事先建立的“弦”发送给S`。

故障检索阶段，运行区间为D→D_E和S→U_E。D生成的故障检索报文沿着业务转发的逆路径向D_E逐跳地转发，S生成的故障检索报文沿着业务转发路径向U_E逐跳地转发。

故障确认阶段，运行区间为D_E→U_E，或U_E→D_E。D_E生成的故障确认报文沿着业务转发路径向它的下一跳节点周期性地发送，U_E生成的故障确认报文沿着业务转发的逆路径向它的下一跳节点周期性地发送。

故障告警阶段，运行区间为U_E→S。UE生成的故障告警报文沿着业务转发的逆路径向S逐跳地转发。

故障定位阶段，运行区间U_E→S和D_E→D→S`。U<sub>E</sub>生成的故障定位报文沿着业务转发的逆路径向S逐跳地转发，D<sub>E</sub>生成的故障定位报文沿着业务的转发路径先向D逐跳地转发，然后由D沿着事先建立的“弦”发送给S`。

下面通过具体的实施例来说明本发明的技术方案，图3所示为面向业务的故障检测与定位的方法流程图，包括：

步骤【301】，建立端到端的业务转发路径并补“弦”，由目的节点负责实时监测业务的QoS，并将QoS突降的信息反馈给源节点，触发检测与定位方法；

图4中节点F发出某类业务的请求，如果节点A恰好能够提供该类业务的服务，节点A响应该类业务请求，综合网络参数和业务请求的QoS参数等信息后，建立从源节点A到目的节点F的一条端到端的最优业务转发路径为A→B→C→D→E→F，并开始传输业务。此时，节点A作为该类业务传输的源节点、节点F作为该类业务传输的目的节点。除了Path以外的所有能从节点A到节点F的路径，作为”弦”

并在其上运行多跳保活报文。其中，图4(a)为网状拓扑图，选取“弦”时不需要“增补”链路；图4(b)为树状拓扑图，选取“弦”时需要“增补”的链路，如(b)图中补上链路D-M和链路I-F后，从节点F到节点A的“弦”

就获得了多条保活路径。

图5(a)中为已经建立的业务转发路径Path和“弦”

目的节点F负责监测Path的QoS指标，当节点F监测到自身的某一项或者某几项QoS传输指标不满足业务的QoS要求时，如VoIP业务的丢包率大于5％、抖动大于60ms、时延大于400ms时，节点F生成QoS触发报文沿着“弦”

发送给节点A，然后触发该故障检测与定位方法。

步骤【302】，源节点向下游节点，同时目的节点向上游节点检索路径中报文可达的最后一个节点；

图5(a)中，节点A生成携带业务数据的故障检索报文，发送给它的下一跳节点B，假设链路A-B和节点B均正常，节点B收到节点A发来的检索报文后立即向节点A回复响应报文，如果节点A在检索时间(1+0.1×N₁)×t_ETI内能够收到节点B发送来的响应报文，则说明上述假设成立，即链路A-B和节点B均正常，节点B可达。同时节点B又将该检索报文发送给它的下一跳节点C，后续节点的处理同上。直到某一节点在检索时间(1+0.1×N₁)×t_ETI内为收到它下一跳节点回复的响应报文，说明检索报文不可到达它的下一跳节点，同时认为该节点为上游检索可达端节点。例如，图2中的节点U_E如果在(1+0.1×N₁)×t_ETI内未收到它下一跳节点回复的响应报文，则认为节点U_E为上游检索可达端节点。

节点F也生成同样的故障检索报文，再逐跳向上游各个节点发送报文，其操作原理同上。例如，图2中的节点D_E如果在(1+0.1×N₁)×t_ETI内未收到它的上一跳节点回复的响应报文，则认为节点D_E为下游检索可达端节点。

综上，认为业务在节点U_E和节点D_E之间的路径上传输时出现了故障。

其中，节点U_E和节点D_E可以是一对邻居节点，如图5(b)中的节点D和节点E的关系；或者，节点U_E和节点D_E也可以不是一对邻居节点，它们拥有同样一个邻居节点，如图5(c)中的节点C和节点E它们拥有同样一个邻居节点D；或者节点U_E和节点D_E也可以不是一对邻居节点，它们之间出现了多个节点或链路故障，如图5(d)中的节点B和节点E，节点B的邻居节点为节点C、节点E的邻居节点为节点D。如此以来就引入了三种故障的情况：链路故障、节点故障、多故障。

步骤【303】，上述最后一个节点向它不可达的邻居节点周期性发送确认报文，以判断是业务拥塞还是中断；

图2中，节点U_E周期性地向它的下一跳节点发送故障确认报文，如果节点U_E在N₂×t_ETI内收到了它下一跳节点回复的任意一个响应报文，则认为U_E和它的下一跳节点发生的业务故障的类型为业务拥塞；如果节点U_E在N₂×t_ETI内未收到它下一跳节点回复的任意一个响应报文，则认为U_E和它的下一跳节点发生的业务故障的类型为业务中断。节点D_E周期性地向它的上一跳节点发送故障确认报文，如果节点D_E在N₂×t_ETI内收到它上一跳节点回复的任意一个响应报文，则认为U_E和它的上一跳节点发生的业务故障的类型为业务拥塞；如果节点D_E在N₂×t_ETI内未收到它上一跳节点回复的任意一个响应报文，则认为U_E和它的上一跳节点发生的业务故障的类型为业务中断。此后，节点U_E和节点D_E分别更名为上、下游故障定位节点。

图5(b)中，节点D周期性地向它的下一跳节点E发送故障确认报文，如果节点D在N₂×t_ETI内收到任意一个响应报文，表明节点D和节点E发生了业务拥塞；反之，为业务中断。节点E周期性地向它的下一跳节点D发送故障确认报文，如果节点E在N₂×t_ETI内收到任意一个响应报文，表明节点E和节点D发生了业务拥塞；反之，为业务中断。

图5(c)中，节点C周期性地向它的下一跳节点D发送故障确认报文，如果节点C在N₂×t_ETI内收到任意一个响应报文，表明节点C和节点D发生了业务拥塞；反之，为业务中断。节点E周期性地向它的下一跳节点D发送故障确认报文，如果节点E在N₂×t_ETI内收到任意一个响应报文，表明节点E和节点D发生了业务拥塞；反之，为业务中断。

图5(d)中，节点B周期性地向它的下一跳节点C发送故障确认报文，如果节点B在N₂×t_ETI内收到任意一个响应报文，表明节点B和节点C发生了业务拥塞；反之，为业务中断。节点E周期性地向它的下一跳节点D发送故障确认报文，如果节点E在N₂×t_ETI内收到任意一个响应报文，表明节点E和节点D发生了业务拥塞；反之，为业务中断。

步骤【304】，上述最后一个节点生成业务中断或拥塞的告警报文并发送给源节点；

图2中，节点U_E生成故障告警报文，沿着U_E→S的路径发送给源节点S。

图5的(b)、(c)、(d)中，分别由节点D、节点C和节点B生成故障告警报文，然后分别沿着D→C→B→A、C→B→A和B→A路径发送给源节点A。节点A收到告警报文后，解析该报文即可获知业务的故障类型。

步骤【305】，上述最后一个节点生成业务故障定位报文并发送给源节点，源节点通过分析给出业务故障原因和位置。

图2中，节点U_E生成的故障定位报文，沿着U_E→S路径发送给源节点S，该报文途经节点U_E和节点S之间的所有正常节点的ID封装到该报文中；节点D_E生成的故障定位报文，沿着DE→D→S`路径发送给源节点S，该报文途径节点D<sub>E</sub>和节点S`之间的所有正常节点的ID封装到该报文中。

图5(b)中，节点D生成的故障定位报文，沿着D→C→B→A发送给节点A，途经的节点C、B将本节点的ID封装到该报文中；节点E生成的故障定位报文，沿着E→F→A`发送给节点A，途经的节点F将本节点的ID封装到该报文中。节点A收到的定位信息：节点D为上游故障定位节点，节点E为下游故障定位节点，节点C、B、F均正常，所以可以判断业务发生故障的位置在链路D-E上。

图5(c)中，节点C生成的故障定位报文，沿着C→B→A发送给节点A，途经的节点B将本节点的ID封装到该报文中；节点E生成的故障定位报文，沿着E→F→A`发送给节点A，途经的节点F将本节点的ID封装到该报文中。节点A收到的定位信息：节点C为上游故障定位节点，节点E为下游故障定位节点，节点B、F均正常，所以可以判断业务发生故障的位置在路径C-E之间，将它们与显式路由做“异或”运算得知节点D发生故障。

图5(d)中，节点B生成的故障定位报文，沿着B→A发送给节点A；节点E生成的故障定位报文，沿着E→F→A`发送给节点A，途经的节点F将本节点的ID封装到该报文中。节点A收到的定位信息：节点B为上游故障定位节点，节点E为下游故障定位节点，节点F正常，所以可以判断业务发生故障的位置在路径B-E之间，将它们与显式路由做“异或”运算得知节点C、D，或是链路B-C和节点D，或是节点C和链路D-E发生故障。

为了实现上述方法，本发明还提供了一种面向业务的故障检测与定位系统，如图6所示为路径中的各个节点的结构示意图。

各个节点包括：报文生成模块601、报文接收与处理模块602、报文转发模块603。由于网络故障的出现是随机事件，当网络中不同的节点或链路发生故障时，产生的上、下游检索可达端节点是不同的，故在不同状态下，各节点的内部模块生成报文的类型是不同的，各模块的主要功能如下所述：

报文生成模块601，用于生成面向业务的故障检测与定位报文，并处理来自报文接收与定位模块602移交的相关处理信息，模块601在方法运行的各个阶段修改对应的字段，如QoS达不到要求时将字段Q置位、检索阶段时将字段S置位、确认阶段时将字段C置位、告警阶段时将字段A置位、定位阶段时将字段L置位，等等。601模块完成自己的任务后，将其移交给报文转发模块603；

报文接收与处理模块602，用于接收发送方节点603发送来的报文，对该报文进行相关处理，然后将需要改变的报文信息，如字段Q、S、C、A、L、E移交给报文生成模块601，其他的报文信息移交给报文转发模块603；

报文转发模块603，用于将报文转发给下一节点的602，将响应报文发送给上一节点的602模块。

报文生成模块601进一步用于，当源节点开始向目的节点传输业务时，由源节点生成的运行在“弦”上的多跳保活报文；当QoS性能突降时，由目的节点生成的QoS告警报文；在不同的处理阶段将字段S、字段C、字段A和字段L置位，以及置位字段E，设定是否需要报文接收端回复响应报文；

报文接收与处理模块602进一步用于，记录接收到响应报文的时间，由此计算出模块603记录的报文发送时间和接收到响应报文的时间间隔。模块602在报文中给出业务QoS突降的指标QD；给出业务故障的类型C/I。该模块还生成故障定位信息LDI；在不同阶段生成不同的唯一会话识别码。当源节点接收到定位报文后，模块602提取其中的定位信息进行定位运算；

报文转发模块603进一步用于，当S字段、C字段置位时，表示该报文为传输的数据包，不用于故障的检测与定位，同时记录报文发送的时间和N₂的大小，最后标记报文的长度。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施方式仅限于此，对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单的推演或替换，都应当视为属于本发明由所提交的权利要求书确定专利保护范围。

Claims (7)

1.提出一种面向业务的故障检测与定位方法，其特征在于，包括以下步骤：

1)建立端到端的业务转发路径并补“弦”后，由目的节点负责实时监测业务的QoS，并将QoS突降的信息反馈给源节点，触发检测与定位方法；

2)源节点向下游节点，同时目的节点向上游节点检索路径中报文可达的最后一个节点；

3)上述最后一个节点向它不可达的邻居节点周期性发送确认报文，以判断是业务拥塞还是中断；

4)上述最后一个节点生成业务中断或拥塞的告警并发送给源节点；

5)上述最后一个节点生成业务故障定位报文并发送给源节点，源节点通过分析给出业务故障原因和位置。

2.根据权利要求1所述的面向业务的故障检测与定位方法，其特征在于：所述的补“弦”是指建立从源节点到目的节点的最优业务转发路径后，寻找其他在源节点和目的节点之间可以传输数据的路径的集合，该集合就是所补的“弦”，为了保证“弦”的连通性需在“弦”上运行多跳保活报文；所述的业务QoS触发是指目的节点依据DSCP值、IP地址等信息区分出不同的业务，然后分别监测不同业务的QoS指标，某一时刻当某个到达目的端的业务QoS指标和期望值存在较大差异时，生成QoS触发报文并通过事先建立的“弦”传递给源节点，然后启动该方法。

3.根据权利要求1所述的面向业务的故障检测与定位方法，其特征在于：所述的检索是指源节点生成故障检索报文，沿着业务转发路径逐跳向下游各个节点发送该报文，用于查找转发路径中检索报文可达的最后一个节点；下游节点收到检索报文后，向上一跳节点回复响应报文，将本节点是否可用的信息封装到检索报文中，并向下一跳节点发送，该过程一直重复下去，直到某一节点在检索时间(1+0.1×N₁)×t_ETI内未收到它下一跳节点回复的响应报文为止，其中，t_ETI指节点向其邻居节点发送检索报文，直到收到邻居节点回复的响应报文的时间间隔，N₁仅出现在该检索阶段，为0.1×t_ETI的倍数，其大小根据业务QoS的期望值进行选取，如业务对QoS指标中的时延要求较高时，N₁取值较小；与此同时，目的节点也生成故障检索报文，沿着业务转发路径逐跳向上游各个节点发报，其操作和源节点一样；最终，源节点和目的节点分别生成的故障检索报文，将到达故障发生位置的两侧，即节点U_E和节点D_E。

4.根据权利要求1所述的面向业务的故障检测与定位方法，其特征在于：业务故障分为拥塞和中断，所述的故障确认是指通过一定的方法确认业务的故障类型；该方法为节点U_E生成故障确认报文，并向它不可达的下一跳节点周期性地发送该报文；如果下一跳节点能够收到确认报文立即向检索该可达端节点回复响应报文，如果节点U_E在故障确认时间N₂×t_ETI内收到任意一个响应报文，其中N₂仅出现在该确认阶段，为t_ETI的倍数，其大小根据业务的QoS期望值进行选取，如业务对QoS指标中的时延要求较高时，N₂取值较小，说明业务QoS性能下降是由业务拥塞引起的，即业务发生的故障为业务拥塞；反之，如果U_E在确认时间N₂×t_ETI内未收到任意一个响应报文，则认为业务QoS性能下降是由业务中断引起的，即业务发生的故障为业务中断；节点D_E在业务转发的逆路径上也按照上述节点U_E的方式进行操作。

5.根据权利要求1所述的面向业务的故障检测与定位方法，其特征在于：所述的故障告警指节点U_E生成业务故障告警报文并发送给源节点，该告警报文携带业务拥塞或业务中断的信息，以及由业务拥塞或业务中断引起的业务QoS下降的指标；源节点收到节点U_E发送的告警报文后，即可获知业务故障的类型；在此阶段，节点D_E不做任何处理。

6.根据权利要求1所述的面向业务的故障检测与定位方法，其特征在于：业务故障的起因可能是节点故障或链路故障，业务故障发生的位置为节点或链路故障的位置，所述的故障定位是指确定引起业务故障的原因并找出业务故障发生的具体位置；在故障确认阶段确定出业务故障的类型后，节点U_E生成的故障定位报文沿着业务转发路径的逆路径发送给源节点，节点D_E生成的故障定位报文沿着业务转发路径的方向发送给目的节点，然后由目的节点沿着事先建立的“弦”发送给源节点；该过程中，定位报文途经的正常节点将本节点ID封装到该定位报文中，源节点收到来自两个方向上的定位报文后通过相应的运算即可判断出业务故障发生的位置。

7.根据权利要求1所述的面向业务的故障检测与定位方法，其特征在于：所述的处理定位信息的手段为源节点将来自两个方向的定位信息同自身存储的显式路由信息进行比较，如果发现这些定位信息中缺少了某些节点的信息，则认为业务在该节点处发生了业务拥塞或者中断，通常这些节点位于节点U_E和D_E之间，；如果发现节点信息完整，则认为业务在节点U_E和D_E之间的链路上发送了业务拥塞或者业务中断，即上述定位信息中显示节点U_E和D_E为邻居节点时，表明业务故障是由节点U_E和D_E之间的链路发生了故障所引起的，上述定位信息中显示节点U_E和D_E不为邻居节点，表明业务故障是由节点U_E和_DE之间的节点发生故障引起的：将上述定位信息对应的节点ID和存储的显示路由中的节点ID做“异或”运算即可得到这些故障节点的ID。

Images