CN107682221A - 一种基于erps的链路状态检查方法及装置 - Google Patents

Abstract

本申请提供一种基于ERPS的链路状态检查方法及装置，应用于以太环网的主节点，所述主节点包括与相邻节点相邻的主端口和副端口，其中，所述副端口在目标链路正常时处于阻塞状态，所述方法包括：基于预设的周期，通过所述主端口发送健康状态检查报文；如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。本申请减少了各节点CPU处理CCM报文产生的资源消耗，避免了各节点CPU因处理大量报文导致CCM报文丢包，进而对以太环网链路状态产生误判，甚至导致以太环网频繁地切换链路的问题。

Description

一种基于ERPS的链路状态检查方法及装置

技术领域

本申请涉及通信技术领域，特别涉及一种基于ERPS的链路状态检查方法及装置。

背景技术

在大规模商用运营网络中，发生网络环路后长时间不能自愈将导致上层协议的中断，进而导致用户相关业务的中断。尤其是对于高质量的电信业务，比如3G/NGN(NextGeneration Network，下一代网络)语音、IPTV(Internet Protocol Television，网路协定电视)等，如果出现网络环路且超过50毫秒不能自愈，就会产生明显的语音视频异常，甚至出现业务中断。

目前电信级的以太环网的保护技术中，最重要的是ERPS(Ethernet RingProtection Switching，以太网多环保护技术)技术。ERPS的收敛时间与环网上的节点数无关，可应用于网络直径较大的网络；其中，节点可以是交换机。

在现有ERPS技术中，通过相邻的两个节点互相发送CCM(Continuity CheckMessage，连续性检查消息)报文来检测以太环网链路中是否处于正常状态。

具体地，相邻的两个节点可以周期性向对端发送CCM探测报文，若在预设的超时时间内无法接收到CCM回应报文，则确定两者间的链路发生故障。在这种情况下，这两个节点可以向网络中发送SF(Signal Failure，信号故障)报文。以太环网中控制备用链路(RingProtection Link)的开通与阻塞的主节点接收到上述SF报文后，可以开通备用链路，使得以太环网中的各节点能够正常通信。

发送SF报文的两个节点后续仍旧互相发送CCM探测报文，如果能够接收到对端发送的CCM回应报文，则可以确定两者间的链路恢复正常。在这种情况下，两个节点可以向网络中发送NR(No Request)报文。主节点接收到上述NR报文后，可以将备用链路切换回原来的链路。

通过相邻的两个节点互相发送CCM报文的方式来检测以太环网链路中是否处于正常状态，会使得以太环网中各节点都处理大量CCM报文，从而增大了节点CPU的开销。由于各节点还需要处理其它报文，可能造成CCM报文丢包，进而导致对以太环网链路状态的误判。如果出现多次误判，甚至会造成以太环网频繁地切换链路。

发明内容

有鉴于此，本申请提供一种基于ERPS的链路状态检查方法及装置，用以解决现有技术在检测以太环网链路中是否出现处于正常状态时，可能出现误判，导致以太环网的频繁地切换链路的问题。

具体地，本申请是通过如下技术方案实现的：

一种基于ERPS的链路状态检查方法，应用于以太环网的主节点，所述主节点包括与相邻节点相连的主端口和副端口，其中，所述副端口在目标链路正常时处于阻塞状态，包括：

基于预设的周期，通过所述主端口发送健康状态检查报文；

如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。

在所述基于ERPS的链路状态检查方法中，所述副端口预配置ACL表项；其中，所述ACL表项用于将所述健康状态检查报文上送至CPU处理。

在所述基于ERPS的链路状态检查方法中，所述方法还包括：

如果所述目标链路出现故障，开通所述副端口；

清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

通过所述主端口和所述副端口发送NR-RB报文。

在所述基于ERPS的链路状态检查方法中，所述方法还包括：

如果从所述副端口接收到所述健康状态检查报文，确定所述目标链路恢复正常。

在所述基于ERPS的链路状态检查方法中，所述方法还包括：

如果所述目标链路恢复正常，阻塞所述副端口；

清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

通过所述主端口和所述副端口发送NR-RB报文。

一种基于ERPS的链路状态检查装置，应用于以太环网的主节点，所述主节点包括与相邻节点相连的主端口和副端口，其中，所述副端口在目标链路正常时处于阻塞状态，包括：

发送单元，用于基于预设的周期，通过所述主端口发送健康状态检查报文；

确定单元，用于如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。

在所述基于ERPS的链路状态检查装置中，所述副端口预配置ACL表项；其中，所述ACL表项用于将所述健康状态检查报文上送至CPU处理。

在所述基于ERPS的链路状态检查装置中，所述装置还包括：

开通单元，用于如果所述目标链路出现故障，开通所述副端口；

清空单元，用于清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

所述发送单元，进一步用于通过所述主端口和所述副端口发送NR-RB报文。

在所述基于ERPS的链路状态检查装置中，所述确定单元，进一步用于：

如果从所述副端口接收到所述健康状态检查报文，确定所述目标链路恢复正常。

在所述基于ERPS的链路状态检查装置中，所述装置还包括：

阻塞单元，用于如果所述目标链路恢复正常，阻塞所述副端口；

所述清空单元，进一步用于清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

所述发送单元，进一步用于通过所述主端口和所述副端口发送NR-RB报文。

在本申请实施例中，以太环网的主节点可以基于预设的周期，通过主端口发送健康状态检查报文；如果在预设的超时时间内，主节点没有从副端口接收到所述健康状态检查报文，可以确定所述目标链路出现故障；

本申请技术方案通过主节点发送健康状态检查报文的方式，来检测以太环网链路中是否出现处于正常状态；以太环网中的其它节点无需互相发送CCM报文，从而减少了各节点CPU处理CCM报文的产生的资源消耗，并且避免了各节点CPU因处理大量报文导致CCM报文丢包，进而对以太环网链路状态产生误判，甚至导致以太环网频繁地切换链路的问题。

附图说明

图1是现有技术的一种网络架构示意图；

图2是现有技术的另一种网络架构示意图；

图3是现有技术的又一种网络架构示意图；

图4是本申请示出的一种基于ERPS的链路状态检查方法的流程图；

图5是本申请示出的一种网络架构示意图；

图6是本申请示出的另一种网络架构示意图；

图7是本申请示出的又一种网络架构示意图；

图8是本申请示出的一种基于ERPS的链路状态检查装置的实施例框图；

图9是本申请示出的一种基于ERPS的链路状态检查装置的硬件结构图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例中的技术方案，并使本发明实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对现有技术方案和本发明实施例中的技术方案作进一步详细的说明。

以太环网中若出现网络环路可能导致用户业务的中断，保护以太环网的技术的可靠性非常重要。

现有的以太环网的保护技术中，最重要的是ERPS技术。在ERPS技术中，通过以太环网的相邻节点互相发送CCM报文来检测以太环网链路是否处于正常状态。

参见图1，为现有技术的一种网络架构示意图，如图1所示，以太环网中有6个节点，其中交换机A(图中SWA)为主节点。主节点的a端口为主端口、b端口为副端口，主节点通过开通或阻塞副端口来实现备用链路的启用或关闭。

需要指出的是，由于接入各节点的设备与本申请涉及的技术无关，图中并未示出。

以太环网的目标链路为从SWA到SWB到SWC到SWD到SWE到SWF的链路；其中，上述目标链路指的是以太环网在未启用备用链路的情况下使用的链路。

如果目标链路处于正常状态，主节点会阻塞副端口，使得SWF无法通过a端口向主节点发送报文。当然，由于主节点的副端口预配置了若干ACL表项，SWF仍然可以通过a端口向主节点发送ERPS的相关报文。

如图1所示，各节点可以周期性向相邻的节点发送CCM探测报文，如果接收到对端返回的CCM回应报文，可以确定与对端之间的链路处于正常状态。

参见图2，为现有技术的另一种网络架构示意图，如图2所示，SWB和SWC之间的链路出现故障。SWB无法向SWC发送CCM探测报文，也无法接收到SWC发送的CCM回应报文，在这种情况下，SWB可以向以太环网中发送SF报文，并将故障链路端口(即SWB的a端口)设置为阻塞状态。同理，SWC也可以向以太环网中发送SF报文，并将故障链路端口(即SWC的b端口)设置为阻塞状态。需要说明的是，普通节点的端口同样预设置了若干将ERPS的相关报文上送CPU的ACL表项。

主节点SWA接收到上述SF报文后，可以确定目标链路中出现故障。

参见图3，为现有技术的又一种网络架构示意图，如图3所示，主节点确定目标链路出现故障后，放通了副端口，以启用备用链路。此外，由于以太环网中的链路变为从SWB到SWC到SWD到SWE到SWF到SWA的链路，主节点还可以清空本地MAC表项和地址解析表项，以重新学习上述表项，从而根据更新后的上述表项实现在新的链路中的报文转发工作。

其中，上述地址解析表项包括ARP(Address Resolution Protocol，地址解析协议)表项或ND(Neighbor Discovery，邻居发现)表项，取决于以太环网中设备配置的IP地址版本；如果以太环网中设备配置IPv4版本的地址，则上述地址解析表项为ARP表项；如果以太环网中设备配置IPv6版本的地址，则上述地址解析表项为ND表项。

除主节点以外，其它节点也需要更新本地的MAC表项和地址解析表项。主节点可以通过主端口和副端口向以太环网发送NR-RB(No Request.RPL Blocked)报文，以由各节点在接收到上述NR-RB报文后更新本地的上述表项。

在上述目标链路出现故障后，SWB和SWC仍周期性互相发送CCM探测报文。如果SWB从a端口接收到SWC发送的CCM回应报文，则SWB可以确定SWB与SWC之间的链路恢复正常，在这种情况下，SWB可以向以太环网发送NR报文，以通知各节点上述目标链路恢复正常。

或者，如果SWC从b端口接收到SWB发送的CCM报文，则SWC可以确定SWB与SWC之间的链路恢复正常，在这种情况下，SWC可以向以太环网发送NR报文，以通知各节点上述目标链路恢复正常。

主节点SWA接收到上述NR报文后，可以确定上述目标链路恢复正常，为防止出现网络环路，主节点可以阻塞副端口以关闭备用链路，并清空本地的MAC表项和地址解析表项。主节点可以向以太环网发送NR-RB报文，以由各节点在接收到上述NR-RB报文后更新本地的MAC表项和地址解析表项。

此外，SWB接收到上述NR-RB报文后，可以开通本地的故障链路端口(即SWB的a端口)；同理，SWC接收到上述NR-RB报文后，可以开通本地的故障链路端口(即SWC的b端口)。

现有技术中，通过相邻的两个节点互相发送CCM报文的方式来检测以太环网的链路是否连通，使得以太环网的每个节点都需要处理大量的CCM报文，增大了各节点的CPU的资源消耗。如果任一节点的CPU还在处理其它业务报文，则可能在业务繁忙时出现CCM报文丢包，造成对以太环网链路状态的误判。如果出现多次误判，会导致以太环网频繁切换链路。

有鉴于此，本申请提供了一种基于ERPS的链路状态检查方法，由以太网的主节点基于预设的周期，通过主端口发送健康状态检查报文；如果在预设的超时时间内，没有从主节点的副端口接收到上述健康状态检查报文，则可以确定目标链路出现故障。本申请链路状态的检查方法，无需以太环网中相邻的两个节点互相发送CCM报文，极大地减少了普通节点的CPU的资源消耗，也避免了因CCM报文丢包导致对以太环网链路状态误判，以及误判带来的以太环网频繁切换链路的问题。

参见图4，为本申请示出的一种基于ERPS的链路状态检查方法的流程图，该方法应用于以太环网的主节点，所述主节点包括与相邻节点相邻的主端口和副端口，其中，所述副端口在目标链路正常时处于阻塞状态；所述方法包括以下步骤：

步骤401：基于预设的周期，通过所述主端口发送健康状态检查报文。

步骤402：如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。

其中，上述主节点可以由人工指定，主节点通过开通或阻塞副端口来实现备用链路的启用或关闭。上述主节点经人工配置发送上述健康状态检查报文的周期时长(比如：周期时长为1秒)，以及接收上述健康状态检查报文的超时时间(比如：超时时间为3秒)。

上述副端口预配置ACL(Access Control List，访问控制列表)表项，上述ACL表项用于将上述健康状态检查报文上送至CPU处理。当然，上述副端口还可以预配置与现有技术相同的ACL表项，用于将ERPS技术中的CCM报文、SF报文、NR报文和NR-RB报文上述至CPU处理。

上述目标链路指的是以太环网在未启用备用链路的情况下使用的链路。

参见图5，为本申请示出的一种网络架构图，如图5所示，以太环网中有6个节点，其中交换机A(图中SWA)为主节点。主节点的a端口为主端口、b端口；其它节点的端口不区分主端口和副端口。

在本申请实施例中，主节点可以基于预设的周期，通过上述主端口发送健康状态检查报文；其中，上述健康状态检查报文的目的MAC被置为预设值，该预设值并非以太环网内设备的MAC地址，使得以太环网中的其它节点可以持续转发上述健康状态检查报文。

如图5所示，主节点SWA通过a端口向SWB发送健康状态检查报文(即图中的Health报文)；SWB可以将上述健康状态检查报文转发至SWC；SWC再将上述健康状态检查报文转发至SWD；SWD将上述健康状态检查报文转发至SWE；SWE将上述健康状态检查报文转发至SWF；SWF将上述健康状态检查报文转发至主节点SWA。

整个转发过程，上述健康状态检查报文经过目标链路两端的节点，最终返回主节点。如果目标链路处于正常状态，则主节点可以从副端口接收到上述健康状态检查报文。

在本申请实施例中，如果在预设的超时时间内，主节点没有从副端口接收到上述健康状态检查报文，则可以确定目标链路出现故障。

具体地，主节点在发送健康状态检查报文后，可以启动预设的定时器，如果该定时器达到超时时间，仍未接收到健康状态检查报文，则确定目标链路出现故障。如果在超时时间内，主节点接收到监控状态检查报文，可以将该定时器归零，重新开始计时。

通过主节点发送健康状态检查报文来检测以太环网链路是否处于正常状态，普通节点无需互相发送CCM报文，减少了普通节点处理CCM报文的CPU资源消耗。

在本申请实施例中，如果目标链路出现故障，主节点可以启用备用链路。

参见图6，为本申请示出的另一种网络架构示意图，如图6所示，由于SWB与SWC之间出现断路，使得目标链路出现故障。

主节点可以开通副端口来启用备用链路。如图6所示，主节点SWA开通了b端口，后续可以从b端口接收到业务报文，也可以从b端口转发业务报文。

由于以太环网链路发生变化，主节点需要更新本地的MAC表项、ARP表项和ND表项，以根据更新后的上述表项实现在新的链路中的报文转发工作。主节点可以在开通副端口后，清空本地的MAC表项和地址解析表项，以重新学习上述表项。其中，上述地址解析表项可以包括ARP表项或ND表项。

此外，以太环网的其它节点也需要更新本地的MAC表项、ARP表项和ND表项。因此，主节点可以通过主端口和副端口发送NR-RB报文。其它节点接收到上述NR-RB报文后，可以更新本地的MAC表项和地址解析表项。

在本申请实施例中，主节点确定目标链路出现故障后，仍基于预设的周期，通过主端口发送上述健康状态检查报文。

如果主节点从副端口接收到上述健康状态检查报文，则可以确定上述目标链路恢复正常。

参见图7，为本申请示出的又一种网络架构示意图，如图7所示，SWB和SWC之间的链路恢复正常，因此，SWB可以将接收到的上述健康状态检查报文转发至SWC，再由SWC转发至SWD。主节点可以从副端口接收到上述健康状态检查报文，从而确定上述目标链路恢复正常。

在本申请实施例中，主节点确定上述目标链路恢复正常后，可以关闭备用链路，重新启用目标链路。

具体地，主节点可以阻塞副端口，然后清空本地的MAC表项和地址解析表项，以重新学习上述表项。主节点可以根据更新后的上述表项实现在新的链路中的报文转发工作。

此外，主节点可以通过主端口和副端口发送NR-RB报文。其它节点接收到上述NR-RB报文后，可以更新本地的MAC表项和地址解析表项。

综上所述，在本申请技术方案中，主节点基于预设的周期，通过主端口发送健康状态检查报文；如果在预设的超时时间内，主节点没有从副端口接收到上述健康状态检查报文，则可以确定目标链路出现故障；

本申请通过主节点发送健康状态检查报文的方式检查以太环网的链路是否处于正常状态，相比现有技术，取消了普通的节点发送CCM报文的工作，从而减少了普通的节点的CPU处理CCM报文的资源消耗，并避免了因CCM报文丢包导致对以太环网链路状态产生误判，甚至导致以太环网频繁地切换链路的问题。

与前述基于ERPS的链路状态检查方法的实施例相对应，本申请还提供了基于ERPS的链路状态检查装置的实施例。

参见图8，为本申请示出的一种基于ERPS的链路状态检查装置的实施例框图：

如图8所示，该基于ERPS的链路状态检查装置80包括：

发送单元810，用于基于预设的周期，通过所述主端口发送健康状态检查报文。

确定单元820，用于如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。

在本例中，所述副端口预配置ACL表项；其中，所述ACL表项用于将所述健康状态检查报文上送至CPU处理。

在本例中，所述装置还包括：

开通单元830，用于如果所述目标链路出现故障，开通所述副端口。

清空单元840，用于清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项。

所述发送单元810，进一步用于通过所述主端口和所述副端口发送NR-RB报文。

在本例中，所述确定单元820，进一步用于：

如果从所述副端口接收到所述健康状态检查报文，确定所述目标链路恢复正常。

在本例中，所述装置还包括：

阻塞单元850，用于如果所述目标链路恢复正常，阻塞所述副端口。

所述清空单元840，进一步用于清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项。

所述发送单元810，进一步用于通过所述主端口和所述副端口发送NR-RB报文。

本申请基于ERPS的链路状态检查装置的实施例可以应用在以太环网的主节点上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在以太环网的主节点的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图9所示，为本申请基于ERPS的链路状态检查装置所在以太环网的主节点的一种硬件结构图，除了图9所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的以太环网的主节点通常根据该基于ERPS的链路状态检查装置的实际功能，还可以包括其他硬件，对此不再赘述。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种基于ERPS的链路状态检查方法，应用于以太环网的主节点，所述主节点包括与相邻节点相连的主端口和副端口，其中，所述副端口在目标链路正常时处于阻塞状态，其特征在于，包括：

基于预设的周期，通过所述主端口发送健康状态检查报文；

如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。

2.根据权利要求1所述的方法，其特征在于，所述副端口预配置ACL表项；其中，所述ACL表项用于将所述健康状态检查报文上送至CPU处理。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果所述目标链路出现故障，开通所述副端口；

清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

通过所述主端口和所述副端口发送NR-RB报文。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

如果从所述副端口接收到所述健康状态检查报文，确定所述目标链路恢复正常。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

如果所述目标链路恢复正常，阻塞所述副端口；

清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

通过所述主端口和所述副端口发送NR-RB报文。

6.一种基于ERPS的链路状态检查装置，应用于以太环网的主节点，所述主节点包括与相邻节点相连的主端口和副端口，其中，所述副端口在目标链路正常时处于阻塞状态，其特征在于，包括：

发送单元，用于基于预设的周期，通过所述主端口发送健康状态检查报文；

确定单元，用于如果在预设的超时时间内，没有从所述副端口接收到所述健康状态检查报文，确定目标链路出现故障。

7.根据权利要求6所述的装置，其特征在于，所述副端口预配置ACL表项；其中，所述ACL表项用于将所述健康状态检查报文上送至CPU处理。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

开通单元，用于如果所述目标链路出现故障，开通所述副端口；

清空单元，用于清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

所述发送单元，进一步用于通过所述主端口和所述副端口发送NR-RB报文。

9.根据权利要求8所述的装置，其特征在于，所述确定单元，进一步用于：

如果从所述副端口接收到所述健康状态检查报文，确定所述目标链路恢复正常。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

阻塞单元，用于如果所述目标链路恢复正常，阻塞所述副端口；

所述清空单元，进一步用于清空本地的MAC表项和地址解析表项；其中，所述地址解析表项包括ARP表项或ND表项；

所述发送单元，进一步用于通过所述主端口和所述副端口发送NR-RB报文。