CN107968747A - 一种路径调整管理方法及装置、通信系统 - Google Patents

Abstract

本发明实施例提供了一种路径调整管理方法及装置、通信系统；该方法包括：检测与数据转发设备的控制面开放流连接状态；在检测到与第一数据转发设备的控制面开放流连接中断时，获取与第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；根据转发面数据转发链路状态，管理经过第一数据转发设备的通信路径的路径调整。本发明通过在控制器检测到与数据转发设备之间的控制面开放流连接中断时，通过与该数据转发设备建立通信的数据转发设备来确定转发面数据转发链路的实际状态，进而判断是否需要调整，避免了无疑义的调整，解决了现有控制器误判交换机故障导致无意义路径调整的问题。

Description

一种路径调整管理方法及装置、通信系统

技术领域

本发明涉及通信领域，尤其涉及一种路径调整管理方法及装置、通信系统。

背景技术

在通信系统，如SDN(Software Defined Network，软件定义网络)通信系统中，下层数据转发设备的数据转发受到上层控制设备的控制，这种控制主要体现在数据的转发路径上。以SDN为例，其包括控制面的控制器(Controller，简称C)和转发面的交换机(Switch，简称SW或者S)两部分构成，控制器Controller和交换机Switch之间通过开放流OPENFLOW(简称OF)协议下发控制指令，指导交换机上的数据流转发。

在现有技术中，若控制器C检测到交换机S之间的保活路径断链时，认为交换机S故障或者下线，就会将经过这个交换机S的数据转发路径调整到其他交换机S上。

在实际应用中，控制器C与交换机S之间的控制面开放流连接堵塞时，也会导致控制器C与交换机S之间的保活消息不能及时送达，进而控制器C认为与交换机S之间的控制面开放流连接中断，错误的认为交换机S下线或者故障，执行路径调整，这种路径调整是没有意义的。

发明内容

本发明实施例提供了一种路径调整管理方法及装置、通信系统，以解决现有控制器误判交换机故障导致无意义路径调整的问题。

一方面，提供了一种路径调整管理方法，包括：

检测与数据转发设备的控制面开放流连接状态；

在检测到与第一数据转发设备的控制面开放流连接中断时，获取与第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；

根据转发面数据转发链路状态，管理经过第一数据转发设备的通信路径的路径调整。

一方面，提供了一种路径调整管理装置，包括：链路保活模块及路径调整模块，其中，

链路保活模块用于检测与数据转发设备的控制面开放流连接状态；在检测到与第一数据转发设备的控制面开放流连接中断时，触发路径调整模块；

路径调整模块用于获取与第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；根据转发面数据转发链路状态，管理经过第一数据转发设备的通信路径的路径调整。

一方面，提供了一种通信系统，包括：控制器以及与控制器连接的多个交换机，其中，控制器设置有本发明实施例提供的路径调整管理装置，交换机作为数据转发设备，在控制器的控制下进行数据转发。

另一方面，提供了一种计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于执行前述的路径调整管理方法。

本发明实施例的有益效果：

本发明实施例提供了一种路径调整管理方法，该方法通过在控制器检测到与数据转发设备之间的控制面开放流连接中断时，通过与该数据转发设备建立通信的数据转发设备来确定两个数据转发设备之后转发面数据转发链路的实际状态，进而判断是否需要调整，避免了无疑义的调整，解决了现有控制器误判交换机故障导致无意义路径调整的问题。

附图说明

图1为本发明第一实施例提供的路径调整管理方法的流程图；

图2为本发明第二实施例提供的路径调整管理装置的结构示意图；

图3为本发明第三实施例涉及的通信系统的组网示意图；

图4为现有路径调整管理方法的第一种示意图；

图5为现有路径调整管理方法的第二种示意图；

图6为本发明第三实施例涉及的路径调整管理方法的第一种示意图；

图7为本发明第三实施例涉及的路径调整管理方法的第二种示意图；

图8为本发明第三实施例涉及的路径调整管理方法的第三种示意图；

图9为本发明第三实施例涉及的路径调整管理方法的第四种示意图；

图10为本发明第三实施例涉及的路径调整管理方法的第五种示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例只是本发明中一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现通过具体实施方式结合附图的方式对本发明做出进一步的诠释说明。

第一实施例：

图1为本发明第一实施例提供的路径调整管理方法的流程图，由图1可知，本实施例提供的路径调整管理方法包括：

S101：检测与数据转发设备的控制面开放流连接状态；

S102：在检测到与第一数据转发设备的控制面开放流连接中断时，获取与第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；

S103：根据转发面数据转发链路状态，管理经过第一数据转发设备的通信路径的路径调整。

一些实施例中，上述实施例中的路径调整管理方法在获取第二数据转发设备的转发面数据转发链路状态之前，还包括：

检测与第二数据转发设备的控制面开放流连接状态；

若检测到与第二数据转发设备的控制面开放流连接中断，不调整经过第一数据转发设备的通信路径。

在实际应用中，控制器与多个数据转发设备都断链的情况很难出现，若出现则很大程度上代表着控制器本身出现了故障或者宕机，此时代表着转发面的数据转发设备没有发送故障，为了避免无效调整，则不应该调整路径。

一些实施例中，上述实施例中的获取转发面数据转发链路状态包括：

向第二数据转发设备发送查询消息，查询消息用于查询第二数据转发设备维护的第一数据转发设备与第二数据转发设备之间转发面数据转发链路的转发面数据转发链路状态；

接收第二数据转发设备返回的转发面数据转发链路状态。

一些实施例中，上述实施例中的根据转发面数据转发链路状态，管理经过第一数据转发设备的通信路径的路径调整包括：

当转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链时，调整经过第一数据转发设备的通信路径；

当转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常时，不调整经过第一数据转发设备的通信路径。

一些实施例中，上述实施例中的获取转发面数据转发链路状态还包括：

检测在预设时长内，是否监听到第二数据转发设备上报的状态上报事件；

若监听到状态上报事件为断链，则判定转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链，调整经过第一数据转发设备的通信路径；

若没有监听到状态上报事件或者状态上报文事件为定期保活事件，则判定转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常，不调整经过第一数据转发设备的通信路径。在实际应用中，定期保活事件代表着第一数据转发设备与第二数据转发设备在进行这定期保活，那么两者之间的转发面数据转发链路就是正常的。

在实际应用中，预设时长可以是控制面开放流连接的保活周期T1，也可以是转发面数据转发链路的保活周期T2，还可以是在控制器检测到与第一交换机之间的控制面开放流连接中断的时刻T0到下一个转发面数据转发链路的保活时刻t之间的差值T3与保活周期T2之和T4(T4＝T3+T2)。

第二实施例：

图2为本发明第二实施例提供的路径调整管理装置的结构示意图，由图2可知，本实施例提供的路径调整管理装置包括：链路保活模块21及路径调整模块22，其中，

链路保活模块21用于检测与数据转发设备的控制面开放流连接状态；在检测到与第一数据转发设备的控制面开放流连接中断时，触发路径调整模块；

路径调整模块22用于获取与第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；根据转发面数据转发链路状态，管理经过第一数据转发设备的通信路径的路径调整。

在一些实施例中，上述实施例中的路径调整模块22在获取第二数据转发设备的转发面数据转发链路状态之前，还用于检测与第二数据转发设备的控制面开放流连接状态，若检测到与第二数据转发设备的控制面开放流连接中断，不调整经过第一数据转发设备的通信路径。

在一些实施例中，上述实施例中的路径调整模块22用于向第二数据转发设备发送查询消息，查询消息用于查询第二数据转发设备维护的第一数据转发设备与第二数据转发设备之间转发面数据转发链路的转发面数据转发链路状态；接收第二数据转发设备返回的转发面数据转发链路状态。

在一些实施例中，上述实施例中的路径调整模块22用于当转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链时，调整经过第一数据转发设备的通信路径；当转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常时，不调整经过第一数据转发设备的通信路径。

在一些实施例中，上述实施例中的路径调整模块22用于检测在预设时长内，是否监听到第二数据转发设备上报的状态上报事件；若监听到状态上报事件为断链，则判定转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链，调整经过第一数据转发设备的通信路径；若没有监听到状态上报事件或者状态上报文事件为定期保活事件，则判定转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常，不调整经过第一数据转发设备的通信路径。

对应的，本发明实施例还提供了一种通信系统，包括：控制器以及与控制器连接的多个交换机，其中，控制器设置有图2所示实施例提供的路径调整管理装置，交换机作为数据转发设备，在控制器的控制下进行数据转发。

在实际应用中，图2所示实施例中的所有功能模块，都可以采用处理器、编辑逻辑器件等方式实现。

第三实施例：

现结合具体应用场景对本发明做进一步的诠释说明。

本实施例以简单的SDN网络为例进行说明。

图3是SDN网络技术的简单示意图，SW1，SW2和SW3是受控OPENFLOW交换机，即作为数据转发设备的交换机SW1、SW2和SW3是控制器通过上述的控制面开放流连接控制的交换机，在本实施例中，控制面开放流连接具体为openflow链接。为了清晰，这里只展示了环形TOPO(Topology，拓扑)的三台交换机，在实际布网中，可以是任何TOPO的任何数量的交换机，每台SW上挂接着数量不等的主机，主机与主机之间有通信需求，例如，主机1与主机2通信，数据流可以通过SW1-SW2进行通信，即数据转发设备SW1和SW2之间存在转发面数据转发链路，并借此链路完成数据转发等通信业务，也可以经过SW1-SW3-SW2进行通信，即数据转发设备SW1和SW2、SW2和SW3之间分别存在转发面数据转发链路，并借此链路完成数据转发等通信业务。一般情况下，控制器会选择一个最优的路径用于通信，如果最优路径断链，需要将数据流切换到次优的路径上，如图中所示，在SW1与SW2之间的链路故障后，业务数据流从路径SW1-SW2切换到了路径SW1-SW3-SW2。

如图4所示，在承载网网络中，控制器Controller对SW之间里的链路发现和TOPO形成都是通过LLDP(Link Layer Discovery Protocol，链路层发现协议)完成的。LLDP发现链路的速度较慢，因此又引入了BFD的快速链路检测机制用于快速检测SW之间的链路状态(图4中的CASE1)：控制器下发BFD(Bidirectional Forwarding Detection，双向转发检测)配置参数控制交换机生成双向BFD会话(参见图4步骤401)。交换机通过BFD会话保活机制周期性检测转发面链路故障(参见图4步骤402-405)，如果出现了链路故障事件，则将链路故障事件通过OPENFLOW协议上报给控制器(参见图4步骤406a-406b)。控制器根据链路故障事件调整路径，并向交换机更新的流表和组表(参见图4步骤S407-408)，保证数据流切换到备用路径上(参见图3中的两条虚线，划线代表原业务传输路径，当链路出现问题后，业务传输路径切换到虚线方式)。当链路恢复后(BFD检测链路恢复的机制比较复杂，并且与本发明关系不大，再次不做深入介绍)，控制器获取该事件，并将业务数据流调整回到原来的路径(参见图4的409a-409c)；

另外，还有一种情况会影响业务数据流在不同的路径上的调整(参见图4中的CASE2)。因为调整路径的决策方是在控制器，如果控制器和交换机(例如SW1)之间的openflow通信中断的话(参见图4步骤410，为了继续传输业务数据流，控制器默认做法是认为交换机之间的链路断链(参见图4步骤411a)，做出路径调整(参见图4步骤411b)：控制器向交换机更新的流表和组表(参见图4步骤412)，保证数据流切换到备用路径上(同样可以参见图3中的两条虚线)。如果控制器和SW之间的链路恢复，控制器再通过链路调整路径，将业务数据流调整到原来路径(参见图4步骤413-416)。

对比图4中的CASE1和CASE2，会发现CASE1中做出的路径调整是必需的，否则会造成业务数据流的终止，是一种对链路故障问题的应对操作；而CASE2中做出的路径调整大部分场景下是不必要的，多余的。因为控制器与SW失联，并不代表SW之间的链路一定故障，实际上是出现了链路故障的误判而强行将链路切换，从初始状态和最后openflow通信恢复后的状态对比来看，中间的调整可能就是多此一举，还可能在链路切换中造成了额外的流表反复操作和因路径切换带来的业务传输质量被影响。但是如果控制器与SW失联的情况下不将路径做调整，又有可能此时恰巧SW1-SW2之间的链路出现故障而导致业务数据流无法及时切换到备用路径上。这是现有技术中存在的一个问题。

如图5所示，除了BFD检测机制以外，在移动通信网络的核心网EPC(evolvedpacket core，演进的分组核心网)中，也存在类似的问题。在此简单的介绍一下EPC中的路径检测机制。EPC场景下，Controller除了控制承载网的链路状态之外，还充当EPC网络的网关(GW，GateWay)的控制面功能，SW上执行EPC网络的网关的转发面功能。控制器向EPC网关下发GTP-U(GPRS Tunnel Protocol，GPRS隧道协议)的上下文信息(图5中的501a-501b)，EPC网关之间进行GTP隧道(此GTP隧道是上述的转发面数据转发链路的一种具体实现形式)的链路探测功能(图5中的502a-502d)：EPC网关通过发送GTP Echo Request(GTP回声请求)和接收GTP Echo Response(GTP回声响应)来判断链路的状态。当检测到链路出现问题的时候，上报控制器，控制器进行路径调整(与BFD的调整机制类似)。EPC场景下，也会存在控制器与EPC网关失去Openflow链接(Openflow链接即上述的控制面开放流连接的一种具体实现形式)的情况，因此也会导致出现类同BFD场景下同样的问题：链路故障误判了，路径调整是多此一举的。

根据以上分析，采用了SDN技术的网络中的链路检测存在一个普遍的问题：因Openflow通信受阻对SW之间的链路出现误判，从而导致路径做频繁切换。本发明正是针对该问题提出了一种解决方案。

针对上述问题，本实施例提供了一种软件定义网络中解决因链路故障误判而导致路径频繁切换的方法和系统，以至少解决因此而带来对业务数据流传输造成影响的问题。

具体的，控制器在感知到与第一SW之间的openflow连接中断的情况下，查询与第一SW存在链路维护机制的第二SW侧的的链路的状态。根据获取到的结果判断第一交换机与第二交换机之间的链路状态，并对路径调整或者不调整。

进一步的，“查询与第一SW存在链路维护机制的第二SW侧的的链路的状态，可以是以下几种方式的一种：

控制器根据在一个链路保活周期内收到/没有收到对端交换机的断链事件。

控制器主动向对端交换机发送查询通知，查询链路是否断链的。

控制器一个链路保活周期内检测到对端交换机与控制器之间的openflow也中断了。

进一步的，“获取到的结果判断该交换机与对端交换机之间的最可能的链路状态”，可以是以下几种方式的一种：

控制器根据在一个链路保活周期内收到/没有收到对端交换机的断链事件，断定链路是断链/没有断链的。

控制器从对端交换机查询到断链/没有断链状态。

控制器检测到对端交换机与控制器之间的openflow也中断了，则判断SW与对端SW之间断链。

进一步的，“与该SW存在链路维护机制”可以是以下几种中的一种：

GTP链路维护，或者BFD链路维护。

现结合具体的场景进行说明。

场景一

在本场景中提供了一种解决路径频繁切换的方法，图6，7,8是根据本场景一的流程图，控制器在感知到与SW1之间的openflow通信中断的情况下，主动向SW2查询SW2上维护的SW1->SW2的链路状态。根据查询到的结果做出处理：

场景a：SW2上维护的SW1->SW2之间的链路没有断链(对应图6)，因此控制器最终断定SW1和SW2之间的链路是良好的，无需发起路径切换的操作。

场景b：SW2上维护的SW1->SW2之间的链路确实断链(对应图7)，因此控制器最终判定SW1和SW2之间的链路是故障的，发起路径切换的操作；

场景c：控制器与SW1之间openflow断链时刻，控制器检测到与SW2之间的链路也断链了(对应图8)，在这种情况下，控制器已经无法控制SW1和SW2上的链路，也无法实现路径调整，控制器等待交换机重新接入。如果一端交换机SW1接入了，并且从该SW1交换机侧判断链路良好的情况，也断定该SW1和SW2之间链路良好。

通过本实施例，避免了在SW1与SW2之间链路良好的情况下，因为openflow通信中断而误判为SW1与SW2之间链路故障的情况。

场景a完整的执行步骤如下：

步骤601：控制器与SW1之间的openflow通信中断，控制器感知该事件。

步骤602：控制器主动向SW2发送链路状态查询消息，查询SW2上维护的SW1->SW2的链路的状态。

查询消息为Openflow消息族的消息加功能扩展字段或者是新扩展消息类型。例如：Openflow消息可以是flow_mod_msg，或者是mutipart_request消息，或者是新增的openflow消息。

查询消息中携带源SW(SW1)和目的SW(SW2)的ID(一般为DPID(datapathidentity)，或者deviceid)。

查询消息中还可以携带查询指示，用于指示查询的信息内容和操作。

步骤603：收到查询请求的交换机SW2，上报自身维护的SW1与SW2之间的链路状态信息。

链路上报消息为Openflow消息族的消息加功能扩展字段或者是新扩展消息类型。例如，Openflow消息可以是port_status_msg或者是新增的openflow消息。

该场景下，上报的链路状态是：无断链。

步骤604:控制器根据SW2上报的链路状态(在本场景中是无断链)做出决策——不执行路径调整。

步骤605：某段时间后，SW1与控制器之间的openflow通信恢复；

步骤606：链路维护机制、业务流转发机制恢复到初始状态。

场景b完整的执行步骤如下：

步骤701-702：同步骤601-602；

步骤703：收到查询请求的交换机SW2，上报自身维护的SW1与SW2之间的链路状态信息。

链路上报消息为Openflow消息族的消息加功能扩展字段或者是新扩展消息类型。例如：Openflow消息可以是port_status_msg或者是新增的openflow消息。

该场景下，上报的链路状态是：断链。

步骤704:控制器根据SW2上报的链路状态(在本场景中是断链)做出决策——执行路径调整。

步骤705：控制器向对应的交换机下发/更新openflow流表，实现流量的路径切换，将业务数据流引导到备用路径上。

某段时间后，SW1与SW2之间的链路恢复，控制器再通过更新/下发流表，将业务数据流引导回原路径。

场景c完整的执行步骤如下：

步骤801：同步骤601；

步骤802：控制器与SW2之间的openflow通信也中断了；

步骤803：控制器无法控制SW1和SW2上的链路，也无法实现路径调整，控制器等待交换机重新接入。如果一端交换机SW1接入了，并且从该SW1交换机侧判断链路良好的情况，也断定该SW1和SW2之间链路良好。

场景二

在本场景中提供了一种解决因链路误判导致路径频繁切换的方法，图9，10是根据本发明场景二的流程图，控制器上分别维护了SW1侧的SW2->SW1的链路状态，和SW2侧的SW1->SW2的链路状态。在控制器检测到控制器与SW1之间openflow通信中断时，通过查询单位保活周期内、控制器上维护的、SW2侧的、SW1->SW2的链路状态。根据查询到的结果做出处理：

场景d：如果单位保活周期内SW1->SW2之间的链路是良好的(对应图9)，无需发起路径切换的操作。

场景e：如果单位保活周期内SW2上维护的SW1->SW2之间的链路出现断链(对应图10)，控制器发起路径切换的操作；

场景f：控制器与SW1之间openflow断链时刻，控制器检测到与SW2之间的链路也断链了(对应图8)，在这种情况下，控制器已经无法控制SW1和SW2上的链路，也无法实现路径调整，控制器等待交换机重新接入。如果一端交换机SW1接入了，并且从该SW1交换机侧判断链路良好的情况，也断定该SW1和SW2之间链路良好。(本场景与实施例一的场景三是一致的，因此后面不做累述)

通过本实施例，避免了在SW1与SW2之间链路良好的情况下，因为openflow中断而误判为SW1与SW2之间链路为故障的情况，避免了链路的频繁切换。

场景d完整的执行步骤如下：

步骤901：控制器与SW1之间的openflow通信中断，控制器感知该事件。

步骤902：控制器主动查询在一个链路保活周期内的、维护于控制器上的、SW2侧的、SW1->SW2的链路状态。具体的实现方式可以是：控制器主动监测SW2的上报事件，如果在一个保活周期内没有收到SW2的状态消息，则认为SW1与SW2之间的链路完好。

步骤904：在一个保活周期内没有收到链路断链的事件，控制器断定SW1和SW2之间的链路无断链，不执行路径调整。

步骤905：某段时间后，SW1与控制器之间的openflow通信恢复；

步骤906：链路维护机制，业务流转发机制恢复到初始状态。

场景e完整的执行步骤如下：

步骤1001：同步骤901；

步骤1002：控制器主动查询在一个链路保活周期内的、维护于控制器上的、SW2侧的、SW1->SW2的链路状态。具体的实现方式可以是：控制器主动监测SW2的上报事件，如果在一个保活周期内确实收到了SW2的状态上报事件(只要上报就是代表链路故障)，则认为SW1与SW2之间的确实出现故障。

步骤1004:控制器执行路径调整。

步骤1005：控制器向对应的交换机下发/更新openflow流表，实现流量的路径切换，将业务数据流引导到备用路径上。

某段时间后，SW1与SW2之间的链路恢复，控制器再通过更新/下发流表，将业务数据流引导回原路径。

场景f的执行操作完全同场景一的场景c，在此不做累述。

以上两个场景都是以SW1与控制器之间的openflow通信中断来说明的，实际网络中，可能是任何交换机SWi与控制器之间的openflow通信中断，控制器通过判断SWi->SW1,SWi->SW2,SWi->SW3,SWi->SWx....的情况。因此以SW1和SW2仅作举例说明，不局限于特定的交换机。而且，与某一个交换机建立链路的有很多其他的交换机对端，一旦某一个交换机与控制器的openflow通信中断，可能同时要执行很多的链路判断，这些情况都可以通过采用场景一或者场景二的多重叠加来实现，都属于本发明介绍方法的使用范围。

另外，场景一和场景二描述的方法，不局限于特定的链路保活方式，背景技术中介绍的BFD链路保活和GTP链路保活是两种推荐的使用场景，其他类似于这两种链路保活机制的场景也可以使用，在此不做限制。

综上可知，通过本发明实施例的实施，至少存在以下有益效果：

本发明实施例提供了一种路径调整管理方法，该方法通过在控制器检测到与数据转发设备之间的控制面开放流连接中断时，通过与该数据转发设备建立通信的数据转发设备来确定两个数据转发设备之后转发面数据转发链路的实际状态，进而判断是否需要调整，避免了无疑义的调整，解决了现有控制器误判交换机故障导致无意义路径调整的问题。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上仅是本发明的具体实施方式而已，并非对本发明做任何形式上的限制，凡是依据本发明的技术实质对以上实施方式所做的任意简单修改、等同变化、结合或修饰，均仍属于本发明技术方案的保护范围。

Claims (11)

1.一种路径调整管理方法，包括：

检测与数据转发设备的控制面开放流连接状态；

在检测到与第一数据转发设备的控制面开放流连接中断时，获取与所述第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；

根据所述转发面数据转发链路状态，管理经过所述第一数据转发设备的通信路径的路径调整。

2.如权利要求1所述的路径调整管理方法，其特征在于，在获取所述第二数据转发设备的转发面数据转发链路状态之前，还包括：

检测与所述第二数据转发设备的控制面开放流连接状态；

若检测到与所述第二数据转发设备的控制面开放流连接中断，不调整经过所述第一数据转发设备的通信路径。

3.如权利要求1所述的路径调整管理方法，其特征在于，所述获取所述转发面数据转发链路状态包括：

向所述第二数据转发设备发送查询消息，所述查询消息用于查询所述第二数据转发设备维护的第一数据转发设备与第二数据转发设备之间转发面数据转发链路的转发面数据转发链路状态；

接收所述第二数据转发设备返回的转发面数据转发链路状态。

4.如权利要求3所述的路径调整管理方法，其特征在于，所述根据所述转发面数据转发链路状态，管理经过所述第一数据转发设备的通信路径的路径调整包括：

当所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链时，调整经过所述第一数据转发设备的通信路径；

当所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常时，不调整经过所述第一数据转发设备的通信路径。

5.如权利要求1至4任一项所述的路径调整管理方法，其特征在于，所述获取所述转发面数据转发链路状态包括：

检测在预设时长内，是否监听到所述第二数据转发设备上报的状态上报事件；

若监听到所述状态上报事件为断链，则判定所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链，调整经过所述第一数据转发设备的通信路径；

若没有监听到所述状态上报事件或者所述状态上报文事件为定期保活事件，则判定所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常，不调整经过所述第一数据转发设备的通信路径。

6.一种路径调整管理装置，包括：链路保活模块及路径调整模块，其中，

所述链路保活模块用于检测与数据转发设备的控制面开放流连接状态；在检测到与第一数据转发设备的控制面开放流连接中断时，触发所述路径调整模块；

所述路径调整模块用于获取与所述第一数据转发设备建立转发面数据转发链路的第二数据转发设备的转发面数据转发链路状态；根据所述转发面数据转发链路状态，管理经过所述第一数据转发设备的通信路径的路径调整。

7.如权利要求6所述的路径调整管理装置，其特征在于，所述路径调整模块在获取所述第二数据转发设备的转发面数据转发链路状态之前，还用于检测与所述第二数据转发设备的控制面开放流连接状态，若检测到与所述第二数据转发设备的控制面开放流连接中断，不调整经过所述第一数据转发设备的通信路径。

8.如权利要求6所述的路径调整管理装置，其特征在于，所述路径调整模块用于向所述第二数据转发设备发送查询消息，所述查询消息用于查询所述第二数据转发设备维护的第一数据转发设备与第二数据转发设备之间转发面数据转发链路的转发面数据转发链路状态；接收所述第二数据转发设备返回的转发面数据转发链路状态。

9.如权利要求8所述的路径调整管理装置，其特征在于，所述路径调整模块用于当所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链时，调整经过所述第一数据转发设备的通信路径；当所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常时，不调整经过所述第一数据转发设备的通信路径。

10.如权利要求6至9任一项所述的路径调整管理装置，其特征在于，所述路径调整模块用于检测在预设时长内，是否监听到所述第二数据转发设备上报的状态上报事件；若监听到所述状态上报事件为断链，则判定所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路断链，调整经过所述第一数据转发设备的通信路径；若没有监听到所述状态上报事件或者所述状态上报文事件为定期保活事件，则判定所述转发面数据转发链路状态为第一数据转发设备与第二数据转发设备之间转发面数据转发链路正常，不调整经过所述第一数据转发设备的通信路径。

11.一种通信系统，包括：控制器以及与所述控制器连接的多个交换机，其中，所述控制器设置有如权利要求6至10任一项所述的路径调整管理装置，所述交换机作为数据转发设备，在所述控制器的控制下进行数据转发。