一种设备状态切换的方法、设备及系统与流程

本发明涉及通信技术领域，特别涉及一种设备状态切换的方法、设备及系统。

背景技术：

为了防止因默认网关故障导致的通信中断，在TCP(Transmission Control Protocol，传输控制协议)/IP(Internet Protocol，互联网协议)网络中可以采用VRRP(Virtual Router Redundancy Protocol，虚拟路由器冗余协议)。VRRP是一种容错协议，当局域网中有两台或两台以上的路由设备时，可以将这些路由设备根据VRRP协议组成一台虚拟路由设备，将这台虚拟路由设备作为局域网内终端设备的默认网关，并为该虚拟路由设备提供唯一固定的IP地址和硬件地址。

组成虚拟路由设备的这些路由设备中只有一台作为主控路由设备(简称主设备)代表虚拟路由设备进行包的发送，其他的设备为备份路由设备(简称备设备)。备设备随时监测主设备的状态，并根据需要从备状态切换到主状态。当主设备正常工作时，会发送心跳报文，以通知组内的备设备此时主设备处于正常工作状态。如果备设备长时间没有接收到来自主设备的心跳报文，则将自己从备状态切换至主状态。当组内有多台备设备时，为了避免产生多个主设备，这时每个备设备比较接收到的心跳报文中的优先级和自己的优先级，将优先级最高的路由设备选成新的主设备。

如图1所示为采用上述VRRP进行组网的路由示意图。在同一个局域网内，终端设备1和终端设备2通过交换机与路由设备1和路由设备2连接，路由设备1和路由设备2又分别通过汇聚设备1和汇聚设备2与外部网络连接。局域 网中的路由设备1和路由设备2运行VRRP，组成虚拟路由设备作为局域网终端设备的默认网关，运行VRRP的接口称为VRRP接口，运行VRRP协议的路由设备可以称为VRRP路由设备。因此，路由设备1，称为VRRP路由设备1，为主设备，该路由设备的VRRP接口为图1中的VRRP接口1。路由设备2，称为VRRP路由设备2，为备设备，该路由设备的VRRP接口为图1中的VRRP接口2。外部网络区域运行动态路由协议实现路由交互，外部网络汇聚设备和局域网内虚拟路由设备路由交互采用静态路由协议。

目前，主设备和备设备之间的状态切换是依赖心跳触发的。为了准确进行主备设备之间的状态切换，衍生出与VRRP技术联动的BFD(Bidirectional Forwarding Detection，双向转发检测)/OAM(Operation Administration and Maintenance，网络管理功能)等技术，这种联动技术的主要思路为：如果备设备在BFD报文的检测周期内收到主设备发送的一个BFD报文，并且在心跳报文的检测周期内也能收到主设备发送的一个心跳报文，那么业务流量继续通过主设备转发，否则业务流量通过备设备转发。

但是，针对丢包频率达不到完全丢弃掉BFD报文和心跳报文的这种场景，VRRP技术联动BFD/OAM技术也不能解决上述问题。例如：设备A为主设备、设备B为备设备：由于设备B在BFD报文的检测周期内收到设备A发送的一个BFD报文，并且在心跳报文的检测周期内也能收到设备A发送的一个心跳报文，那么业务流量就会继续通过设备A转发，如果设备A存在丢包的情况，但是设备A的丢包频率恰好可以使设备B在BFD报文的检测周期内收到设备A发送的一个BFD报文，并且在心跳报文的检测周期内也能收到设备A发送的一个心跳报文，则业务流量继续走设备A转发，在这种情况下，由于无法准确进行主备设备之间的状态切换，导致业务流量受损。

又例如：设备A为主设备、设备B为备设备，设备B可以确定无法正常接收到心跳报文，但是无法确定是由于自身发生问题而导致无法正常接收到心跳报文，因此，可能认为由于设备A发生问题而导致无法正常接收到心跳报文，进 而设备B从备状态切换至主状态，并触发设备A从主状态切换至备状态，业务流量从设备B转发，导致业务流量受损。

综上所述，目前设备状态切换的方法无法准确切换、存在业务流量受损的缺陷。

技术实现要素：

本发明实施例提供一种设备状态切换的方法、设备及系统，用以解决现有技术中存在的切换准确度较低、业务流量受损的缺陷。

本发明实施例提供的具体技术方案如下：

第一方面，提供一种设备状态切换的方法，包括：

第一设备确定满足状态切换条件；

所述第一设备在确定满足状态切换条件之后，向第二设备发送第一通告报文，所述第一通告报文用于触发所述第二设备切换至主状态；

所述第一设备接收所述第二设备发送的第一心跳报文，所述第一心跳报文用于通知所述第一设备所述第二设备处于主状态；

所述第一设备在接收到所述第一心跳报文之后，判断所述第一设备是否处于主状态，若是，切换为备状态，否则，不执行任何操作。

结合第一方面，在第一种可能的实现方式中，所述状态切换条件包括承载虚拟路由器冗余协议VRRP的接口处于关闭状态、发送原始心跳报文的接口处于关闭状态、原始心跳报文出接口链路上循环冗余校验CRC错包大于阈值，及资源消耗超过预设值中的至少一种。

结合第一方面，或者第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一通告报文携带所述第一设备发生故障的故障类型。

结合第一方面，或者第一方面的第一种至第二种可能的实现方式，在第三种可能的实现方式中，所述第一设备向所述第二设备发送第一通告报文之前，还包括：

所述第一设备将优先级从第一优先级降低至第二优先级；

所述第一设备向所述第二设备发送第一通告报文，包括：

所述第一设备向所述第二设备发送携带所述第二优先级的第一通告报文。

结合第一方面，或者第一方面的第一种至第三种可能的实现方式，在第四种可能的实现方式中，所述第一设备从主状态切换至备状态时，所述第一设备切换至备状态之后，还包括:

所述第一设备确定不满足所述状态切换条件，向所述第二设备发送第二通告报文，所述第二通告报文用于触发所述第二设备从主状态切换至备状态；

所述第一设备在预设时长内接收不到所述第一心跳报文时，从备状态切换至主状态；

所述第一设备发送第二心跳报文，所述第二心跳报文用于通知所述第二设备所述第一设备处于主状态。

结合第一方面，或者第一方面的第一种至第三种可能的实现方式，在第五种可能的实现方式中，所述第一设备切换至备状态之后，还包括:

所述第一设备确定继续满足所述状态切换条件时，向所述第二设备发送第三通告报文，所述第三通告报文用于通知所述第二设备所述第一设备继续满足所述状态切换条件。

结合第一方面，或者第一方面的第一种至第五种可能的实现方式，在第六种可能的实现方式中，所述第一通告报文为互联网协议IP报文，所述第一心跳报文为IP报文。

结合第一方面，或者第一方面的第一种至第六种可能的实现方式，在第七种可能的实现方式中，所述第一设备向第二设备发送第一通告报文，包括：

所述第一设备在中继链路上，向所述第二设备发送所述第一通告报文；或者

所述第一设备在所述第一设备和所述第二设备的流量工程TE隧道上，向所述第二设备发送所述第一通告报文。

结合第一方面，或者第一方面的第一种至第七种可能的实现方式，在第八种可能的实现方式中，所述第一设备接收所述第二设备发送的第一心跳报文，包括：

所述第一设备在中继链路上，接收所述第二设备发送的第一心跳报文；或者

所述第一设备在所述第一设备和所述第二设备的TE隧道上，接收所述第二设备发送的第一心跳报文。

第二方面，提供一种设备状态切换的方法，包括：

第二设备接收第一设备发送的第一通告报文，所述第一通告报文用于触发所述第二设备切换至主状态；

所述第二设备判断所述第二设备是否处于主状态，若是，所述第二设备直接向所述第一设备发送所述第一心跳报文，所述第一心跳报文用于通知所述第一设备所述第二设备处于主状态；否则，所述第二设备确定所述第二设备处于备状态或者处于初始状态且承载VRRP的接口处于开启状态时，根据所述第一通告报文切换至主状态，并向所述第一设备发送所述第一心跳报文；或者，所述第二设备确定所述第二设备处于初始状态且承载VRRP的接口处于关闭状态时，不执行任何操作。

结合第二方面，在第一种可能的实现方式中，所述第一通告报文携带所述第一设备发生故障的故障类型。

结合第二方面，或者第二方面的第一种可能的实现方式，在第二种可能的实现方式中，第二设备接收第一设备发送的第一通告报文，包括：

所述第二设备接收所述第一设备发送的携带第二优先级的第一通告报文，所述第二优先级为所述第一设备从第一优先级降低后的优先级；

所述第二设备根据所述第一通告报文切换至主状态之前，还包括：

所述第二设备确定所述第二优先级低于所述第二设备当前的优先级。

结合第二方面，或者第二方面的第一种至第二种可能的实现方式，在第三 种可能的实现方式中，所述第二设备根据所述第一通告报文切换至主状态之后，还包括：

所述第二设备接收所述第一设备发送的第二通告报文；

所述第二设备根据所述第二通告报文从主状态切换至备状态，并停止发送所述第一心跳报文。

结合第二方面，或者第二方面的第一种至第三种可能的实现方式，在第四种可能的实现方式中，所述第二设备根据所述第一通告报文切换至主状态之后，还包括：

所述第二设备接收所述第一设备发送的第三通告报文，并根据所述第三通告报文确定所述第一设备继续满足所述状态切换条件；

所述第二设备在接收到所述第三通告报文之后，禁止触发所述第一设备切换至主状态。

结合第二方面，或者第二方面的第一种至第三种可能的实现方式，在第五种可能的实现方式中，所述第一通告报文为互联网协议IP报文，所述第一心跳报文为IP报文。

结合第二方面，或者第二方面的第一种至第五种可能的实现方式，在第六种可能的实现方式中，所述第二设备接收第一设备发送的第一通告报文，包括：

所述第二设备在中继链路上，接收所述第一设备发送的所述第一通告报文；或者

所述第二设备在所述第一设备和所述第二设备的流量工程TE隧道上，接收所述第一设备发送的所述第一通告报文。

结合第二方面，或者第二方面的第一种至第六种可能的实现方式，在第七种可能的实现方式中，所述第二设备向所述第一设备发送所述第一心跳报文，包括：

所述第二设备在中继链路上，向所述第一设备发送第一心跳报文；或者

所述第二设备在所述第一设备和所述第二设备的TE隧道上，向所述第一 设备发送第一心跳报文。

第三方面，提供一种设备状态切换的装置，包括：

处理单元，确定满足状态切换条件；

发送单元，用于在所述处理单元确定满足状态切换条件之后，向第二设备发送第一通告报文，所述第一通告报文用于触发所述第二设备切换至主状态；

接收单元，用于接收所述第二设备发送的第一心跳报文，所述第一心跳报文用于通知所述第一设备所述第二设备处于主状态；

所述处理单元还用于，在所述接收单元接收到所述第一心跳报文之后，判断所述第一设备是否处于主状态，若是，切换为备状态，否则，不执行任何操作。

结合第三方面，在第一种可能的实现方式中，所述状态切换条件包括承载虚拟路由器冗余协议VRRP的接口处于关闭状态、发送原始心跳报文的接口处于关闭状态、原始心跳报文出接口链路上循环冗余校验CRC错包大于阈值，及资源消耗超过预设值中的至少一种。

结合第三方面，或者第三方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一通告报文携带所述第一设备发生故障的故障类型。

结合第三方面，或者第三方面的第一种至第二种可能的实现方式，在第三种可能的实现方式中，所述处理单元还用于，将优先级从第一优先级降低至第二优先级；

所述发送单元在向所述第二设备发送第一通告报文时，具体为：

向所述第二设备发送携带所述第二优先级的第一通告报文。

结合第三方面，或者第三方面的第一种至第三种可能的实现方式，在第四种可能的实现方式中，所述发送单元还用于，在所述处理单元确定不满足所述状态切换条件，向所述第二设备发送第二通告报文，所述第二通告报文用于触发所述第二设备从主状态切换至备状态；

所述处理单元还用于，在所述接收单元在预设时长内接收不到所述第一心 跳报文时，从备状态切换至主状态；

所述发送单元还用于，发送第二心跳报文，所述第二心跳报文用于通知所述第二设备所述第一设备处于主状态。

结合第三方面，或者第三方面的第一种至第三种可能的实现方式，在第五种可能的实现方式中，所述发送单元还用于，在所述处理单元确定继续满足所述状态切换条件时，向所述第二设备发送第三通告报文，所述第三通告报文用于通知所述第二设备所述第一设备继续满足所述状态切换条件。

结合第三方面，或者第三方面的第一种至第五种可能的实现方式，在第六种可能的实现方式中，所述第一通告报文为互联网协议IP报文，所述第一心跳报文为IP报文。

结合第三方面，或者第三方面的第一种至第六种可能的实现方式，在第七种可能的实现方式中，所述发送单元向第二设备发送第一通告报文时，具体为：

在中继链路上，向所述第二设备发送所述第一通告报文；或者

在所述第一设备和所述第二设备的流量工程TE隧道上，向所述第二设备发送所述第一通告报文。

结合第三方面，或者第三方面的第一种至第七种可能的实现方式，在第八种可能的实现方式中，所述接收单元接收所述第二设备发送的第一心跳报文时，具体为：

在中继链路上，接收所述第二设备发送的第一心跳报文；或者

在所述第一设备和所述第二设备的TE隧道上，接收所述第二设备发送的第一心跳报文。

第四方面，提供一种设备状态切换的装置，包括：

接收单元，用于接收第一设备发送的第一通告报文，所述第一通告报文用于触发所述第二设备切换至主状态；

处理单元，用于判断所述第二设备是否处于主状态；

发送单元，用于在所述处理单元确定所述第二设备处于主状态时，直接向 所述第一设备发送所述第一心跳报文，所述第一心跳报文用于通知所述第一设备所述第二设备处于主状态；

所述发送单元还用于，用于在所述处理单元确定所述第二设备处于备状态或者处于初始状态且承载VRRP的接口处于开启状态时，根据所述第一通告报文切换至主状态，并向所述第一设备发送所述第一心跳报文；或者，在所述处理单元确定所述第二设备处于初始状态且承载VRRP的接口处于关闭状态时，不执行任何操作。

结合第四方面，在第一种可能的实现方式中，所述第一通告报文携带所述第一设备发生故障的故障类型。

结合第四方面，或者第四方面的第一种可能的实现方式，在第二种可能的实现方式中，所述接收单元接收第一设备发送的第一通告报文时，具体为：

接收所述第一设备发送的携带第二优先级的第一通告报文，所述第二优先级为所述第一设备从第一优先级降低后的优先级；

所述处理单元还用于，确定所述第二优先级低于所述第二设备当前的优先级。

结合第四方面，或者第四方面的第一种至第二种可能的实现方式，在第三种可能的实现方式中，所述接收单元还用于，接收所述第一设备发送的第二通告报文；

所述处理单元还用于，根据所述第二通告报文从主状态切换至备状态，并停止发送所述第一心跳报文。

结合第四方面，或者第四方面的第一种至第三种可能的实现方式，在第四种可能的实现方式中，所述接收单元还用于，接收所述第一设备发送的第三通告报文；

所述处理单元还用于，根据所述接收单元接收到的所述第三通告报文确定所述第一设备继续满足所述状态切换条件；

所述处理单元还用于，在接收到所述第三通告报文之后，禁止触发所述第 一设备切换至主状态。

结合第四方面，或者第四方面的第一种至第三种可能的实现方式，在第五种可能的实现方式中，所述第一通告报文为互联网协议IP报文，所述第一心跳报文为IP报文。

结合第四方面，或者第四方面的第一种至第五种可能的实现方式，在第六种可能的实现方式中，所述接收单元接收第一设备发送的第一通告报文时，具体为：

在中继链路上，接收所述第一设备发送的所述第一通告报文；或者

在所述第一设备和所述第二设备的流量工程TE隧道上，接收所述第一设备发送的所述第一通告报文。

结合第四方面，或者第四方面的第一种至第六种可能的实现方式，在第七种可能的实现方式中，所述发送单元向所述第一设备发送所述第一心跳报文时，具体为：

在中继链路上，向所述第一设备发送第一心跳报文；或者

在所述第一设备和所述第二设备的TE隧道上，向所述第一设备发送第一心跳报文。

第五方面，提供一种设备状态切换的系统，包括如第三方面，或者第三方面的第一种至第八种可能的实现方式中的任意一所述的第一设备和如第四方面，或者第四方面的第一种至第七种可能的实现方式中的任意一所述的第二设备。

本发明公开了一种设备状态切换的方法、设备及系统，在该方案中，第一设备在确定满足状态切换条件的时候，向第二设备发送第一通告报文，触发第二设备切换至主状态，不再是由第二设备通过检测现有的原始心跳报文来确定是否要切换至主状态，第一设备接收第二设备发送的第一心跳报文，确定第二设备处于主状态，进而可以使第二设备稳定处于主状态，因此，提高了状态切换的准确度，避免业务流量受损。

附图说明

图1为现有技术中采用上述VRRP进行组网的路由示意图；

图2为本发明实施例中设备状态切换的一种流程图；

图3为本发明实施例中设备状态切换的另一种流程图；

图4为本发明实施例中设备状态切换的实施例；

图5A为本发明实施例中第一设备的一种示意图；

图5B为本发明实施例中第一设备的另一种示意图；

图6A为本发明实施例中第二设备的一种示意图；

图6B为本发明实施例中第二设备的另一种示意图；

图7为本发明实施例中设备状态切换系统的示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

下面对本发明实施例涉及到的初始状态进行简单说明，以便于理解。

设备中承载VRRP的接口由于传输故障，会发生闪断(闪断是指承载VRRP的接口关闭之后，又快速开启)，一般为了防止链路震荡造成承载VRRP的接口频繁切换状态，需要配置恢复延迟时间，即承载VRRP的接口开启时，不能立即工作，即不处理心跳等事件，等配置的恢复延迟时间截止时，才可以处理 心跳等事件，其中，将设备在承载VRRP的接口开启至恢复延时时间截止的时间段所处的状态称为初始状态。

例如，恢复延迟时间的时长设置为60ms，则承载VRRP的接口开启时，设备不能立即处理工作，而是等60ms后设备才可以工作，设备在这60ms所处的状态称为初始状态。

下面结合说明书附图对本发明优选的实施方式进行详细说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

下面结合附图对本发明实施例进行详细说明。

参阅图2所示，本发明实施例中，设备之间状态切换的一种流程如下：

步骤200：第一设备确定满足状态切换条件；

步骤210：第一设备在确定满足状态切换条件之后，向第二设备发送第一通告报文，第一通告报文用于触发第二设备切换至主状态；

步骤220：第一设备接收第二设备发送的第一心跳报文，第一心跳报文用于通知第一设备第二设备处于主状态；

步骤230：第一设备在接收到第一心跳报文之后，判断第一设备是否处于主状态，若是，切换为备状态，否则，不执行任何操作。

需要说明的是，在步骤230中，当第一设备不是处于主状态时，可能处于其他状态，例如，可以处于备状态，或者处于初始状态，当然，其他状态并不限定在备状态和初始状态两种状态，随着技术的发展，还可能出现其他状态，在此不再进行详述。

本发明实施例中所提及的原始心跳报文指的是现有技术中所说的心跳报文，且原始心跳报文可以通过二层转发，本发明实施例中所提及的第一心跳报文和第二心跳报文都是本发明实施例中新提及的心跳报文，第一心跳报文和第二心跳报文可以通过三层转发，且第二心跳报文和第三心跳报文的优先级都高于原始心跳报文，即设备在同时接收到原始心跳报文和第一心跳报文的时候， 是按照第一心跳报文来操作，设备在同时接收到原始心跳报文和第二心跳报文的时候，是按照第二心跳报文来操作。

本发明实施例中，状态切换条件可以包括承载VRRP的接口处于关闭状态、发送原始心跳报文的接口处于关闭状态、原始心跳报文出接口链路上CRC(Cyclic Redundancy Check，循环冗余校验)错包大于阈值，及资源消耗超过预设值中的至少一种状况，上述只是状态切换条件的具体的例子，但是并不限定于此，还可以为用户设定的其他条件，在此不再进行一一详述。

其中，资源消耗超过预设值可以指内存资源、CPU(Central Processing Unit，中央处理单元)资源、业务资源中的至少一种资源的消耗超过预设值。

为了保证第一链路故障恢复后，第二设备在从主状态切换至备状态时的准确度，本发明实施例中，第一通告报文可以携带第一设备发生故障的故障类型。

这样，当第一设备发生的故障恢复后，第一设备将恢复故障的故障类型通知第二设备，第二设备确定发生故障的故障类型跟恢复故障的故障类型相同后，第二设备可以从主状态切换至备状态。

需要说明的是，第一设备从主状态切换至备状态之前，继续收发业务报文，并仍然发送现有技术中的原始心跳报文。如果第二设备既可以接收到第一通告报文，也可以接收到现有的原始心跳报文的话，仍然以第一通告报文所指示的信息为准。也就是说，第二设备在接收到第一通告报文和原始心跳报文的情况下，第二设备仍然要按照接收到第一通告报文的后续过程进行操作。

在实际应用中，设备切换至主状态时，要保证自身的优先级要高于其他设备的优先级，因此，本发明实施例中，第一设备向第二设备发送第一通告报文之前，还包括如下操作：

第一设备将优先级从第一优先级降低至第二优先级；

此时，第一设备向第二设备发送第一通告报文时，可选的，可以采用如下方式：

第一设备向第二设备发送携带第二优先级的第一通告报文。

上述描述的是，通过第一设备降低优先级来达到第二设备的优先级高于第一设备的优先级的效果，当然，在实际应用中，也可以通过第二设备提高优先级的方式来达到第二设备的优先级高于第一设备的优先级的效果，或者，也可以通过上述两种方式的组合来达到第二设备的优先级高于第一设备的优先级的效果，即通过第一设备降低优先级、第二设备提高优先级来达到第二设备的优先级高于第一设备的优先级的效果。

需要说明的是，如果仅仅通过第一设备降低优先级来达到第二设备的优先级高于第一设备的优先级的效果的话，第一设备降低后的第二优先级要低于第二设备的初始优先级。

同理，如果仅仅通过第二设备提高优先级来达到第二设备的优先级高于第一设备的优先级的效果的话，第二设备提高后的优先级要高于第一设备的第一优先级。

同理，如果通过第一设备降低优先级、第二设备提高优先级来达到第二设备的优先级高于第一设备的优先级的效果的话，第二设备提高后的优先级要高于第一设备降低后的第二优先级。

需要说明的是，上述第一设备降低优先级，或者第二设备提高优先级描述的是第一设备为主状态的场景，如果第一设备为备状态或者初始状态的话，第一设备不降低优先级，直接将第一设备当前优先级，即第一优先级携带在第一通告报文中，只不过，当第一设备为初始状态的话，第一优先级为0，当第一设备为备状态的话，第一优先级为与0不同的一个值。

上述描述的是，第一设备从主状态切换至备状态的情况，在实际应用中，第一设备从主状态切换至备状态之后，可能不满足状态切换条件，此时，第一设备可以从备状态切换至主状态，因此，本发明实施例中，第一设备从主状态切换至备状态时，第一设备切换至备状态之后，还包括如下操作:

第一设备确定不满足状态切换条件，向第二设备发送第二通告报文，第二通告报文用于触发第二设备从主状态切换至备状态；

第一设备在预设时长内接收不到第一心跳报文时，从备状态切换至主状态；

第一设备发送第二心跳报文，第二心跳报文用于通知第二设备第一设备处于主状态。

本发明实施例中，不满足状态切换条件可以包括承载VRRP的接口处于开启状态、发送原始心跳报文的接口处于开启状态、原始心跳报文出接口链路上CRC错包小于或者等于阈值，及资源消耗未超过预设值中的至少一种，上述只是状态切换条件的具体的例子，但是并不限定于此，还可以为用户设定的其他条件，在此不再进行一一详述。

例如，第一设备从主状态降到备状态，第二设备从备状态切换到主状态后，第一设备可能检测到自身链路恢复，此时，第一设备向第二设备发送第二通告报文，触发第二设备从主状态切换到备状态，第一设备从备状态切换至主状态，其中，第一设备确定不满足状态切换条件时，可以确定检测到自身链路恢复。其中，资源消耗未超过预设值可以指内存资源、CPU资源、业务资源中的至少一种资源的消耗未超过预设值。

需要说明的是，第一设备和第二设备中设置的满足状态切换条件是相同的，同理，第一设备和第二设备中设置的不满足状态切换条件也是相同的，也就是说，触发第一设备从主状态切换至备状态的条件，与触发第二设备从主状态切换至备状态的条件是相同的，触发第一设备从备状态切换至主状态的条件，与触发第二设备从备状态切换至主状态的条件是相同的，但是，具体通过什么方式在第一设备和第二设备中设置满足状态切换条件、不满足状态切换条件，在此不做具体限定，例如，可以采用控制设备配置的方式分别在第一设备和第二设备上部署，又例如，可以通过人工的方式分别在第一设备和第二设备上部署。

本发明实例中，第一设备从主状态切换至备状态之后，如果第一设备确定继续满足状态切换条件，则第一设备还要将第一设备继续满足状态切换条件的情况通知第二设备，这样，避免第二设备在第一设备不适合从备状态切换至主状态的情况下，触发第一设备从备状态切换至主状态，因此，本发明实施例中， 第一设备切换至备状态之后，还包括如下操作:

第一设备确定继续满足状态切换条件时，向第二设备发送第三通告报文，第三通告报文用于通知第二设备第一设备继续满足状态切换条件。

这样，即使第二设备想要从主状态切换至备状态，由于第一设备不适合从备状态切换至主状态，因此，第二设备也不会通知第一设备进行状态切换，触发第一设备从备状态切换至主状态。

本发明实施例中，可选的，第一设备确定继续满足状态切换条件时，第一设备可以周期性的向第二设备发送第三通告报文，直至第一设备不满足状态切换条件。

例如，第一设备从主状态降到备状态，第二设备从备状态切换到主状态后，第一设备可能检测到自身链路仍然处于故障状态，此时，第一设备向第二设备发送第三通告报文，其中，第一设备确定满足状态切换条件时，可以确定检测到自身链路仍然处于故障状态。

本发明实施例中，为了降低第一通告报文被丢弃的可能性，第一通告报文是通过三层转发来发现的，可选的，第一通告报文为IP报文。同理，第二通告报文、第三通告报文、第一心跳报文和第二心跳报文也可以为IP报文。

本发明实施例中，可选的，第一设备向第二设备发送第一通告报文时，可以采用如下方式：

第一设备在中继链路(TrunkLink)上，向第二设备发送第一通告报文；或者

第一设备在第一设备和第二设备的TE(Traffic Engineering，流量工程)隧道上，向第二设备发送第一通告报文。

同理，第一设备向第二设备发送第二通告报文时，可选的，可以采用如下方式：

第一设备在中继链路上，向第二设备发送第二通告报文；或者

第一设备在第一设备和第二设备的TE隧道上，向第二设备发送第二通告 报文。

同理，第一设备向第二设备发送第三通告报文时，可选的，可以采用如下方式：

第一设备在中继链路上，向第二设备发送第三通告报文；或者

第一设备在第一设备和第二设备的TE隧道上，向第二设备发送第三通告报文。

上述描述的是通告报文可以在中继链路上，或者在第一设备和第二设备的TE隧道上发送，本发明实施例中，第一心跳报文或者第二心跳报文也可以在中继链路上，或者在第一设备和第二设备的TE隧道上发送或接收，具体过程如下：

第一设备在中继链路上，接收第二设备发送的第一心跳报文；或者

第一设备在第一设备和第二设备的TE隧道上，接收第二设备发送的第一心跳报文。

本发明实施例中，为了提高第一通告报文的安全性，可以对第一通告报文进行加密处理。同理，第二通告报文和第三通告报文也可以进行加密处理。

本发明实施例中，为了保证第一通告报文能够达到第二设备，第一通告报文需要承载在稳定的链路上。

本发明实施例中，第一设备在执行步骤200-230的这个方法的过程中，也可以向第二设备发送现有技术中的原始心跳报文，但是，第一通告报文的优先级高于原始心跳报文的优先级，也就是说，第一设备既发送第一通告报文，也发送原始心跳报文，这样，第二设备既可以接收到第一通告报文，也可以接收到原始心跳报文，但是，以第一通告报文所指示的信息为准，也就是说，如果第二设备既可以接收到第一通告报文，也可以接收到原始心跳报文的话，第二设备仍然要从备状态切换至主状态。

步骤200所说的是第一设备确定满足状态切换条件的时候，第一设备要发送第一通告报文，如果第一设备确定不满足状态切换条件的话，第一设备就按 照现有的技术发送原始心跳报文即可。

本发明实施例中，原始心跳报文跟第一心跳报文和第二心跳报文的区别是，原始心跳报文通过二层转发，而第一心跳报文和第二心跳报文可以通过三层转发。

可选的，第一设备发生的故障恢复后，并且经历了预定时长后，第一设备停止发送第一心跳报文和第二心跳报文，发送原始心跳报文。也就是说，当第一设备故障恢复，并且稳定运行预定时长后，停止本发明实施例中提及的心跳报文机制，采用现有技术中的心跳报文机制。这样做的有益效果是，节省网络链路带宽的占用。当第一设备又检测到发生故障时，可以再次启动本发明所提及的心跳报文机制，即发送第一心跳报文和/或第二心跳报文。

本发明实施例中，第一设备在确定满足状态切换条件的时候，向第二设备发送第一通告报文，触发第二设备切换至主状态，不再是由第二设备通过检测原始心跳报文来确定是否要切换至主状态，并接收第二设备发送的第一心跳报文，确定第二设备处于主状态，可以使第二设备稳定处于主状态，因此，提高了状态切换的准确度，避免业务流量受损。

参阅图3所示，本发明实施例中，设备状态切换的另一种流程如下：

步骤300：第二设备接收第一设备发送的第一通告报文，第一通告报文用于触发第二设备切换至主状态；

步骤310：第二设备判断第二设备是否处于主状态，若是，第二设备直接向第一设备发送第一心跳报文，第一心跳报文用于通知第一设备第二设备处于主状态；否则，执行步骤320，或者步骤330；

步骤320：第二设备确定第二设备处于备状态或者处于初始状态且承载VRRP的接口处于开启状态时，根据第一通告报文切换至主状态，并向第一设备发送第一心跳报文；

步骤330：第二设备确定第二设备处于初始状态且承载VRRP的接口处于关闭状态时，不执行任何操作。

需要说明的是，第二设备不是处于主状态时，可能处于备状态，或者处于初始状态，当然，并不限定在备状态和初始状态两种状态，随着技术的发展，还可能出现其他状态，在此不再进行详述。

本发明实施例中所提及的原始心跳报文指的是现有技术中所说的心跳报文，且原始心跳报文可以通过二层转发，本发明实施例中所提及的第一心跳报文和第二心跳报文都是本发明实施例中新提及的心跳报文，第一心跳报文和第二心跳报文可以通过三层转发，且第二心跳报文和第三心跳报文的优先级都高于原始心跳报文，即设备在同时接收到原始心跳报文和第一心跳报文的时候，是按照第一心跳报文来操作，设备在同时接收到原始心跳报文和第二心跳报文的时候，是按照第二心跳报文来操作。

为了保证第一链路故障恢复后，第二设备在从主状态切换至备状态时的准确度，本发明实施例中，第一通告报文可以携带第一设备发生故障的故障类型。

当第一设备发生的故障恢复后，第一设备将恢复故障的故障类型发送通知第二设备，第二设备确定发生故障的故障类型跟恢复的故障类型相同后，第二设备可以从主状态切换至备状态。

需要说明的是，本发明实施例中，如果第二设备既可以接收到第一通告报文，也可以接收到现有技术中的原始心跳报文的话，在这种情况下，以第一通告报文所指示的信息为准。也就是说，第二设备在接收到第一通告报文和原始心跳报文的情况下，第二设备执行步骤310和320，或者步骤310和330。

在实际应用中，设备切换至主状态时，要保证自身的优先级要高于其他设备的优先级，因此，本发明实施例中，第二设备接收第一设备发送的第一通告报文时，可以采用如下方式：

第二设备接收第一设备发送的携带第二优先级的第一通告报文，第二优先级为第一设备从第一优先级降低后的优先级；

进一步的，第二设备根据第一通告报文切换至主状态之前，还包括如下操作：

第二设备确定第二优先级低于第二设备当前的优先级。

上述描述的是，通过第一设备降低优先级来达到第二设备的优先级高于第一设备的优先级的效果，当然，在实际应用中，也可以通过第二设备提高优先级的方式来达到第二设备的优先级高于第一设备的优先级的效果，或者，也可以通过上述两种方式的组合来达到第二设备的优先级高于第一设备的优先级的效果，即通过第一设备降低优先级、第二设备提高优先级来达到第二设备的优先级高于第一设备的优先级的效果。

需要说明的是，如果仅仅通过第一设备降低优先级来达到第二设备的优先级高于第一设备的优先级的效果的话，第一设备降低后的第二优先级要低于第二设备的初始优先级。

同理，如果仅仅通过第二设备提高优先级来达到第二设备的优先级高于第一设备的优先级的效果的话，第二设备提高后的优先级要高于第一设备的第一优先级。

同理，如果通过第一设备降低优先级、第二设备提高优先级来达到第二设备的优先级高于第一设备的优先级的效果的话，第二设备提高后的优先级要高于第一设备降低后的第二优先级。

需要说明的是，上述第一设备降低优先级，或者第二设备提高优先级描述的是第一设备为主状态的场景，如果第一设备为备状态或者初始状态的话，第一设备不降低优先级，直接将第一设备当前优先级，即第一优先级携带在第一通告报文中，只不过，当第一设备为初始状态的话，第一优先级为0，当第一设备为备状态的话，第一优先级为与0不同的一个值。

上述描述的是，第一设备从主状态切换至备状态的情况，在实际应用中，第一设备从主状态切换至备状态之后，可能不满足状态切换条件，此时，第一设备可以从备状态切换至主状态，，因此，本发明实施例中，第二设备根据第一通告报文切换至主状态之后，还包括如下操作：

第二设备接收第一设备发送的第二通告报文；

第二设备根据第二通告报文从主状态切换至备状态，并停止发送第一心跳报文。

进一步的，为了降低丢包的概率，保证在第一设备处于主状态时，第二设备才从主状态切换至备状态，本发明实施例中，进一步的，第二设备接收第一设备发送的第二通告报文之后，第二设备根据第二通告报文从主状态切换至备状态，并停止发送第一心跳报文之前，还包括：

第二设备接收第一设备发送的第二心跳报文，第二心跳报文用于通知第二设备第一设备处于主状态；

第二设备根据第二通告报文和第二心跳报文从主状态切换至备状态，并停止发送第一心跳报文。

例如，第一设备从主状态降到备状态，第二设备从备状态切换到主状态后，第一设备可能检测到自身链路恢复，此时，第一设备向第二设备发送第二通告报文，触发第二设备从主状态切换到备状态，第一设备从备状态切换至主状态，其中，第一设备确定不满足状态切换条件时，可以确定检测到自身链路恢复。

本发明实例中，第一设备从主状态切换至备状态之后，如果第一设备确定继续满足状态切换条件，则第一设备还要将第一设备继续满足状态切换条件的通知第二设备，这样，避免第二设备在第一设备不适合从备状态切换至主状态的情况下，触发第一设备从备状态切换至主状态，因此，本发明实施例中，第二设备根据第一通告报文切换至主状态之后，还包括如下操作：

第二设备接收第一设备发送的第三通告报文，并根据第三通告报文确定第一设备继续满足状态切换条件；

第二设备在接收到第三通告报文之后，禁止触发第一设备切换至主状态。

本发明实施例中，可选的，禁止触发第一设备切换至主状态。可选的，可以通过第二设备继续发送第一心跳报文来实现，因为第一设备接收到第一心跳报文的话，确定第二设备处于主状态，第一设备不会从备状态切换至主状态。

这样，即使第二设备想要从主状态切换至备状态，由于第一设备不适合从 备状态切换至主状态，因此，第二设备也不会触发第一设备从备状态切换至主状态。

本发明实施例中，可选的，第二设备周期性的接收第一设备发送的第三通告报文。

例如，第一设备从主状态降到备状态，第二设备从备状态切换到主状态后，第一设备可能检测到自身链路仍然处于故障状态，此时，第一设备向第二设备发送第三通告报文，其中，第一设备确定满足状态切换条件时，可以确定检测到自身链路仍然处于故障状态。

本发明实施例中，可选的，为了降低第一通告报文被丢弃的可能性，第一通告报文为IP报文。也就是说，第一通告报文通过三层转发实现的。同理，第二通告报文、第三通告报文、第一心跳报文和第二心跳报文也可以为IP报文。

本发明实施例中，第二设备接收第一设备发送的第一通告报文时，可选的，可以采用如下方式：

第二设备在中继链路上，接收第一设备发送的第一通告报文；或者

第二设备在第一设备和第二设备的TE隧道上，接收第一设备发送的第一通告报文。

同理，第二设备接收第一设备发送的第二通告报文时，可选的，可以采用如下方式：

第二设备在中继链路上，接收第一设备发送的第二通告报文；或者

第二设备在第一设备和第二设备的TE隧道上，接收第一设备发送的第二通告报文。

同理，第二设备接收第一设备发送的第三通告报文时，可选的，可以采用如下方式：

第二设备在中继链路上，接收第一设备发送的第三通告报文；或者

第二设备在第一设备和第二设备的TE隧道上，接收第一设备发送的第三 通告报文。

同理，本发明实施例中，第二设备向第一设备发送第一心跳报文时，也可以采用如下方式：

第二设备在中继链路上，向第一设备发送第一心跳报文；或者

第二设备在第一设备和第二设备的TE隧道上，向第一设备发送第一心跳报文。

同理，本发明实施例中，第二设备向第一设备发送第二心跳报文时，也可以采用如下方式：

第二设备在中继链路上，向第一设备发送第二心跳报文；或者

第二设备在第一设备和第二设备的TE隧道上，向第一设备发送第二心跳报文。

本发明实施例中，为了提高第一通告报文的安全性，第一通告报文可以是经过加密处理的。同理，第二通告报文和第三通告报文也可以经过加密处理。

本发明实施例中，为了保证第一通告报文能够达到第二设备，第一通告报文需要承载在稳定的链路上。

本发明实施例中，第二设备在执行步骤300-330的这个方法的过程中，也可以接收第一设备发送的原始心跳报文，但是，第一通告报文的优先级高于原始心跳报文的优先级，也就是说，第一设备既发送第一通告报文，也发送现有技术中的心跳报文，这样，第二设备既可以接收到第一通告报文，也可以接收到原始心跳报文，但是，以第一通告报文所指示的信息为准，第二设备执行步骤310和320，或者步骤310和330。

本发明实施例中，原始心跳报文跟第一心跳报文和第二心跳报文的区别是，原始心跳报文通过二层转发，而第一心跳报文和第二心跳报文可以通过三层转发。

可选的，第一设备发生的故障恢复后，并且经历了预定时长后，第一设备停止发送第一心跳报文和第二心跳报文，发送原始心跳报文。也就是说，当第 一设备故障恢复，并且稳定运行预定时长后，停止本发明实施例中提及的心跳报文机制，采用现有技术中的心跳报文机制。这样做的有益效果是，节省网络链路带宽的占用。当第一设备又检测到发生故障时，可以再次启动本发明所提及的心跳报文机制，即发送第一心跳报文和/或第二心跳报文。

本发明实施例中，第一设备在确定满足状态切换条件的时候，向第二设备发送第一通告报文，触发第二设备切换至主状态，不再是由第二设备通过检测原始心跳报文来确定是否要切换至主状态，并通过向第一设备发送第一心跳报文来维持状态的稳定性，因此，提高了状态切换的准确度，避免业务流量受损。

为了更好地理解本发明实施例，以下给出具体应用场景，针对设备状态切换过程，做出进一步详细描述，具体参阅图4所示：

步骤400：第一设备确定原始心跳报文出接口链路上的CRC错包大于阈值时，向第二设备发送第一通告报文；

在该步骤中，第一设备将优先级从第一优先级降低至第二优先级，并将第二优先级携带在第一通告报文中；

该步骤中的第一通告报文携带发生故障的故障类型。

需要说明的是，第一设备确定心跳报文出接口链路上的CRC错包大于阈值时，可以继续收发业务报文，并发送原始心跳报文。

步骤410：第二设备接收到第一通告报文，确定第二设备处于备状态或者处于初始状态且承载VRRP的接口处于开启状态时时，从备状态切换至主状态；

步骤420：第二设备将第一心跳报文发送至第一设备；

步骤430：第一设备接收到第一心跳报文后，确定处于主状态，并从主状态切换至备状态；

步骤440：第一设备确定是否继续满足状态切换条件，若是，周期性的发送第三通告报文；否则，执行步骤450：

步骤450：第一设备向第二设备发送第二通告报文；

步骤460：第二设备接收第二通告报文，从主状态切换至备状态，并停止 向第一设备发送第一心跳报文；

步骤470：第一设备在预设时长内接收不到第一心跳报文时，从备状态切换至主状态。

需要说明的是，如果第一设备的原始心跳报文出接口链路丢包严重，原始心跳报文可能发送失败，或者，如果第一设备原始心跳报文出接口链路丢包不严重，第二设备可以在3个周期内收到一个原始心跳报文。此时，即使第二设备既可以接收到第一通告报文，也可以接收到原始心跳报文，那么就以第一通告报文所指示的信息为准。不根据原始心跳报文做任何操作，即使第二设备先收到原始心跳报文，执行了一些操作后，再接收到第一通告报文，第二设备仍然要回退到根据原始心跳报文执行的操作之前，再根据第一通告报文进行操作。

参阅图5A所示，本发明实施例中，提出一种第一设备，第一备状态切换的装置包括处理单元50、发送单元51和接收单元52，其中：

处理单元50，确定满足状态切换条件；

发送单元51，用于在处理单元50确定满足状态切换条件之后，向第二设备发送第一通告报文，第一通告报文用于触发第二设备切换至主状态；

接收单元52，用于接收第二设备发送的第一心跳报文，第一心跳报文用于通知第一设备第二设备处于主状态；

处理单元50还用于，在接收单元52接收到第一心跳报文之后，判断第一设备是否处于主状态，若是，切换为备状态，否则，不执行任何操作。

本发明实施例中，可选的，状态切换条件包括承载虚拟路由器冗余协议VRRP的接口处于关闭状态、发送原始心跳报文的接口处于关闭状态、原始心跳报文出接口链路上循环冗余校验CRC错包大于阈值，及资源消耗超过预设值中的至少一种。

本发明实施例中，可选的，第一通告报文携带第一设备发生故障的故障类型。

本发明实施例中，进一步的，处理单元50还用于，将优先级从第一优先 级降低至第二优先级；

发送单元51在向第二设备发送第一通告报文时，具体为：

向第二设备发送携带第二优先级的第一通告报文。

本发明实施例中，进一步的，发送单元51还用于，在处理单元50确定不满足状态切换条件，向第二设备发送第二通告报文，第二通告报文用于触发第二设备从主状态切换至备状态；

处理单元50还用于，在接收单元52在预设时长内接收不到第一心跳报文时，从备状态切换至主状态；

发送单元51还用于，发送第二心跳报文，第二心跳报文用于通知第二设备第一设备处于主状态。

本发明实施例中，进一步的，发送单元51还用于，在处理单元50确定继续满足状态切换条件时，向第二设备发送第三通告报文，第三通告报文用于通知第二设备第一设备继续满足状态切换条件。

本发明实施例中，可选的，第一通告报文为互联网协议IP报文，第一心跳报文为IP报文。

本发明实施例中，可选的，发送单元51向第二设备发送第一通告报文时，具体为：

在中继链路上，向第二设备发送第一通告报文；或者

在第一设备和第二设备的流量工程TE隧道上，向第二设备发送第一通告报文。

本发明实施例中，可选的，接收单元52接收第二设备发送的第一心跳报文时，具体为：

在中继链路上，接收第二设备发送的第一心跳报文；或者

在第一设备和第二设备的TE隧道上，接收第二设备发送的第一心跳报文。

参阅图5B所示，本发明实施例中，提出一种第一设备的示意图，该第一设备包括处理器500、发送器510和接收器520，其中：

处理器500，确定满足状态切换条件；

发送器510，用于在处理器500确定满足状态切换条件之后，向第二设备发送第一通告报文，第一通告报文用于触发第二设备切换至主状态；

接收器520，用于接收第二设备发送的第一心跳报文，第一心跳报文用于通知第一设备第二设备处于主状态；

处理器500还用于，在接收器520接收到第一心跳报文之后，判断第一设备是否处于主状态，若是，切换为备状态，否则，不执行任何操作。

需要说明的是，处理器500还用于执行处理单元50所执行的其他操作，发送器510还用于执行发送单元51所执行的其他操作，接收器520，还用于执行接收单元52所执行的操作。

参阅图6A所示，本发明实施例中，提出一种第二设备的示意图，该第二设备包括接收单元60、处理单元61和发送单元62，其中：

接收单元60，用于接收第一设备发送的第一通告报文，第一通告报文用于触发第二设备切换至主状态；

处理单元61，用于判断第二设备是否处于主状态；

发送单元62，用于在处理单元61确定第二设备处于主状态时，直接向第一设备发送第一心跳报文，第一心跳报文用于通知第一设备第二设备处于主状态；

发送单元62还用于，用于在处理单元61确定第二设备处于备状态或者处于初始状态且承载VRRP的接口处于开启状态时，根据第一通告报文切换至主状态，并向第一设备发送第一心跳报文；或者，在处理单元61确定第二设备处于初始状态且承载VRRP的接口处于关闭状态时，不执行任何操作。

本发明实施例中，可选的，第一通告报文携带第一设备发生故障的故障类型。

本发明实施例中，可选的，接收单元60接收第一设备发送的第一通告报文时，具体为：

接收第一设备发送的携带第二优先级的第一通告报文，第二优先级为第一设备从第一优先级降低后的优先级；

处理单元61还用于，确定第二优先级低于第二设备当前的优先级。

本发明实施例中，进一步的，接收单元60还用于，接收第一设备发送的第二通告报文；

处理单元61还用于，根据第二通告报文从主状态切换至备状态，并停止发送第一心跳报文。

本发明实施例中，进一步的，接收单元60还用于，接收第一设备发送的第三通告报文；

处理单元61还用于，根据接收单元60接收到的第三通告报文确定第一设备继续满足状态切换条件；

处理单元61还用于，在接收到第三通告报文之后，禁止触发第一设备切换至主状态。

本发明实施例中，可选的，第一通告报文为IP报文，第一心跳报文为IP报文。

本发明实施例中，可选的，接收单元60接收第一设备发送的第一通告报文时，具体为：

在中继链路上，接收第一设备发送的第一通告报文；或者

在第一设备和第二设备的流量工程TE隧道上，接收第一设备发送的第一通告报文。

本发明实施例中，可选的，发送单元62向第一设备发送第一心跳报文时，具体为：

在中继链路上，向第一设备发送第一心跳报文；或者

在第一设备和第二设备的TE隧道上，向第一设备发送第一心跳报文。

参阅图6B所示，本发明实施例中，提出一种第二设备的示意图，该第二设备状态切换的装置包括接收器600、处理器610和发送器620，其中：

接收器600，用于接收第一设备发送的第一通告报文，第一通告报文用于触发第二设备切换至主状态；

处理器610，用于判断第二设备是否处于主状态；

发送器620，用于在处理器610确定第二设备处于主状态时，直接向第一设备发送第一心跳报文，第一心跳报文用于通知第一设备第二设备处于主状态；

发送器620还用于，用于在处理器610确定第二设备处于备状态或者处于初始状态且承载VRRP的接口处于开启状态时，根据第一通告报文切换至主状态，并向第一设备发送第一心跳报文；或者，在处理器610确定第二设备处于初始状态且承载VRRP的接口处于关闭状态时，不执行任何操作。

需要说明的是，接收器600还用于执行接收单元60所执行的其他操作，处理器610还用于执行处理单元61所执行的其他操作，发送器620还用于执行发送单元62所执行的操作。

参阅图7所示，本发明实施例中，提出一种设备状态切换系统，包括如图5A和图5B所示的第一设备和图6A和图6B所示的第二设备。

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

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

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

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

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。