基于GMPLS光网络的分布式多层故障定位方法

田军，崔贺

（西安邮电学院 通信工程系，陕西 西安 710061）

在GMPLS全光网络[1]下，要求具有高速的数据传输率的同时还要维持较高的服务质量（QOS），在这个推动力的作用下，需要对光的运行状况进行监控。而在光网络中出现故障是不可避免的，所以保障网络的鲁棒性[2]以及传输业务的可靠性的关键是快速的故障定位[3-4]。

一般来说，由于光网络的大容量性[5]，故障的定位并不是一件容易的事情。由于光层故障的传播性，有限的故障定位时间，有限的可利用的数字信息，在光网络中故障定位更加复杂。并且由于光层传输的透明性，一个故障可以引发大量的告警，导致告警的冗余。而故障定位机制是则根据由不同网络监控设备产生的告警（这些监控设备监控不同的运行参数，这些参数就是OSI不同层的运行参数）。也就是说，告警的性质和数量取决于监控设备放在哪个层以及这个监控设备的功能（能测什么样的参数）。

由于光网络内部的复杂性，传统的定位故障根源的方法是从单层开始的。典型的多层网络的恢复策略同样也是基于单层的观点。在光网络中，常用的一个方法是自下向上的故障恢复（第一层进行故障的定位），第一层（光层）尝试恢复发生故障的连接，假如没有成功，则由上层（第二层）尝试发起恢复。本文分析故障的发现，故障定位中面临的挑战，并在现有的GMPLS标准的基础上，提出了一种改进的故障定位方案。

1 GMPLS网络的故障管理

在GMPLS全光网络中因为故障的传播特性，故障定位的主要问题出现在网络核心结点或链路上（骨干网上），尤其对中等或大型网络更是如此。例如：如图1所示，相邻的结点（A，B）之间有一个故障，由于数据向下游流动，它会影响下游的数据链接（B，C），（C，D）。 从而导致大量的告警，进而引发故障的定位和保护/恢复处理。由于故障的传播，一个链路的故障会对其他链路产生影响，从而增加了定位故障根源的复杂性。更糟糕的是可能会引起没有必要的保护和恢复机制操作。

图1 故障的传播Fig.1 Spread of failure

故障定位的方法可分为：分布式和集中式。集中式的方法利用单个实体（故障管理体系），它接收由监测设备发出的所有告警，然后进行过滤和告警的相关操作，根据全局信息去定位故障的根源。分布式的方法则是在全光网络的每个结点放置一个故障处理单元，然后在运行一个协议去传播故障管理的信息，从而定位故障的根源。

对于分布式方案，依靠实时的信息或通知消息去定位故障的根源。一个具有代表性的分布式定位方法是LMP协议，它是GMPLS协议族的一部分。LMP需要另外分出一个监控信道去定位故障，因为当光纤发生故障时不会影响监控信道的工作。其他的方法都是在处理当故障影响监控信道时的故障定位，实质是对LMP协议的完善。

2 故障的发现以及跨层定位

多层网络有两个没有解决的问题：1）各个层中功能重叠。也就是说，有些层执行类似的功能；2）一个故障会影响许多层。本节我们将关注应用到故障管理框架下的这两个没有解决的问题。

2.1 多层故障的发现

因为节点的每一层都安装了检测装置，所以当故障发生时每一层都能检测到。而由于光网络中故障的传播，许多其他的下游光路会发出告警。一个故障引发许许多多的告警，有效的多层故障发现的机制随之产生。必须强调的是多层故障发现的告警提供的是冗余信息、互补信息还是其他信息？当这个告警的目的是引发恢复机制时，存在两个主要策略会避免多层同时启动恢复机制。这两个策略是规定延时时间和恢复标志信号。换句话说，多层的故障发现告警对于时间顺序结构是互补的，但是在某一时刻的时间是冗余的。

2.2 跨层的故障定位

对于看到的症状对应最有可能的解释是一个NP困难问题。但是，上层需要下层提供的服务（下层决定上层），所以经常会出现一个现象：一个很小的下层问题会对上层的业务产生很大的影响。所以，在故障管理中要融合跨层的故障诊断。目前，很难实现上述的目标，因为故障在向上层传时语义也随之改变。其次，建立一个体系模型是非常困难的，以及在这个系统中分析也是很复杂的。由于在两个节点相同层之间的故障的水平传播，以及在节点内，故障的垂直传播。目前还没有完善的故障定位技术。总之，要完全的解决上述问题需要融合不同的技术。

在数据高速率传输的网络中另一个非常重要的方面是故障定位的时延。因为它直接影响到业务量的丢失。当发生故障时，数据包将一直丢失，直到把连接转换到备用连接上才可以进行正常的通信（这个备用连接是在铺设网络时预留的，或在发现故障时快速临时建立的）。故障定位的时延Tloc=Tdet+Thold-off+Tnotif。Tdet是故障发现的时间 （由监控技术决定）。Thold-off是截止时间，由多层网络中故障定位策略决定（定时器或恢复标志信号）。Tnotif是故障的通知时间，当定位了故障根源并把它隔离后完成送信息的时间（由故障的通知方法和信息传递的时间决定）。

3 改进的多层故障定位

在GMPLS多层网络中，高效的故障定位应该考虑下面的参数：在维持少的定位时延下对于Capex和Opex的支出。Capex包括：故障发现以及全网络的监控设施的投入（节点的各个层次的监控的投入）。Opex包括：在保证网络的QOS和生存性的条件下，故障定位以及恢复策略。在GMPLS多层网络故障定位，高效的故障定位要考虑下面的一些因素。1）故障的发现应尽可能近的接近故障的源头；2）利用光层完成光复用有关的操作；3）利用多层的故障发现机制；4）利用上层的反馈；5）光路保护和链路保护的相结合。

综合考虑上述因素，一方面，可以认识到高层OSI协议栈中包含容纳故障的能力。其次在数据传输网络中的大多数协议，他们为了发现传输过程中的故障检测都对传输数据进行了冗余编码。目前并不把这些反馈提供给物理层（光层）。但是，为了保证QOS，提出了利用上层反馈的跨层策略。另一方面，考虑到上层的监控设备。曾经在光网络中应用的自下而上的策略恢复机制是可以应用在故障的定位。如果低层不能轻易的定位故障根源，则这个故障的定位的任务将交给上层的监控器。

3.1 实际中的GMPLS网络的故障定位

在实际的GMPLS网络中LSP是分层的，例如发端IP网络要与一个收端IP网络建立500 Mbps信道带宽，则现实的网络模型如图2所示。

图2 现实情况下的故障定位Fig.2 Fault localization in reality

利用GMPLS协议可以实现分层的LSP。则它的故障定位算法流程算法如图3所示。

由GMPLS的节点可知LSR3与LSR4能够检测到WDM的故障与frame的故障，LSR2与LSR5能够检测到时隙帧的故障与分组的故障。LSR1与LSR6只能检测分组的故障。

下面举例说明：假如第1种情况，LSR1与LSR2之间发生故障则首先LSR3与LSR4的WDM监控检测到故障，进行关联操作之后，LSR3把WDM层的告警通知距离它最近的具有帧检测能力节点进行时隙帧检测，之后在和LSR2的帧检测进行关联操作，LSR1的分组检测进行关联操作，最终定位故障的根源LSR1的输出链路上。假如第2种情况，在LSR4与LSR5之间发生故障，则LSR3与LSR4的WDM检测没有检测到故障，但是LSR5的帧检测检测到故障，它与LSR3的第2层进行相关操作，进而定位故障在LSR3的输出端。

3.2 算法中所用的故障定位协议

上述算法用到的协议是改进的LMP协议[6]。它是通过控制平面来实现故障的定位。当第1层发现故障时，则第一层的监控设备就会向控制平面发送一个告警信号，同理，第2层，第3层检测到故障时，也会向控制平面发送告警信号。下文以第一层为例，说明改进的LMP协议。

图3 有LSP分层的故障定位流程图Fig.3 LSP hierarchical flow diagram of the fault localization

一般来说，两个相邻节点的数据链路故障可以影响许多下游链路（下游指的是数据的流动），从而造成许多告警进而触发保护和恢复的处理。为了避免不必要的保护和恢复处理，提高网络的效率，必须有一个快速，简单的故障定位方案。虽然目前的GMPLS标准提供了方法去定位和数据链路的故障，但是这个方案没有全面的考虑。造成了不必要的资源浪费。

通过对故障定位机制的定义，当一个数据链路故障发生时，每个发现故障的下游节点将通知上游临近的节点一个消息。这个消息是故障链路信息中的一个—链路状态信息。每个上游节点一旦收到这个故障通知信息，他就会给临近的下游节点一个链路状态信息收到的确认信息，目的是通知下游节点我已经收到了链路状态信息。接着，凡是收到故障通知的节点将执行各自的故障相关处理。从而判断故障是否是相应的LSP中的本身的故障。如果上游节点发现这个故障是自己内部的或输出端口的，则这个上游节点定位这个故障，然后发送一个故障的告警去引发相应的路径保护和恢复处理。同时，所有的收到故障通知的节点将给他的相应的下游节点发送一个信道状态的信息去指示目前那个有问题链路的状态（故障或正常）。如果下游节点没有收到信道状态信息，他将请求他的上游节点发送信道状态信息，也就是下游向上游发送信道状态信息请求信息。上游节点收到信道状态信息请求信息必须回复一个信道状态回复信息去告之下游节点链路的状态。在目前的方案中，两个相邻节点故障定位的过程可以用图4来说明。在一个拥有许多节点的网络中，受到数据链路故障影响的所有相邻节点有相同的过程。

图4 目前方案下相邻节点的故障定位处理Fig.4 Adjacent nodes of the fault location processing

这个故障定位方案有两个严重不足的地方从而导致网络性能的下降。首先，所有收到故障通知信息的节点将执行故障相关的操作。事实上，没有必要每个节点都执行故障相关的操作，只有那些与故障相邻的节点执行故障相关的操作就已经足够去定位故障。这将导致许多没有必要的故障处理，而且因为占用许多网络资源，会造成网络节点的效率降低，影响其他的一些紧迫操作。其次，在目前的故障定位过程有许多的冗余信息。目前的故障定位处理过程中，受到故障影响的每对相邻节点至少要3个信息的交互。而通过修改发送信息的顺序，其实2个信息就足够完成同样的功能。当一个数据链路的故障影响许多节点时，冗余的信息交互很大的浪费了控制信道的资源，增加了网络节点的负担。

3.3 改进的故障定位方案

基于上述提到的问题，文中提出一个新的故障定位处理方法，该方法应用双向数据链路故障通知方法取代最新的GMPLS标准下的方案。在此方案中，当一个节点发现一个数据链路故障时，他将同时向上游和下游节点发送链路状态信息。发送到上游相邻节点的信息被用来通知链路故障，他的作用几乎和目前解决方案中发送的链路故障信息的作用一样。发送到下游相邻节点的链路状态信息有两个作用。一个是通知下游节点它们之间的链路是正常的。这样就可以避免了正常的数据链路被错误的隔离以及消除不必要的故障相关操作；另外一个作用是通知下游节点它已经找到了链路的故障，它已经收到了从下游节点发来的故障通知信息从而避免了同样的信息重复发送。

当一个节点收到故障通知信息时，将证实是否已经在它们之间的链路上发现了故障。如果节点没有在它们之间的链路上发现故障的记录，他将执行故障关联处理，确定故障的位置，这个操作和目前故障定位的操作类似。一旦定位了这个故障，这个节点就发送故障告警信息发起相应的路径保护和恢复处理。然后，通知它的下游相邻节点这个问题的链路的状态。相反，如果节点收到了故障通知消息，它正好也检测到这个链路的故障，就确认这个故障发生在上游链路，这个节点没有必要执行故障定位操作。所以这个节点忽略了故障通知信息。图5说明了在有4个节点网络的新方案。通过应用新的方案，有下面的优势：

图5 改进的故障定位方案Fig.5 Improved fault localization program

1）对于定位数据链路故障的信令的开销可以大幅降低。除了在受到链路故障影响的大多数相邻节点之间的信令的交互和目前的方案相同，其他的节点通过两个方向同时通知链路发生了故障，用了两个信令信息完成了相同的功能（目前的方案用3个信令信息）。因为数据链路的故障经常影响网络中的许多节点，所以该方案可以大幅减少定位链路故障的信令的开销。

2）大幅降低占用的网络资源。在我们的方案中，受到故障影响的所有节点，仅仅一个节点需要执行故障相关操作。因此，网络节点定位故障的时间大幅降低。由于减少了信令开销，从而降低了控制信道的带宽和节点的信息处理时间。

3）可以避免错误的隔离正常的链路。在此方案中，当一个数据链路故障发生时，受到影响的链路的状态将快速的通知相应的受到影响的节点。这个方法可以避免正常数据链路由于上游节点的故障而被错误的隔离，这些正常的链路还可以用来支持新的连接建立的请求。所以避免了不必要的网络资源浪费，降低网络资源的阻塞率。

4 结束语

GMPLS光网络作为下一代新型网络，它需要具有高速的数据传输率以及高质的服务质量，因而一旦出现故障将会对网络造成很坏的影响，所以故障的快速定位就显得尤为重要。本文在GMPLS光网络现有的标准下提出了一种改进的故障定位方案，完善了其故障定位方面的一些功能，这对GMPLS光网络的发展有着一定意义。

[1]E.Mannie Ed.Generalized Multi-Protocol Label Switching（GMPLS） Architecture[S].Interface，2004.

[2]Pinart C.A multilayer fault localization framework for IP over all-optical multilayer networks[J].IEEE Network，2009（5）:4-9.

[3]GUO Hai-bo，KUO Geng-sheng.Improvements on fault localization in GMPLS-based networks[J].IEEE HPSR，2005（5）:94-99.

[4]Li G，Yates J，Wang D，et al.Control plane design for reliable optical networks[J].IEEE Communication Magazine，2002（2）:90-96.

[5]Banerjee A，Drake L，Lang L，et al.Generalized multiprotocol label switching:an overview of signaling enhancements and recovery techniques[J].IEEE Communication Magazine，2001（7）:144-151.

[6]Ed J L.Link management protocol （LMP）[J].IETF RFC 4204，2005（10）:12-15.