CN105530117A - 控制通道协议状态的更新方法、装置及系统 - Google Patents

Abstract

本发明提供了一种控制通道协议状态的更新方法、装置及系统，其中，该方法包括检测到控制平面故障后，维持控制平面中控制通道的协议状态为协议UP状态；依据与重启节点的协商结果，更新与重启节点之间的控制通道的协议状态，其中，该协议状态包括协议DOWN状态或协议UP状态，通过本发明，解决相关技术中存在的控制平面发送故障后会将控制通道置为协议DOWN状态，导致数据丢失、路由震荡的问题，进而达到了减少数据丢失的效果。

Description

控制通道协议状态的更新方法、装置及系统

技术领域

本发明涉及通信领域，具体而言，涉及一种控制通道协议状态的更新方法、装置及系统。

背景技术

随着路由器、交换机、交换连接器、密集波分复用系统(DenseWavelengthDivisionMultiplexing，简称为DWDM)以及异步传输模式(AsynchronousTransferMode，简称为ATM)技术的发展，网络技术也在不断的发展，这些技术都有一个公共的控制平面，比如通用多协议标签交换协议(GeneralizedMultiprotocolLabelSwitching，简称为GMPLS)，它使用保护/恢复技术，动态的分配资源，提供网络的生存性。

在网络节点之间可能会有上千条内部连接，它们通过复用技术,每条连接又可以包含多条数据链路。为了扩展性，多条数据链路又可以聚合在一起组成一条单独的流量工程(TrafficEngineering，简称为TE)链路。为了在节点之间进行路由、信令和链路管理，节点之间必须有一对可以“互相可达”的互联网协议(InternetProtocol，简称为IP)接口，我们称这对接口为控制通道。在此引入了链路管理协议(LinkManagementProtocol，简称为LMP)，其运行在一对网络节点之间，用于管理TE链路、检验控制通道的可达性。

控制通道管理用于确定和维护相邻节点间的控制通道，通过在两个节点之间使用配置消息交换和快速保活机制来实现。当控制通道可用(协议UP)之后，TE等业务就可以使用控制通道来传送TE信令消息了。控制通道的状态通过路由协议进行洪泛。

控制平面的故障主要有两种，一种故障是节点间通讯故障，控制面的通讯在两个节点间丢失，但是节点没有丢失控制面和转发平面状态。第二种故障是节点故障，LMP控制平面发生了故障，控制面状态丢失，而数据平面没有发生故障，节点仍然维持数据转发状态。

在实际工程部署中，如图1所示，控制通道CC1(ControlChannel1)和CC3经过R1和R3之间的L13链路，数据通道是R1和R3之间的L13链路；控制通道CC1和控制通道CC3管理着R1和R3之间的数据通道，传递控制平面的报文。

当节点R3发生控制平面故障后，R1上的控制通道在保活周期内(ms级别)一直在发送Hello消息，当保活周期一到，则停止发送Hello，另外再发送一条协商报文(Config配置协商消息)，等待一段Config消息老化时间，如果还是没收到Config的回应消息，则把控制通道置为协议DOWN状态。此时由控制通道CC1所管理的数据通道会通告到路由协议进行洪泛(洪泛R1和R3之间节点不可达)，说明该数据通道不再适合转发流量了。这个时候会造成路由协议数据的震荡，还会造成业务建立不成功，流量不通，发生丢包现象。类似的，R3发生控制平面故障时，控制通道CC3直接就置协议DOWN，然后告知路由模块进行洪泛。

针对相关技术中存在的控制平面发生故障后会将控制通道置为协议DOWN状态，导致数据丢失、路由震荡的问题，目前尚未提出有效的解决方案。

发明内容

本发明提供了一种控制通道协议状态的更新方法、装置及系统，以至少解决相关技术中存在的控制平面发生故障后会将控制通道置为协议DOWN状态，导致数据丢失、路由震荡的问题。

根据本发明的一个方面，提供了一种控制通道协议状态的更新方法，包括：检测到控制平面故障后，维持所述控制平面中控制通道的协议状态为协议UP状态；依据与重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态，其中，所述协议状态包括协议DOWN状态或协议UP状态。

在选地，在依据与所述重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态之前，还包括：判断重启节点是否具备优雅重启GR能力；在判断所述重启节点具备所述GR能力时，判断是否接收到所述重启节点发送的Hello消息和/或协商Config消息；在仅接收到所述Config消息的情况下，与所述重启节点进行协商。

优选地，依据与所述重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态包括：当所述协商结果为操作成功时，更新所述控制通道的协议状态为协议UP状态；当所述协商结果为操作失败时，更新所述控制通道的协议状态为协议DOWN状态。

优选地，在判断重启节点是否具备优雅重启GR能力之后还包括：在判断所述重启节点不具备所述GR能力时，更新所述控制通道的协议状态为协议DOWN状态。

优选地，在判断是否接收到所述重启节点发送的Hello消息和/或配置协商Config消息之后，还包括以下之一：在未接收到所述Config消息和所述Hello消息的情况下，更新所述控制通道的协议状态为协议DOWN状态；在仅接收到所述Hello消息的情况下，更新所述控制通道的协议状态为协议UP状态。

根据本发明的另一方面，还提供了一种控制通道协议状态的更新装置，其特征在于，包括：维持模块，用于在检测到控制平面故障后，维持所述控制平面中控制通道的协议状态为协议UP状态；第一更新模块，用于依据与重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态，其中，所述协议状态包括协议DOWN状态或协议UP状态。

优选地，所述控制通道协议状态的更新装置还包括：第一判断模块，用于判断重启节点是否具备优雅重启GR能力；第二判断模块，用于在第一判断模块的判断结果为所述重启节点具备所述GR能力时，判断是否接收到所述重启节点发送的Hello消息和/或协商Config消息；协商模块，用于在仅接收到所述Config消息的情况下，与所述重启节点进行协商。

优选地，所述第一更新模块包括：第一更新单元，用于当所述协商结果为操作成功时，更新所述控制通道的协议状态为协议UP状态；第二更新单元，用于当所述协商结果为操作失败时，更新所述控制通道的协议状态为协议DOWN状态。

优选地，所述控制通道的协议状态的更新装置还包括：第二更新模块，用于在所述第一判断模块的判断结果为所述重启节点不具备所述GR能力时，更新所述控制通道的协议状态为协议DOWN状态。

优选地，所述控制通道的协议状态的更新装置还包括以下之一：第三更新模块，用于在未接收到所述Config消息和所述Hello消息的情况下，更新所述控制通道的协议状态为协议DOWN状态；第四更新模块，用于在仅接收到所述Hello消息的情况下，更新所述控制通道的协议状态为协议UP状态。

根据本发明的再一方面，提供了一种控制通道协议状态的更新系统，包括上述任一项所述的装置。

通过本发明，采用检测到控制平面故障后，维持所述控制平面中控制通道的协议状态为协议UP状态；依据与重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态，其中，所述协议状态包括协议DOWN状态或协议UP状态，解决了相关技术中存在的控制平面发生故障后会将控制通道置为协议DOWN状态，导致数据丢失、路由震荡的问题，进而达到了减少数据丢失的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的控制通道协议状态的更新方法的流程图；

图2是根据本发明实施例的控制通道协议状态的更新装置的结构框图；

图3是根据本发明实施例的控制通道协议状态的更新装置的优选结构框图一；

图4是根据本发明实施例的控制通道协议状态的更新装置中第一更新模块24的结构框图；

图5是根据本发明实施例的控制通道协议状态的更新装置的优选结构框图二；

图6是根据本发明实施例的控制通道协议状态的更新装置的优选结构框图三；

图7是根据本发明实施例的控制通道协议状态的更新系统；

图8是根据本发明实施例的降低控制通道协议DOWN机率的装置的结构框图；

图9是根据本发明实施例的控制通道的拓扑图；

图10是根据本发明实施例的ctype＝2的config对象格式图；

图11是根据本发明实施例的非重启点的流程图；

图12是根据本发明实施例的重启点的流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在本实施例中提供了一种控制通道协议状态的更新方法，图1是根据本发明实施例的控制通道协议状态的更新方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，检测到控制平面故障后，维持控制平面中控制通道的协议状态为协议UP状态；

步骤S104，依据与重启节点的协商结果，更新与重启节点之间的控制通道的协议状态，其中，该协议状态包括协议DOWN状态或协议UP状态。

通过上述步骤，在检测到控制平面故障后，会维持控制平面中控制通道的协议状态为协议UP状态，依据与重启节点的协商结果，更新与重启节点之间的控制通道的协议状态，其中，该协议状态包括协议DOWN状态或协议UP状态，实现了在控制平面重启后不直接将控制通道的状态置为协议DOWN状态，而是根据与重启节点的协商结果确定是否需要将控制通道的状态置为协议DOWN状态，从而解决了相关技术中存在的控制平面发送故障后会将控制通道置为协议DOWN状态，导致数据丢失、路由震荡的问题，进而达到了减少数据丢失的效果。

在一个优选的实施例中，在依据与重启节点的协商结果，更新与重启节点之间的控制通道的协议状态之前，还包括：判断重启节点是否具备优雅重启GR能力；在判断重启节点具备GR能力时，判断是否接收到重启节点发送的Hello消息和/或配置协商Config消息；在仅接收到Config消息的情况下，与重启节点进行协商。

在一个优选的实施例中，依据与重启节点的协商结果，更新与重启节点之间的控制通道的协议状态包括：当协商结果为操作成功时，更新控制通道的协议状态为协议UP状态；当协商结果为操作失败时，更新控制通道的协议状态为协议DOWN状态。从而实现了仅在协商失败时，才将控制通道的协议状态置为协议DOWN状态，降低了对控制平面的影响。

在一个优选的实施例中，在判断重启节点是否具备优雅重启GR能力之后还包括：在判断重启节点不具备GR能力时，更新控制通道的协议状态为协议DOWN状态。

在一个优选的实施例中，在判断是否接收到重启节点发送的Hello消息和/或配置协商Config消息之后，还包括以下之一：在未接收到Config消息和Hello消息的情况下，更新该控制通道的协议状态为协议DOWN状态；在仅接收到Hello消息的情况下，更新该控制通道的协议状态为协议UP状态。从而实现了在既没有接收到Config消息也没有接收到Hello消息的情况下，再将控制通道的协议状态置为协议DOWN状态，降低了对控制平面的影响。

在本实施例中还提供了一种控制通道协议状态的更新装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本发明实施例的控制通道协议状态的更新装置的结构框图，如图2所示，该装置包括维持模块22和第一更新模块24。下面对该装置进行说明。

维持模块22，用于在检测到控制平面故障后，维持控制平面中控制通道的协议状态为协议UP状态；第一更新模块24，连接至上述维持模块22，用于依据与重启节点的协商结果，更新与重启节点之间的控制通道的协议状态，其中，该协议状态包括协议DOWN状态或协议UP状态。

图3是根据本发明实施例的控制通道协议状态的更新装置的优选结构框图一，如图3所示，该装置除包括图2所示的所有模块外，还包括第一判断模块32、第二判断模块34和协商模块36，下面对该装置进行说明。

第一判断模块32，连接至上述维持模块22，用于判断重启节点是否具备优雅重启GR能力；第二判断模块34，连接至上述第一判断模块32，用于在第一判断模块的判断结果为重启节点具备GR能力时，判断是否接收到重启节点发送的Hello消息和/或协商Config消息；协商模块36连接至上述第二判断模块34和第一更新模块24，用于在仅接收到Config消息的情况下，与重启节点进行协商。

图4是根据本发明实施例的控制通道协议状态的更新装置中第一更新模块24的结构框图，如图4所示，该第一更新模块24包括第一更新单元42或第二更新单元44，下面对该第一更新模块24进行说明。

第一更新单元42，用于当协商结果为操作成功时，更新该控制通道的协议状态为协议UP状态；第二更新单元44，用于当协商结果为操作失败时，更新控制通道的协议状态为协议DOWN状态。

图5是根据本发明实施例的控制通道协议状态的更新装置的优选结构框图二，如图5所示，该装置除包括图3所示的所有模块外，还包括第二更新模块52，下面对该装置进行说明。

第二更新模块52，连接至上述第一判断模块32，用于在第一判断模块32的判断结果为重启节点不具备GR能力时，更新控制通道的协议状态为协议DOWN状态。

图6是根据本发明实施例的控制通道协议状态的更新装置的优选结构框图三，如图6所示，该装置除包括图3所示的所有模块外，还包括第三更新模块62或第四更新模块64，下面对该装置进行说明。

第三更新模块62，连接至上述第二判断模块34，用于在未接收到Config消息和Hello消息的情况下，更新控制通道的协议状态为协议DOWN状态；第四更新模块64，连接至上述第二判断模块34，用于在仅接收到Hello消息的情况下，更新控制通道的协议状态为协议UP状态。

图7是根据本发明实施例的控制通道协议状态的更新系统，如图7所示，该控制通道协议状态的更新系统72包括上述任一项的控制通道协议状态的更新装置74。

为了避免网络中发生的节点故障导致的控制通道协议DOWN，从而引发节点不可达，本发明实施例中还提供了一种降低控制通道协议DOWN机率的方法，包括：

(1)在LMPConfig对象中添加一个ctype＝2的Config对象(class＝6)，用来协商节点是否具备优雅重启的能力，其中该Config对象包括重启时间和恢复时间；

(2)节点发生故障后将进入恢复阶段，根据恢复出来的CC数据发送Config消息，如果没有恢复出来才置协议DOWN；

(3)上下游节点CC在Hello超时后，相关CC将进入重启阶段，停止发送Hello消息，在此期间保持控制通道的状态不变，也不进行路由洪泛；

(4)上下游节点CC在收到重启点的Config消息后，相关CC进入恢复状态，进行协商，直至成功，最后更新控制通道的状态，并重新发送Hello进行保活处理。

在本发明实施例中还提供了一种降低控制通道协议DOWN机率的装置，图8是根据本发明实施例的降低控制通道协议DOWN机率的装置的结构框图，如图8所示，该装置包括配置单元82、消息编解码单元84、协议处理单元86(同上述协商模块36)、GR处理单元88(同上述维持模块22)。下面对各单元进行说明：

①配置单元82：进行GR能力的全局使能配置，以及控制通道下重启时间和恢复时间的配置；

②消息编解码单元84：接收LMP消息，提取Config消息中的GRconfig对象，解码出重启时间和恢复时间，交由协议处理单元处理；同时在收到协议处理单元86提交的Config消息发送任务时，构造Config消息中的GRconfig对象，即进行编码操作；

③协议处理单元86：根据消息编解码单元84解析出的数据，进行相应的协议处理，如果发现Hello超时或者节点重启，则进入GR处理单元进行处理；

④GR处理单元88：进行GR的恢复处理工作，即有两个阶段，一个是重启阶段，一个是恢复阶段，在这两个阶段内，控制通道状态不设置协议DOWN。

图9是根据本发明实施例的控制通道的拓扑图，以正向的节点R1->R3、R1上控制通道CC1、R3上控制通道CC3、节点R3重启为例进行说明。

扩展RFC4204第13.6小节中的config对象，增加ctype＝2这个对象，如下：

ctype＝2的config对象格式如图10所示，图10是根据本发明实施例的ctype＝2的config对象格式图：

RestartTime:16bits.(>0)

重启时间字段表示重启节点重启控制平面需要花费的时间，从启动开始，到和邻居交互Config消息结束的时间。

RecoveryTime:16bits.(>0)

恢复时间字段表示重启节点是否需要保留控制通道状态，如果不需要则设置为0，恢复时间点从重启节点和邻居重新建立邻居关系开始。

建立过程：R1发送Config协商报文给R3，除了必须携带ctype＝1的Config对象，还可以携带ctype＝2的Config对象(可选，根据是否配置了GR能力来决定)，里面包含R1节点的重启时间和恢复时间，R3纪录下这两个时间，并和自己的重启时间和恢复时间进行比较，选择合理范围内的时间，随后在configAck消息携带给R1。R1也记录下R3的重启时间和恢复时间。在控制通道CC1和CC3协议UP之后，周期性的发送Hello报文来进行监测。

R1周期性发送Hello给R3，在保活时间内没有收到Hello之后，如果存储的R3重启时间为0，则控制通道CC1协议状态变为DOWN，通知路由协议，告知R1和R3之间连通性不可达；如果存储的R3重启时间不为0，则进入重启阶段，在这个时候，停止发送Hello报文；

R3发生控制平面重启故障，起来后，如果不支持GR能力，则控制通道CC3状态为协议DOWN，通知路由协议进行洪泛；如果支持GR能力，则根据恢复出来的控制通道CC3数据，发送Config消息给R1，此时暂时不通告路由协议CC3的状态；

R1如果在重启阶段没有收到R3发过来的Config消息，也没有收到Hello消息，则认为CC1失去了通讯，协议状态置为DOWN，通告路由协议进行洪泛；如果收到了Config消息，那么进行Config协商，同时状态进入到恢复阶段，直至Config协商完成，收到R3发来的Hello消息后，GR阶段完成；

R1如果在重启阶段收到了R3发过来的Hello消息，则认为R3发生的不是控制平面节点故障，而是控制平面节点通讯故障，此时GR阶段结束，同时重新发送Hello保活报文；

R3在收到configAck消息后，按照RFC4204第3.1的方法进行报文协商，直至周期性发送Hello保活报文，GR阶段结束。

R3在恢复期间内没有收到configAck消息，则CC3协议状态置为DOWN，通告路由模块，GR阶段结束。

图11是根据本发明实施例的非重启点的流程图，如图11所示，以图9中的R1为非重启点，R3为重启点为例进行说明，该流程包括如下步骤：

步骤S1102，CC1根据RFC4204协商；

步骤S1104，发送Hello进行保活；

步骤S1106，判断Hello是否超时，在判断结果为是的情况下，转至步骤S1108，否则转至步骤S1104；

步骤S1108，判断对端peer是否支持优雅重启，在判断结果为是的情况下，转至步骤S1112，否则转至步骤S1110；

步骤S1110，置CC1为DOWN状态，通知路由进行洪范；

步骤S1112，CC1进入重启阶段，等待一段重启时间(停止发送Hello报文)；

步骤S1114，重启时间到期，判断是否收到config消息或者Hello消息，在判断结果为是时，转至步骤S1118，否则转至步骤S1116；

步骤S1116，置CC1为DOWN状态，通知路由进行洪范；

步骤S1118，判断收到的消息是否是config消息，在判断结果为是的情况下，转至步骤S1102，否则转至步骤S1120；

步骤S1120，判断收到的消息是否是Hello消息；

步骤S1122，在判断结果为是的情况下，确定对端发生的是控制面通讯故障，CC1恢复成功，进入UP状态。

图12是根据本发明实施例的重启点的流程图，如图12所示，以图9中的R1为非重启点，R3为重启点为例进行说明，该流程包括如下步骤：

步骤S1202，判断是否是控制平面故障，在判断结果为是的情况下，转至步骤S1204，否则转至步骤S1206；

步骤S1204，判断是否支持优雅重启，在判断结果为是的情况下，转至步骤S1208，否则转至步骤S1206；

步骤S1206，置CC3为DOWN状态，通知路由进行洪范，转至步骤S1212；

步骤S1208，不通知路由协议CC3协议DOWN，进入到恢复阶段；

步骤S1210，判断恢复周期是否到期，在判断结果为是的情况下，转至步骤S1206，否则转至步骤S1212；

步骤S1212，根据RFC4204发起协商流程；

步骤S1214，判断CC3是否协商UP，在判断结果为是的情况下，转至步骤S1216，否则转至步骤S1210。

步骤S1216，CC3状态置为UP，发送Hello保活报文，GR结束。

通过上述各个实施例，可以实现在节点重启后，保持控制通道的状态不改变，这样能够保证在节点发生控制平面故障期间节点之间的可达性，避免扩散错误的不可达性信息、规避路由数据的震荡，从而保障了控制和信令信息有效在节点之间转发，把对控制平面的影响降到最低，也规避了通告信息(控制通道出问题)的频繁上报现象。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种控制通道协议状态的更新方法，其特征在于，包括：

检测到控制平面故障后，维持所述控制平面中控制通道的协议状态为协议UP状态；

依据与重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态，其中，所述协议状态包括协议DOWN状态或协议UP状态。

2.根据权利要求1所述的方法，其特征在于，在依据与所述重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态之前，还包括：

判断重启节点是否具备优雅重启GR能力；

在判断所述重启节点具备所述GR能力时，判断是否接收到所述重启节点发送的Hello消息和/或协商Config消息；

在仅接收到所述Config消息的情况下，与所述重启节点进行协商。

3.根据权利要求1所述的方法，其特征在于，依据与所述重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态包括：

当所述协商结果为操作成功时，更新所述控制通道的协议状态为协议UP状态；

当所述协商结果为操作失败时，更新所述控制通道的协议状态为协议DOWN状态。

4.根据权利要求2所述的方法，其特征在于，在判断重启节点是否具备优雅重启GR能力之后还包括：

在判断所述重启节点不具备所述GR能力时，更新所述控制通道的协议状态为协议DOWN状态。

5.根据权利要求2所述的方法，其特征在于，在判断是否接收到所述重启节点发送的Hello消息和/或配置协商Config消息之后，还包括以下之一：

在未接收到所述Config消息和所述Hello消息的情况下，更新所述控制通道的协议状态为协议DOWN状态；

在仅接收到所述Hello消息的情况下，更新所述控制通道的协议状态为协议UP状态。

6.一种控制通道协议状态的更新装置，其特征在于，包括：

维持模块，用于在检测到控制平面故障后，维持所述控制平面中控制通道的协议状态为协议UP状态；

第一更新模块，用于依据与重启节点的协商结果，更新与所述重启节点之间的控制通道的协议状态，其中，所述协议状态包括协议DOWN状态或协议UP状态。

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

第一判断模块，用于判断重启节点是否具备优雅重启GR能力；

第二判断模块，用于在第一判断模块的判断结果为所述重启节点具备所述GR能力时，判断是否接收到所述重启节点发送的Hello消息和/或协商Config消息；

协商模块，用于在仅接收到所述Config消息的情况下，与所述重启节点进行协商。

8.根据权利要求6所述的装置，其特征在于，所述第一更新模块包括：

第一更新单元，用于当所述协商结果为操作成功时，更新所述控制通道的协议状态为协议UP状态；

第二更新单元，用于当所述协商结果为操作失败时，更新所述控制通道的协议状态为协议DOWN状态。

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

第二更新模块，用于在所述第一判断模块的判断结果为所述重启节点不具备所述GR能力时，更新所述控制通道的协议状态为协议DOWN状态。

10.根据权利要求7所述的装置，其特征在于，还包括以下之一：

第三更新模块，用于在未接收到所述Config消息和所述Hello消息的情况下，更新所述控制通道的协议状态为协议DOWN状态；

第四更新模块，用于在仅接收到所述Hello消息的情况下，更新所述控制通道的协议状态为协议UP状态。

11.一种控制通道协议状态的更新系统，其特征在于，包括权利要求6至10中任一项所述的装置。