CN105553864A - 降低lmp中消息数量的方法及装置 - Google Patents

降低lmp中消息数量的方法及装置 Download PDF

Info

Publication number
CN105553864A
CN105553864A CN201410608468.9A CN201410608468A CN105553864A CN 105553864 A CN105553864 A CN 105553864A CN 201410608468 A CN201410608468 A CN 201410608468A CN 105553864 A CN105553864 A CN 105553864A
Authority
CN
China
Prior art keywords
node
control channel
message
hello
splicing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201410608468.9A
Other languages
English (en)
Other versions
CN105553864B (zh
Inventor
吴海生
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201410608468.9A priority Critical patent/CN105553864B/zh
Priority to PCT/CN2015/071472 priority patent/WO2016065754A1/zh
Publication of CN105553864A publication Critical patent/CN105553864A/zh
Application granted granted Critical
Publication of CN105553864B publication Critical patent/CN105553864B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及一种降低LMP中消息数量的方法及装置，其方法：根据第二节点的当前控制通道获取第三节点的拼接目的地址；第二节点上配置有拼接使能命令；在第二节点上构造Config消息，并发送至第一节点；Config消息中携带写有第三节点的拼接目的地址的Config对象；在第一节点上解析Config消息，获取第三节点的拼接目的地址；根据第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。本发明减少了控制通道的建立过程，降低了LMP中Hello消息发送的数量，减少消息开销，且避免了由于LMP？Hello消息发送导致的网络拥塞问题；此外，还可以进一步解决某一节点间Hello消息失效的技术问题。

Description

降低LMP中消息数量的方法及装置
技术领域
本发明涉及通讯技术领域，尤其涉及一种降低LMP(LinkManagementProtocol，链路管理协议)中消息数量的方法及装置。
背景技术
在当前GMPLS协议族(Generalizedmulti-protocollabelswitching，通用多协议标记交互协议)中，LMP(LinkManagementProtocol，链路管理协议)用来管理节点之间的链路以及控制通道(IPCC：IPControlChannel)管理。
LMP的功能包括控制通道管理、链路属性关联、链路连通性验证和故障管理。其中前两项用于管理流量工程(TE:TrafficEngineering)，是链路必备的核心功能；后两项是可选的扩展功能，用于应对控制通道与数据通道分离的情况。
控制通道管理用于确定和维护相邻节点间的控制通道(双向的，即一对节点之间有两条方向相反的控制通道)，通过在两个节点之间使用配置消息协商(Config消息)和快速保活机制(Hello消息)来实现。其中Hello消息用于检测控制通道的连通性，周期性进行发送。如果节点之间存在多条控制通道，那么LMP协议会选出一条主用控制通道来管理节点之间的链路，剩余的作为备用控制通道等待使用，如果当前主用控制通道失效，那么LMP协议会将当前控制通道切换到备用控制通道上。
由于Hello消息是控制通道级别的，即每一条控制通道都有自己的Hello消息发送，那么当网络节点多起来时，控制通道也跟着增多，这样会导致Hello消息数量的爆炸式增长。在一个节点两两互连的拓扑中，如图1所示，共有4个节点，那么正常情况下会有4*3条控制通道，推而广之，在一个含有N个节点的网络中(节点两两互连)，那么就有N*(N-1)条控制通道，每条控制通道按照毫秒级别的周期发送Hello消息(RFC4204中建议Hello发送周期是150毫秒)，可想而知，当N一定大时，Hello消息量会很多，消息开销会很大，严重时会造成网络拥塞，影响业务控制报文的发送和接收，导致业务中断，造成不可预知的后果。
发明内容
本发明的主要目的在于提供一种降低LMP中消息数量的方法及装置，旨在避免由于LMPHello消息发送导致的网络拥塞问题。
为了达到上述目的，本发明提出一种降低LMP中消息数量的方法，所述LMP管理的节点至少包括第一节点、第二节点和第三节点，该方法包括：
根据第二节点的当前控制通道获取第三节点的拼接目的地址；所述第二节点上配置有拼接使能命令；
在所述第二节点上构造Config消息，并发送至第一节点；所述Config消息中携带写有所述第三节点的拼接目的地址的Config对象；
在所述第一节点上解析所述Config消息，获取所述第三节点的拼接目的地址；
根据所述第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。
优选地，该方法还包括：
根据所述第三节点的拼接目的地址，查找第一节点上是否存在到达第三节点的拼接目的地址的控制通道；
若存在，则将所述虚拟控制通道作为第一节点和第三节点之间的备用控制通道；否则
将所述虚拟控制通道作为第一节点和第三节点之间的主用控制通道。
优选地，该方法还包括：
当监测到所述第一节点或第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理。
优选地，所述当监测到所述第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理的步骤包括：
当监测到所述第二节点上的控制通道Hello消息失效时，在所述第二节点上构造Hello报文并发送至第一节点，所述Hello报文携带有Hello对象，所述Hello对象的CC_Id设置为第二节点控制通道的ID号；
在所述第一节点上解析所述Hello报文，获取Hello对象；
根据Hello对象关联虚拟控制通道，进行Hello消息失效处理。
优选地，所述根据第二节点的当前控制通道获取第三节点的拼接目的地址的步骤之前还包括：
在所述第二节点上配置拼接使能命令。
本发明实施例还提出一种降低LMP中消息数量的装置，所述LMP管理的节点至少包括第一节点、第二节点和第三节点，该装置包括：
获取模块，用于根据第二节点的当前控制通道获取第三节点的拼接目的地址；所述第二节点上配置有拼接使能命令；
编码模块，用于在所述第二节点上构造Config消息，并发送至第一节点；所述Config消息中携带写有所述第三节点的拼接目的地址的Config对象；
解码模块，用于在所述第一节点上解析所述Config消息，获取所述第三节点的拼接目的地址；
处理模块，用于根据所述第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。
优选地，所述处理模块，还用于根据所述第三节点的拼接目的地址，查找第一节点上是否存在到达第三节点的拼接目的地址的控制通道；若存在，则将所述虚拟控制通道作为第一节点和第三节点之间的备用控制通道；否则将所述虚拟控制通道作为第一节点和第三节点之间的主用控制通道。
优选地，所述处理模块，还用于当监测到所述第一节点或第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理。
优选地，所述处理模块，还用于当监测到所述第二节点上的控制通道Hello消息失效时，在所述第二节点上构造Hello报文并发送至第一节点，所述Hello报文携带有Hello对象，所述Hello对象的CC_Id设置为第二节点控制通道的ID号；在所述第一节点上解析所述Hello报文，获取Hello对象；根据Hello对象关联虚拟控制通道，进行Hello消息失效处理。
优选地，该装置还包括：
配置模块，用于在所述第二节点上配置拼接使能命令。
本发明实施例提出的一种降低LMP中消息数量的方法及装置，在节点上增加拼接使能的命令；当拼接功能使能后，向该节点的上游节点发送一条Config消息，该Config消息携带写有拼接目的地址的Config对象；上游节点收到该Config消息后，解析出其中的Config对象，得到下游节点控制通道所对应的拼接目的地址，根据拼接目的地址，建立一条从本节点到目的地址的虚拟控制通道，从而减少控制通道的建立过程，降低了LMP中Hello消息发送的数量，减少消息开销，而且避免了由于LMPHello消息发送导致的网络拥塞问题；此外，还可以进一步解决某一节点间Hello消息失效的技术问题。
附图说明
图1是现有的四节点控制通道网络图；
图2是本发明降低LMP中消息数量的方法一实施例的流程示意图；
图3是本发明实施例涉及的三节点控制通道网络图；
图4是本发明降低LMP中消息数量的方法另一实施例的流程示意图；
图5是本发明实施例涉及的主备虚拟控制通道示意图；
图6是本发明降低LMP中消息数量的方法再一实施例的流程示意图；
图7是本发明降低LMP中消息数量的装置一实施例的结构示意图；
图8是本发明降低LMP中消息数量的装置另一实施例的结构示意图。
为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。
具体实施方式
本发明实施例的解决方案主要是：在节点上增加拼接使能的命令；当拼接功能使能后，向该节点的上游节点发送一条Config消息，该Config消息携带写有拼接目的地址的Config对象；上游节点收到该Config消息后，解析出其中的Config对象，得到下游节点控制通道所对应的拼接目的地址，根据拼接目的地址，建立一条从本节点到目的地址的虚拟控制通道，从而减少控制通道的建立过程，降低了LMP中Hello消息发送的数量，减少消息开销，而且避免了由于LMPHello消息发送导致的网络拥塞问题；此外，还可以进一步解决某一节点间Hello消息失效的技术问题。
如图2所示，本发明一实施例提出一种降低LMP中消息数量的方法，所述LMP管理的节点至少包括第一节点、第二节点和第三节点，该方法包括：
步骤S101，根据第二节点的当前控制通道获取第三节点的拼接目的地址；所述第二节点上配置有拼接使能命令；
本实施例以第一节点、第二节点和第三节点三个节点组成的控制通道网络进行举例说明，同时如图3所示，以在节点1(第一节点)建立虚拟控制通道到节点3(第三节点)为例进行说明，其它节点之间的虚拟控制通道的建立同此原理。
在LMPConfig消息中添加一个ctype＝2的Config对象(class＝6)，用来通告节点拼接目的地址，即节点3的Node_Id。
在节点2(第二节点)上增加拼接使能的命令；当拼接功能使能后，如果IPCC控制通道协议UP了，那么会向该节点2的上游节点(节点1)发送一条Config消息，该消息携带ctype＝2的Config对象。
上游节点(节点1)收到该Config消息后，解析出其中的ctype＝2的Config对象，得到下游节点(节点3)控制通道所对应的拼接目的地址，根据拼接目的地址，建立一条从本节点(节点1)到下游节点(节点3)目的地址的虚拟控制通道，由此，可以减少控制通道的建立过程，降低LMP中Hello消息发送的数量，减少消息开销，而且避免由于LMPHello消息发送导致的网络拥塞问题。
具体地，首先，扩展LMP中RFC4204第13.6小节中的config对象，增加ctype＝2这个对象，ctype＝2的config对象格式如下：
其中，Node_Id:标识当前节点上所学到的对端目的地址。
在节点2上配置拼接使能命令；节点2根据当前控制通道ipcc2(控制通道ipcc2的选择可以根据用户策略来指定，比如根据控制通道的带宽大小等，默认是选择当前主用控制通道)得知目的地址，即节点3的Node_Id。
步骤S102，在所述第二节点上构造Config消息，并发送至第一节点；所述Config消息中携带写有所述第三节点的拼接目的地址的Config对象；
然后，在节点2上构造Config消息，把节点3的Node_Id写到Config对象中去，其ctype设置为2。将构造的Config消息发往节点1。
步骤S103，在所述第一节点上解析所述Config消息，获取所述第三节点的拼接目的地址；
步骤S104，根据所述第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。
节点1收到节点2发来的Config消息后，解析该Config消息，发现携带了ctype＝2的属性，则根据该属性值(即节点3的Node_Id)，建立一条虚拟控制通道ipcc1-3(关键属性中保留ipcc1、ipcc2、节点3的Node_Id信息，其中控制通道ipcc1的选择和节点2的ipcc2的选择策略类似)，目的地址为节点3的Node_Id；设置其协议状态为UP，不需要进行RFC4204发起控制通道的建立协商过程。
然后，根据节点3的Node_Id来查找当前节点1上是否存在到达节点3Node_Id的控制通道，如果存在(比如控制通道ipcc1’)，则把虚拟控制通道ipcc1-3作为(ipcc1’的)备份控制通道，如果不存在，则把虚拟控制通道ipcc1-3作为节点1和节点3之间的主用控制通道，然后直接进入到链路属性验证、链路连通性验证、故障管理等功能工作，至此，节点1到节点3就可以通过虚拟控制通道ipcc1-3来进行控制通道管理。
建立起来的虚拟控制通道ipcc1-3具备和普通控制通道一样的作用，只不过它不需要再进行Hello报文的发送，因为可以通过ipcc1和ipcc2的Hello监测来达到ipcc1-3的连通性监测，由此，可以减少控制通道的建立过程，降低LMP中Hello消息发送的数量，减少消息开销，而且避免了由于LMPHello消息发送导致的网络拥塞问题。
因此，相比现有技术，采用本实施例方案，可以在网络节点数量增加的情况下，降低控制通道增长数量，从O(n*(n-1))数量级别降到O(2*(n-1))数量级别，进而使得控制通道内Hello消息的数量得以大大降低。本方案通过两条已经存在的控制通道的拼接，来达到建立两个节点之间虚拟控制通道的目的，进而利用控制通道上已经存在的Hello消息保活来维持虚拟控制通道的保活，达到降低Hello消息的发送数量，另外也可以减少控制通道建立所带来的消息开销(Config消息、ConfigAck消息、ConfigNack消息等)，进一步降低消息数量，降低网络拥塞的机率，也降低了业务消息被拥塞的机率。
如图4所示，本发明另一实施例提出一种降低LMP中消息数量的方法，基于上述实施例，还包括：
步骤S105，当监测到所述第一节点或第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理。
相比上述实施例，本实施例还可以解决Hello消息监测失效的问题。
具体地，本实施例采用如下方案：
扩展RFC4204第13.7小节中的Hello对象，在LMPHello消息中添加一个ctype＝2的Hello对象(class＝7)，用于通知上游节点下游控制通道Hello消息监测失效，ctype＝2的Hello对象格式如下：
其中，CC_Id：标识本地节点和下游节点之间的控制通道ID号。
结合图5所示，通常，节点1上的控制通道ipcc1和节点2上的控制通道ipcc2通过周期性的Hello消息来进行连通性监测，当节点1上的控制通道ipcc1或者节点2上的控制通道ipcc2在各自的Hello老化周期内没有收到回应的Hello消息，则说明控制通道发生了故障，即控制通道失效了。
作为一种应用场景，当节点1上的ipcc1Hello失效后，关联虚拟控制通道，通知协议进行Hello失效处理。
此后可以查看是否存在节点1和节点3之间的虚拟控制通道，如果有，则可以继续使用剩余的虚拟控制通道，如图5所示，节点1和节点3之间有两条控制通道，即ipcc1-2-3和ipcc1-4-3，当节点1到节点2上的ipcc1Hello失效后，则节点1上的虚拟控制通道ipcc1-2-3就失效了，此时还存在另外一条虚拟控制通道ipcc1-4-3，那么在ipcc1失效后，ipcc1-4-3就可以切换上来，充当ipcc1-2-3的角色，进行节点1到节点3之间链路的管理工作。
作为另一种应用场景，当监测到所述第二节点上的控制通道Hello消息失效时，在所述第二节点上构造Hello报文并发送至第一节点，所述Hello报文携带有Hello对象，所述Hello对象的CC_Id设置为第二节点控制通道的ID号；在所述第一节点上解析所述Hello报文，获取Hello对象；根据Hello对象关联虚拟控制通道，进行Hello消息失效处理。
具体地，如图5所示，当节点2上的ipcc2Hello失效后，立即构造Hello报文，携带ctype＝2对象，其中的CC_Id设置为ipcc2的ID号；节点1收到该Hello报文后，关联到虚拟控制通道ipcc1-3，通知协议进行Hello失效处理。之后的处理过程同上述节点1上的ipcc1Hello失效的应用场景的后续处理过程。
本实施例通过上述方案，在节点上增加拼接使能的命令；当拼接功能使能后，向该节点的上游节点发送一条Config消息，该Config消息携带写有拼接目的地址的Config对象；上游节点收到该Config消息后，解析出其中的Config对象，得到下游节点控制通道所对应的拼接目的地址，根据拼接目的地址，建立一条从本节点到目的地址的虚拟控制通道，从而减少控制通道的建立过程，降低了LMP中Hello消息发送的数量，减少消息开销，而且避免了由于LMPHello消息发送导致的网络拥塞问题；此外，还可以进一步解决某一节点间Hello消息失效的技术问题。
如图6所示，本发明再一实施例提出一种降低LMP中消息数量的方法，基于上述实施例，在根据第二节点的当前控制通道获取第三节点的拼接目的地址的步骤之前还包括：
步骤S100，在所述第二节点上配置拼接使能命令。
相比上述实施例，本实施例还包括在第二节点上配置拼接使能命令的方案，当第二节点拼接功能使能后，如果IPCC控制通道协议UP了，那么会向该第二节点(节点2)的上游节点(节点1)发送一条Config消息，该消息携带ctype＝2的Config对象，后续具体处理流程参照上述实施例，在此不再赘述。
如图7所示，本发明一实施例提出一种降低LMP中消息数量的装置，所述LMP管理的节点至少包括第一节点、第二节点和第三节点，该装置包括：获取模块201、编码模块202、解码模块203及处理模块204，其中：
获取模块201，用于根据第二节点的当前控制通道获取第三节点的拼接目的地址；所述第二节点上配置有拼接使能命令；
编码模块202，用于在所述第二节点上构造Config消息，并发送至第一节点；所述Config消息中携带写有所述第三节点的拼接目的地址的Config对象；
解码模块203，用于在所述第一节点上解析所述Config消息，获取所述第三节点的拼接目的地址；
处理模块204，用于根据所述第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。
具体地，本实施例以第一节点、第二节点和第三节点三个节点组成的控制通道网络进行举例说明，同时如图3所示，以在节点1(第一节点)建立虚拟控制通道到节点3(第三节点)为例进行说明，其它节点之间的虚拟控制通道的建立同此原理。
在LMPConfig消息中添加一个ctype＝2的Config对象(class＝6)，用来通告节点拼接目的地址，即节点3的Node_Id。
在节点2(第二节点)上增加拼接使能的命令；当拼接功能使能后，如果IPCC控制通道协议UP了，那么会向该节点2的上游节点(节点1)发送一条Config消息，该消息携带ctype＝2的Config对象。
上游节点(节点1)收到该Config消息后，解析出其中的ctype＝2的Config对象，得到下游节点(节点3)控制通道所对应的拼接目的地址，根据拼接目的地址，建立一条从本节点(节点1)到下游节点(节点3)目的地址的虚拟控制通道，由此，可以减少控制通道的建立过程，降低LMP中Hello消息发送的数量，减少消息开销，而且避免由于LMPHello消息发送导致的网络拥塞问题。
具体地，首先，扩展LMP中RFC4204第13.6小节中的config对象，增加ctype＝2这个对象，ctype＝2的config对象格式如下：
其中，Node_Id:标识当前节点上所学到的对端目的地址。
在节点2上配置拼接使能命令；节点2根据当前控制通道ipcc2(控制通道ipcc2的选择可以根据用户策略来指定，比如根据控制通道的带宽大小等，默认是选择当前主用控制通道)得知目的地址，即节点3的Node_Id。
然后，在节点2上构造Config消息，把节点3的Node_Id写到Config对象中去，其ctype设置为2。将构造的Config消息发往节点1。
节点1收到节点2发来的Config消息后，解析该Config消息，发现携带了ctype＝2的属性，则根据该属性值(即节点3的Node_Id)，建立一条虚拟控制通道ipcc1-3(关键属性中保留ipcc1、ipcc2、节点3的Node_Id信息，其中控制通道ipcc1的选择和节点2的ipcc2的选择策略类似)，目的地址为节点3的Node_Id；设置其协议状态为UP，不需要进行RFC4204发起控制通道的建立协商过程。
然后，根据节点3的Node_Id来查找当前节点1上是否存在到达节点3Node_Id的控制通道，如果存在(比如控制通道ipcc1’)，则把虚拟控制通道ipcc1-3作为(ipcc1’的)备份控制通道，如果不存在，则把虚拟控制通道ipcc1-3作为节点1和节点3之间的主用控制通道，然后直接进入到链路属性验证、链路连通性验证、故障管理等功能工作，至此，节点1到节点3就可以通过虚拟控制通道ipcc1-3来进行控制通道管理。
建立起来的虚拟控制通道ipcc1-3具备和普通控制通道一样的作用，只不过它不需要再进行Hello报文的发送，因为可以通过ipcc1和ipcc2的Hello监测来达到ipcc1-3的连通性监测，由此，可以减少控制通道的建立过程，降低LMP中Hello消息发送的数量，减少消息开销，而且避免了由于LMPHello消息发送导致的网络拥塞问题。
因此，相比现有技术，采用本实施例方案，可以在网络节点数量增加的情况下，降低控制通道增长数量，从O(n*(n-1))数量级别降到O(2*(n-1))数量级别，进而使得控制通道内Hello消息的数量得以大大降低。本方案通过两条已经存在的控制通道的拼接，来达到建立两个节点之间虚拟控制通道的目的，进而利用控制通道上已经存在的Hello消息保活来维持虚拟控制通道的保活，达到降低Hello消息的发送数量，另外也可以减少控制通道建立所带来的消息开销(Config消息、ConfigAck消息、ConfigNack消息等)，进一步降低消息数量，降低网络拥塞的机率，也降低了业务消息被拥塞的机率。
进一步地，本实施例还可以解决Hello消息监测失效的问题。
具体地，本实施例采用如下方案：
扩展RFC4204第13.7小节中的Hello对象，在LMPHello消息中添加一个ctype＝2的Hello对象(class＝7)，用于通知上游节点下游控制通道Hello消息监测失效，ctype＝2的Hello对象格式如下：
其中，CC_Id：标识本地节点和下游节点之间的控制通道ID号。
结合图5所示，通常，节点1上的控制通道ipcc1和节点2上的控制通道ipcc2通过周期性的Hello消息来进行连通性监测，当节点1上的控制通道ipcc1或者节点2上的控制通道ipcc2在各自的Hello老化周期内没有收到回应的Hello消息，则说明控制通道发生了故障，即控制通道失效了。
作为一种应用场景，当节点1上的ipcc1Hello失效后，关联虚拟控制通道，通知协议进行Hello失效处理。
此后可以查看是否存在节点1和节点3之间的虚拟控制通道，如果有，则可以继续使用剩余的虚拟控制通道，如图5所示，节点1和节点3之间有两条控制通道，即ipcc1-2-3和ipcc1-4-3，当节点1到节点2上的ipcc1Hello失效后，则节点1上的虚拟控制通道ipcc1-2-3就失效了，此时还存在另外一条虚拟控制通道ipcc1-4-3，那么在ipcc1失效后，ipcc1-4-3就可以切换上来，充当ipcc1-2-3的角色，进行节点1到节点3之间链路的管理工作。
作为另一种应用场景，当监测到所述第二节点上的控制通道Hello消息失效时，在所述第二节点上构造Hello报文并发送至第一节点，所述Hello报文携带有Hello对象，所述Hello对象的CC_Id设置为第二节点控制通道的ID号；在所述第一节点上解析所述Hello报文，获取Hello对象；根据Hello对象关联虚拟控制通道，进行Hello消息失效处理。
具体地，如图5所示，当节点2上的ipcc2Hello失效后，立即构造Hello报文，携带ctype＝2对象，其中的CC_Id设置为ipcc2的ID号；节点1收到该Hello报文后，关联到虚拟控制通道ipcc1-3，通知协议进行Hello失效处理。之后的处理过程同上述节点1上的ipcc1Hello失效的应用场景的后续处理过程。
由此，本实施例通过上述方案，进一步解决了某一节点间Hello消息失效的技术问题。
如图8所示，本发明另一实施例提出一种降低LMP中消息数量的装置，基于上述实施例，还包括：
配置模块200，用于在所述第二节点上配置拼接使能命令。
相比上述实施例，本实施例还包括在第二节点上配置拼接使能命令的方案，当第二节点拼接功能使能后，如果IPCC控制通道协议UP了，那么会向该第二节点(节点2)的上游节点(节点1)发送一条Config消息，该消息携带ctype＝2的Config对象，后续具体处理流程参照上述实施例，在此不再赘述。
相比现有技术，采用本实施例方案，可以在网络节点数量增加的情况下，降低控制通道增长数量，从O(n*(n-1))数量级别降到O(2*(n-1))数量级别，进而使得控制通道内Hello消息的数量得以大大降低。本方案通过两条已经存在的控制通道的拼接，来达到建立两个节点之间虚拟控制通道的目的，进而利用控制通道上已经存在的Hello消息保活来维持虚拟控制通道的保活，达到降低Hello消息的发送数量，另外也可以减少控制通道建立所带来的消息开销(Config消息、ConfigAck消息、ConfigNack消息等)，进一步降低消息数量，降低网络拥塞的机率，也降低了业务消息被拥塞的机率。
此外，本实施例方案还可以进一步解决某一节点间Hello消息失效的技术问题。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种降低LMP中消息数量的方法，其特征在于，所述LMP管理的节点至少包括第一节点、第二节点和第三节点，该方法包括：
根据第二节点的当前控制通道获取第三节点的拼接目的地址；所述第二节点上配置有拼接使能命令；
在所述第二节点上构造Config消息，并发送至第一节点；所述Config消息中携带写有所述第三节点的拼接目的地址的Config对象；
在所述第一节点上解析所述Config消息，获取所述第三节点的拼接目的地址；
根据所述第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。
2.根据权利要求1所述的方法，其特征在于，还包括：
根据所述第三节点的拼接目的地址，查找第一节点上是否存在到达第三节点的拼接目的地址的控制通道；
若存在，则将所述虚拟控制通道作为第一节点和第三节点之间的备用控制通道；否则
将所述虚拟控制通道作为第一节点和第三节点之间的主用控制通道。
3.根据权利要求1所述的方法，其特征在于，还包括：
当监测到所述第一节点或第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理。
4.根据权利要求3所述的方法，其特征在于，所述当监测到所述第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理的步骤包括：
当监测到所述第二节点上的控制通道Hello消息失效时，在所述第二节点上构造Hello报文并发送至第一节点，所述Hello报文携带有Hello对象，所述Hello对象的CC_Id设置为第二节点控制通道的ID号；
在所述第一节点上解析所述Hello报文，获取Hello对象；
根据Hello对象关联虚拟控制通道，进行Hello消息失效处理。
5.根据权利要求1-4中任一项所述的方法，其特征在于，所述根据第二节点的当前控制通道获取第三节点的拼接目的地址的步骤之前还包括：
在所述第二节点上配置拼接使能命令。
6.一种降低LMP中消息数量的装置，其特征在于，所述LMP管理的节点至少包括第一节点、第二节点和第三节点，该装置包括：
获取模块，用于根据第二节点的当前控制通道获取第三节点的拼接目的地址；所述第二节点上配置有拼接使能命令；
编码模块，用于在所述第二节点上构造Config消息，并发送至第一节点；所述Config消息中携带写有所述第三节点的拼接目的地址的Config对象；
解码模块，用于在所述第一节点上解析所述Config消息，获取所述第三节点的拼接目的地址；
处理模块，用于根据所述第三节点的拼接目的地址，建立第一节点至第三节点之间的虚拟控制通道。
7.根据权利要求6所述的装置，其特征在于，
所述处理模块，还用于根据所述第三节点的拼接目的地址，查找第一节点上是否存在到达第三节点的拼接目的地址的控制通道；若存在，则将所述虚拟控制通道作为第一节点和第三节点之间的备用控制通道；否则将所述虚拟控制通道作为第一节点和第三节点之间的主用控制通道。
8.根据权利要求6所述的装置，其特征在于，
所述处理模块，还用于当监测到所述第一节点或第二节点上的控制通道Hello消息失效时，关联所述虚拟控制通道，进行Hello消息失效处理。
9.根据权利要求8所述的装置，其特征在于，
所述处理模块，还用于当监测到所述第二节点上的控制通道Hello消息失效时，在所述第二节点上构造Hello报文并发送至第一节点，所述Hello报文携带有Hello对象，所述Hello对象的CC_Id设置为第二节点控制通道的ID号；在所述第一节点上解析所述Hello报文，获取Hello对象；根据Hello对象关联虚拟控制通道，进行Hello消息失效处理。
10.根据权利要求6-9中任一项所述的装置，其特征在于，还包括：
配置模块，用于在所述第二节点上配置拼接使能命令。
CN201410608468.9A 2014-10-31 2014-10-31 降低lmp中消息数量的方法及装置 Active CN105553864B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201410608468.9A CN105553864B (zh) 2014-10-31 2014-10-31 降低lmp中消息数量的方法及装置
PCT/CN2015/071472 WO2016065754A1 (zh) 2014-10-31 2015-01-23 降低lmp中消息数量的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410608468.9A CN105553864B (zh) 2014-10-31 2014-10-31 降低lmp中消息数量的方法及装置

Publications (2)

Publication Number Publication Date
CN105553864A true CN105553864A (zh) 2016-05-04
CN105553864B CN105553864B (zh) 2020-04-28

Family

ID=55832802

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410608468.9A Active CN105553864B (zh) 2014-10-31 2014-10-31 降低lmp中消息数量的方法及装置

Country Status (2)

Country Link
CN (1) CN105553864B (zh)
WO (1) WO2016065754A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107634869A (zh) * 2016-07-18 2018-01-26 中兴通讯股份有限公司 一种Hello消息处理方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1622547A (zh) * 2003-11-28 2005-06-01 华为技术有限公司 链路管理方法
US20060133266A1 (en) * 2004-12-22 2006-06-22 Kim Young H Method of constituting and protecting control channel in IP-based network and status transition method therefor
CN101047700A (zh) * 2006-05-01 2007-10-03 华为技术有限公司 一种提高lmp控制通道可靠性的方法与装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1622547A (zh) * 2003-11-28 2005-06-01 华为技术有限公司 链路管理方法
US20060133266A1 (en) * 2004-12-22 2006-06-22 Kim Young H Method of constituting and protecting control channel in IP-based network and status transition method therefor
CN101047700A (zh) * 2006-05-01 2007-10-03 华为技术有限公司 一种提高lmp控制通道可靠性的方法与装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107634869A (zh) * 2016-07-18 2018-01-26 中兴通讯股份有限公司 一种Hello消息处理方法及装置

Also Published As

Publication number Publication date
WO2016065754A1 (zh) 2016-05-06
CN105553864B (zh) 2020-04-28

Similar Documents

Publication Publication Date Title
US9722917B2 (en) Traffic recovery in openflow networks
CN101170459B (zh) 基于双向转发链路进行故障检测与链路恢复的方法
EP2592793A1 (en) Method and apparatus for forwarding multicast traffic
CN103200109B (zh) 一种ospf邻居关系管理方法和设备
EP2498453B1 (en) Node, monitoring and administration method used thereupon, and transfer system, input circuit, and output circuit using same
EP2553870B1 (en) An operations, administrations and management proxy and a method for handling operations, administrations and management messages
CN104283711B (zh) 基于双向转发检测bfd的故障检测方法、节点及系统
CN102355421B (zh) 一种lsp网络拥塞处理的方法、装置及系统
WO2015070383A1 (zh) 一种链路聚合的方法、装置和系统
WO2011095101A1 (zh) 一种分组传送网络的线性1：n保护方法、装置和系统
US8681604B2 (en) Address refresh method and system
CN102546409B (zh) 一种基于trill网络的处理报文的方法和路由桥
EP2858302B1 (en) Connectivity check method of service stream link, related apparatus and system
JP2006033124A (ja) トンネル障害通知装置および方法
EP2472796A1 (en) Method and system for blocking protocol messages at a sub-ring control channel without virtual channel
CN102075361A (zh) 一种恢复环网业务的方法及节点设备
CN105553864A (zh) 降低lmp中消息数量的方法及装置
JP5336343B2 (ja) パス接続性確認方法及び伝送装置
CN108337162B (zh) 一种支持双归属保护的系统及方法
WO2011000184A1 (zh) 一种以太环网的单环地址刷新方法及系统
CN102223241B (zh) 网络变化通知方法和设备
CN106130783B (zh) 一种端口故障处理方法及装置
CN103647709A (zh) 一种arp表项建立方法和装置
CN104253752B (zh) 在ldp协议中实现lsp平滑切换的方法及系统
CN105871716B (zh) 基于vrrp的链路监测方法及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant