WO2011012086A1 - 避免邻居关系振荡的方法和通信设备 - Google Patents

避免邻居关系振荡的方法和通信设备 Download PDF

Info

Publication number
WO2011012086A1
WO2011012086A1 PCT/CN2010/075590 CN2010075590W WO2011012086A1 WO 2011012086 A1 WO2011012086 A1 WO 2011012086A1 CN 2010075590 W CN2010075590 W CN 2010075590W WO 2011012086 A1 WO2011012086 A1 WO 2011012086A1
Authority
WO
WIPO (PCT)
Prior art keywords
neighbor
keep
alive
task
protocol
Prior art date
Application number
PCT/CN2010/075590
Other languages
English (en)
French (fr)
Inventor
胡祖松
尹茂
李�诚
Original Assignee
迈普通信技术股份有限公司
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 迈普通信技术股份有限公司 filed Critical 迈普通信技术股份有限公司
Publication of WO2011012086A1 publication Critical patent/WO2011012086A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/026—Details of "hello" or keep-alive messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/028—Dynamic adaptation of the update intervals, e.g. event-triggered updates

Definitions

  • the present invention relates to computer network communications, and more particularly to a method and communication device for avoiding neighbor relationship oscillations. Background of the invention
  • the neighbor keep-alive part and the protocol main part (that is, the protocol state machine, protocol database, protocol algorithm, etc. implemented according to the protocol standard).
  • the protocol main part that is, the protocol state machine, protocol database, protocol algorithm, etc. implemented according to the protocol standard.
  • the protocol main part that is, the protocol state machine, protocol database, protocol algorithm, etc. implemented according to the protocol standard.
  • the priority of the protocol task is set too high, other lower priority will be caused in the system.
  • Level tasks cannot be scheduled; if the priority of the protocol task is set too low, when scheduling tasks with higher priority in the system, the protocol tasks will not be received for a period of time because they are not scheduled. To send or send a keep-alive message, this will cause the neighbor relationship to be timed out, which will trigger high-intensity calculations, and the neighbor relationship needs to be re-established, resulting in The neighbor relationship oscillates and the protocol cannot converge.
  • the neighbor keep-alive part is designed in the task of the main part of the protocol, and the two parts are implemented by the same task, that is, one protocol corresponds to one task, and the task needs to complete intensive database maintenance and calculation, and needs to be sent and received at the same time.
  • the keepalive message is used to keep the neighbors in life.
  • the implementation method can keep the neighbors normally.
  • the protocol task is less likely to be called, and more processing is performed, which may not be normal. Keep your neighbors.
  • this local optimization is not ideal in a relatively harsh integrated environment. For example, when the system service message is quite busy and the CPU resources are quite tight, the local optimization loses its effect. That is to say, this local optimization does not fundamentally solve the problem of neighbor relationship oscillating.
  • Neighbor keepalive operation requires a high degree of real-time performance. Therefore, to keep the neighbor relationship, the operation of the keep-alive neighbor relationship, that is, the neighboring live part of the protocol must be placed in a task with higher priority. For protocol-intensive computing, state machine, database maintenance, etc., that is, the main part of the protocol, because it occupies more CPU resources, it needs to be processed in a task with lower priority to avoid the occupation of the protocol. There are many CPU resources, which causes other tasks in the system to be unscheduled.
  • the embodiment of the present invention provides a method for avoiding neighbor relationship oscillation, which is applied to a network communication device, and can avoid the neighbor relationship status of a communication protocol running on the network communication device because the time is not saved. The resulting neighbor relationship oscillates.
  • Embodiments of the present invention also provide a communication device for avoiding oscillation of a neighbor relationship, the communication device
  • the trusted device can avoid the neighbor relationship oscillation caused by the neighbor state of the communication protocol running on it because the real-time keep-alive is not obtained.
  • a method for avoiding neighbor relationship oscillation includes the following steps:
  • the neighbor keep-alive task only performs the neighbor keep-alive function
  • the main task of the protocol implements the main function of the protocol according to the protocol standard, and synchronizes the neighbor relationship information and the keep-alive message to the neighbor keep-alive task;
  • a communication device for avoiding oscillation of a neighbor relationship includes at least one protocol task module, where the protocol task module includes a neighbor keep-alive task module and a protocol main task module;
  • the neighbor keep-alive task module is configured to perform only the neighbor keep-alive function
  • the protocol main task module is configured to implement the main function of the protocol according to the protocol standard, and synchronize the neighbor relationship information and the keep-alive message to the neighbor keep-alive task module in real time;
  • the neighbor keep-alive task module and the protocol main task module independently run.
  • the method for avoiding neighbor relationship oscillation and the communication device for avoiding neighbor relationship oscillation provided by the embodiment of the present invention, after the protocol task is separated into the neighbor keep-alive task and the protocol main task, in the integrated environment
  • the neighbor relationship of the protocol can be effectively kept, thus avoiding problems such as neighbor relationship oscillation, network failure, and system resource consumption caused by the CPU being busy.
  • FIG. 1 is a schematic flowchart of a method for avoiding neighbor relationship oscillation according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a communication device for avoiding neighbor relationship oscillation according to an embodiment of the present invention; Mode for carrying out the invention
  • the invention is applicable to a communication protocol with neighbor keep-alive characteristics, such as a dynamic routing protocol
  • OSPF OSPF, ISIS, BGP, etc.
  • label distribution protocol LDP label distribution protocol
  • link control protocol PPP link control protocol
  • the core idea of the embodiment of the present invention includes: separating the protocol task into a neighbor keep-alive task and a protocol main task; and by using the neighbor keep-alive task, the neighbor keep-alive task only performs the neighbor keep-alive function; the protocol main task implements the protocol according to the protocol standard.
  • the main function, and the neighbor relationship information and the keep-alive message are synchronized to the neighbor keep-alive task in real time; during the running of the protocol task, the neighbor keep-alive task and the protocol main task are independently run.
  • the neighbor keep-alive task is named HELLO task
  • the protocol principal task is named PROTO task.
  • FIG. 1 is a schematic flowchart diagram of a method for avoiding neighbor relationship oscillation according to an embodiment of the present invention. As shown in FIG. 1, the method includes the following steps:
  • Step 11 Separate tasks from protocol tasks.
  • the protocol task is separated into a neighbor keep-alive task and a protocol principal task.
  • the PROTO tasks in the protocol are specifically designed and implemented in accordance with the Internet Protocol Draft and Standards (RFC) or other standards published by the Internet Engineering Task Force (IETF), and the basic processes are not affected by the separation of protocol tasks.
  • Neighbor keep-alive tasks are designed according to the rules described in this article. Set a higher priority for the neighbor keep-alive task to meet the high real-time requirement, and set a relatively lower priority for the protocol main task to avoid the scheduling of other tasks in the system during the protocol run.
  • Step 12 By enforcing the neighbor keep-alive task, the neighbor keep-alive task only performs the neighbor keep-alive function.
  • the neighbor keep-alive task is designed according to the rules described in this article.
  • the neighboring keepalive task only implements the neighbor keepalive function.
  • the protocol subject is notified to delete the neighbor relationship.
  • the basic workflow of the HELLO task mainly includes: obtaining the neighbor relationship information and the keep-alive message of the task of the protocol; receiving the keep-alive message of the neighboring device to keep the neighbor relationship status of the device; and periodically sending the keep-alive message to the neighbor device;
  • the neighbor relationship cannot be saved (for example, if the neighbor device is shut down and the keepalive message is not received after the neighbor timeout expires), the protocol master task is notified to delete the neighbor relationship.
  • the creation and update of the neighbor relationship are completed in the PROTO task, the newly created neighbor relationship in the PROTO task is mapped to the HELLO task, and the update of the neighbor relationship is also synchronized to the HELLO task, ie, the HELLO task.
  • the maintained neighbor relationship and the neighbor relationship in the PROTO task are - corresponding.
  • the status of the neighbor relationship of the keep-alive device includes: After receiving the keep-alive message, the HELLO task finds the corresponding protocol according to the key field of the keep-alive message. Neighbors keep the state of the neighbor relationship alive.
  • the HELLO task deletes the corresponding neighbor relationship and notifies the PROTO task to delete the corresponding neighbor relationship, indicating that the neighbor relationship cannot be kept live and needs to be deleted.
  • the HELLO task needs to periodically send the keep-alive message to the neighbor device, so that the neighbor device receives the keep-alive message in time to keep the neighbor relationship alive.
  • the trigger update of the keep-alive message is processed by the PROTO task, and the PROTO task copies a keep-alive message to the HELLO task during the process of triggering the update of the keep-alive message, and sends the keep-alive message.
  • the time interval informs the HELLO task.
  • the HELLO task periodically sends the copied keep-alive message to the neighbor device according to the time interval.
  • the PROTO task needs to update or suspend the sending of keep-alive messages, the PROTO task notifies the HELLO task, and the HELLO task updates the keep-alive message or aborts the keep-alive message.
  • Step 13 The protocol main task implements the main function of the protocol according to the protocol standard, and synchronizes the neighbor relationship information and the keep-alive message to the neighbor keep-alive task.
  • the basic process of the PROTO task remains unchanged to implement the protocol main body function, but the neighbor relationship information and the keep-alive message in the protocol main task need to be synchronized to the neighbor keep-alive task.
  • the PROTO task in the protocol is specifically designed and implemented according to the description of the Internet Protocol Draft and Standard (RFC) published by the Internet Engineering Task Force (IETF) or other related standards, and the basic process can be separated from the protocol task.
  • the effect of the neighbor relationship is only slightly adjusted, that is, the PROTO task still keeps the neighbor relationship, but when the neighbor relationship of the communication device where the PROTO task is located has not received the keep-alive message, the PROTO task The neighbor relationship cannot be deleted directly.
  • the neighbor relationship can only be deleted when the HELLO task neighbor has timed out.
  • the PROTO task still keeps the neighbor relationship, which means that the database of the protocol needs to be updated according to the keep-alive situation of the neighbor relationship.
  • the basic processes of the PROTO task mainly include: Synchronizing neighbor relationship information and keep-alive messages to the HELLO task; PROTO tasks cannot directly delete the time-out unprotected neighbors maintained by this task, only after receiving HELLO The task is notified that the neighbor has timed out and needs to delete the neighbor.
  • the PROTO task determines to create a neighbor, update the neighbor relationship status, and delete the neighbor relationship according to the protocol data and the state machine.
  • the PROTO task needs to synchronize the neighbor relationship information to the HELLO task when creating the neighbor relationship or updating the neighbor relationship status.
  • the synchronized neighbor relationship information may be the key information that can uniquely identify a neighbor, that is, the neighbor relationship saved by the PROTO task and the HELLO task saved.
  • Neighbor relationships are - mapped relationships.
  • the HELLO task can keep the neighbors according to the synchronized neighbor relationship, and can uniquely find the corresponding neighbors when receiving the keep-alive message. When a PROTO task deletes a neighbor relationship, it needs to notify the HELLO task to delete the corresponding neighbor relationship.
  • the PROTO task sends a keep-alive message according to the protocol flow.
  • the keep-alive message is not sent directly to the neighbor device. Instead, the keep-alive message is synchronized to the HELLO task.
  • the HELLO task sends the keep-alive message to the neighbor device. HELLO You need to send keep-alive packets to neighbors periodically.
  • the PROTO task needs to update the keep-alive message according to the protocol running process
  • the updated keep-alive message needs to be synchronized to the HELLO task in time.
  • the PROTO task needs to stop the keep-alive message according to the protocol running process, the HELLO task needs to be notified to stop correspondingly.
  • the keep-alive message is sent.
  • the PROTO task maintains the neighbor relationship status on the local communication device, and determines whether the neighbor relationship status is saved after receiving the neighbor keep-alive notification of the HELLO task. Neighbor Relationship Status As part of the protocol operation, the PROTO task still maintains the neighbor relationship status. The PROTO task can directly delete the neighbor relationship and notify the HELLO task, because the external configuration changes of the communication device, interface status changes, and other external factors need to delete the neighbor relationship, so that the HELLO task also deletes the corresponding neighbor.
  • the PROTO task cannot delete the neighbor because the keep-alive message is not received in time, and the HELLO task can delete the neighbor when the keep-alive message is not received in time, and notify the deleted neighbor of the PROTO task, and the PROTO task receives the HELLLO task.
  • the notification can be deleted before the corresponding neighbor can be deleted.
  • Step 14 Run the neighbor keep-alive task and the protocol master task independently during the running of the protocol task of the communication device.
  • the communication between the HELLO task and the PROTO task can be considered as communication between two general tasks, and by using a standard communication method.
  • the communication between the HELLO task and the PROTO task may mainly adopt an internal TCP, a pipeline, a communication semaphore trigger, a shared data structure, and the like.
  • Communication between the HELLO task and the PROTO task but it is important to note that the inventor does not recommend a shared data structure, because once a shared data structure is used, the HELLO task and the PROTO task are required to protect the data with the same semaphore.
  • the PROTO task gets semaphores to perform intensive calculations on the shared data structure, it takes a long time to semaphore, which must cause the HELLO task to be unscheduled because it does not get the semaphore, or the task priority Flipping causes the priority of the PROTO task to be raised to and The HELLO task has the same priority, so that other tasks in the system are not scheduled.
  • step 13 may be performed first, and then step 12 is performed.
  • FIG. 2 is a schematic structural diagram of a communication device for avoiding neighbor relationship oscillation according to an embodiment of the present invention.
  • the communication device includes at least one protocol task module, where the protocol task module includes a neighbor keep-alive task module and a protocol body task module;
  • the neighbor keep-alive task module is configured to perform only the neighbor keep-alive function
  • the protocol main task module is configured to implement the main function of the protocol according to the protocol standard, and synchronize the neighbor relationship information and the keep-alive message to the neighbor keep-alive task module in real time;
  • the neighbor keep-alive task module and the protocol main task module independently run.
  • the protocol tasks running on the communication device are separated into: a neighbor keep-alive task run by the neighbor keep-alive task module and a protocol main task run by the protocol main task module, and the neighbor keep-alive task can be set.
  • a higher priority that meets the requirements of high real-time requirements, and a relatively low priority is set for the protocol principal task to avoid scheduling the scheduling of other tasks in the system during the protocol operation.
  • the neighbor keep-alive task module is configured to: obtain the neighbor relationship information and the keep-alive message of the protocol main task; receive the keep-alive message of the neighbor device to keep the neighbor relationship status of the device; and send the keep-alive message periodically.
  • the neighboring device is notified to the neighboring task module to delete the neighbor relationship when the neighbor relationship cannot be kept.
  • the creation and update of the neighbor relationship are performed by the protocol main task module, the newly created neighbor relationship of the protocol main task module is mapped to the neighbor keep-alive task module, and the update of the neighbor relationship is also synchronized to the neighbor keep-alive.
  • the task module that is, the neighbor relationship maintained by the protocol keep-alive task module and the neighbor relationship maintained by the protocol main task module are one-to-one correspondence.
  • the protocol keep-alive task module searches for the corresponding neighbor relationship of the protocol according to the key segment of the keep-alive message and keeps the neighbor relationship state alive.
  • the neighbor keep-alive task module deletes the corresponding neighbor relationship, and notifies the protocol main task module to delete the corresponding neighbor relationship, indicating that the neighbor relationship cannot be kept live and needs delete.
  • the protocol keepalive task module needs to periodically send the keep-alive message to the neighboring device, so that the neighboring device receives the keep-alive message in time to keep the neighbor relationship alive.
  • the triggered update of the keep-alive message is processed by the protocol main task module, and the protocol main task module copies a keep-alive message to the neighbor keep-alive task module in the process of processing the triggered update of the keep-alive message.
  • the neighbor keep-alive task module is notified of the interval at which the keep-alive message is sent.
  • the protocol keep-alive task module periodically sends the duplicate keep-alive message according to the time interval.
  • the protocol main task module needs to update or suspend the transmission of the keep-alive message, the protocol main task module notifies the neighbor keep-alive task module, and the neighbor keep-alive task module updates the keep-alive message or suspends the keep-alive message.
  • the protocol main task module is specifically designed and implemented according to the description of the Internet Protocol Draft and Standard (RFC) or other related standards issued by the Internet Engineering Task Force (IETF), but needs to maintain the live relationship processing function of the neighbor relationship.
  • RRC Internet Protocol Draft and Standard
  • IETF Internet Engineering Task Force
  • a slight adjustment is made, that is, the protocol main task module still keeps the neighbor relationship.
  • the neighbor of the communication device where the protocol main task module is located has not received the keep-alive message, it cannot directly delete the self-maintained timeout unprotected neighbor.
  • the neighbor can only be deleted when it receives the neighbor keep-alive task module to notify the neighbor that it has timed out.
  • the protocol main task module still keeps the neighbor relationship, which means that the database of the protocol needs to be updated according to the keep-alive situation of the neighbor relationship.
  • the basic process of the protocol main task module mainly includes: synchronizing the neighbor relationship information and the keep-alive message to the neighbor keep-alive task module; the protocol main task module cannot directly delete the timeout that is not maintained by the task.
  • a neighbor is deleted only when it receives a notification that the neighbor keep-alive task module neighbor has timed out and needs to delete the neighbor.
  • the protocol body task module determines to create a neighbor, update a neighbor state, and delete a neighbor according to the protocol data and the state machine.
  • the protocol main task module creates a neighbor or updates the neighbor status, the neighbor relationship information needs to be synchronized to the protocol keep-alive task module.
  • the synchronized neighbor relationship information can be a key information that can uniquely identify a neighbor, that is, the neighbor relationship saved by the protocol main task module.
  • the neighbor relationship saved by the protocol keep-alive task module is a one-to-one mapping relationship.
  • the protocol keep-alive task module can keep the neighbors according to the neighbor relationship that is synchronized, and can uniquely find the corresponding neighbors when receiving the keep-alive message. When the protocol main task module deletes the neighbor, it needs to notify the neighbor keep-alive task module to delete the corresponding neighbor.
  • the protocol main task module sends a keep-alive message according to the protocol flow, and the keep-alive message is not directly sent to the neighbor device, but the keep-alive message is synchronized to the protocol keep-alive task module, and the neighbor keep-alive task module keeps the keep-alive message.
  • the neighboring keepalive task module needs to send keep-alive packets to neighbors periodically.
  • the protocol main task module needs to update the keep-alive message according to the protocol running process
  • the updated keep-alive message needs to be synchronized to the neighbor keep-alive task module in time, and the protocol main task module needs to stop the keep-alive message according to the protocol running process. You need to notify the neighbor keep-alive task module to stop sending the corresponding keep-alive message.
  • the protocol main task module maintains the neighbor relationship status locally, and determines whether the neighbor relationship status is keep alive after receiving the neighbor keep-alive notification of the neighbor keep-alive task module. Neighbor relationship status As part of the protocol operation, the protocol principal task module still maintains the neighbor relationship status. The neighboring task module can directly delete the neighbor and notify the neighbor keep-alive task module, so that the neighbor keep-alive task module also deletes the corresponding neighbor, because the external configuration of the communication device changes and the interface status changes. The protocol main task module cannot delete the neighbor because the keep-alive message is not received in time, and the neighbor keep-alive task module can delete the neighbor when the keep-alive message is not received in time, and notify the deleted neighbor to the protocol main task module.
  • the protocol main task module can delete the neighbor after receiving the notification from the neighbor keep-alive task module.
  • the communication between the neighbor keep-alive task module and the protocol main task module can be implemented by using a standard communication method, such as internal TCP, pipeline, communication semaphore triggering, shared data structure, and the like. It is important to note that the communication between the neighbor keep-alive task module and the protocol main task module needs to avoid using a shared data structure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Description

避免邻居关系振荡的方法和通信设备 技术领域
本发明涉及计算机网络通信， 特别涉及一种避免邻居关系振荡的方 法和通信设备。 发明背景
在网络通信领域， 通信设备上运行的大量通信协议具有邻居关系， 需要定时保活邻居关系状态， 而且协议本身也具有较复杂的算法。 如果 不能优先保证邻居关系的建立、 维护、保活， 可能会导致邻居关系振荡， 使协议不能稳定运行。 因此， 在通信设备上设计和实现通信协议时， 如 何避免协议的邻居关系振荡是协议设计和实现时的一个重要内容。
大部分具备邻居关系的通信协议任务的实现都可以概括为两个部 分：邻居保活部分和协议主体部分（即按照协议标准实现的协议状态机、 协议数据库、 协议算法等）。 视协议的复杂程度， 协议主体部分中可能 有比较复杂的协议状态机维护、 协议数据库维护和计算等， 因此比较消 耗 CPU资源。 如果用一个任务（或者进程 )来实现一个协议的两部分内 容， 那么这里就存在一个矛盾： 邻居保活部分对实时性要求高， 在系统 中要求任务的优先级较高； 而协议主体部分因为存在密集型的计算， 消 耗 CPU资源较多，为避免对系统的影响，其任务的优先级不能设置得过 高； 如果协议任务的优先级设置得过高， 会导致系统中其他具有较低优 先级的任务得不到调度； 如果协议任务的优先级设置得过低， 则在对系 统中具有较高优先级的任务进行调度时， 协议任务因为得不到调度， 会 在一段时间内不能收到或者发送保活报文， 这将导致邻居关系超时断 开， 进而触发高密集型的计算， 并且需要重新建立邻居关系， 从而导致 邻居关系振荡， 协议迟迟不能收敛。
现有技术中， 邻居保活部分设计在协议主体部分的任务里， 两个部 分用同一任务来实现， 即一个协议对应一个任务， 该任务既需要完成密 集型的数据库维护和计算， 同时需要收发保活报文以保活邻居， 在 CPU 空闲时该种实现方式是可以正常保活邻居的，但当 CPU忙时，协议任务 得到调用的机会少， 所做的处理又多， 就可能不能正常保活邻居了。 在 综合环境下， 出现协议邻居关系振荡的情况时， 对协议主体流程本身做 些优化是必要的。 但是这种局部优化在比较恶劣的综合环境下， 效果并 不理想。 比如当系统业务报文相当繁忙时， CPU资源相当紧张时， 局部 优化就失去效果了。 即这种局部优化并不能从根本上解决邻居关系震荡 的问题。
邻居保活的操作对实时性要求相当高， 因此要保活邻居关系， 必须 把保活邻居关系的操作即协议的邻居保活部分放在一个具有较高优先 级的任务里处理。 而对于协议密集型的计算、 状态机、 数据库维护等操 作， 即协议主体部分， 因占用 CPU资源较多， 则需要放在一个具有较低 优先级的任务里处理， 以避免协议运行时因占用 CPU资源较多，导致系 统中其他任务得不到调度。
因此， 发明人经过研究发现， 有必要提出一种避免邻居关系振荡的 方法， 以解决现有技术中存在的所有问题。 发明内容
有鉴于此， 本发明的实施例提供了一种避免邻居关系振荡的方法， 该方法应用在网络通信设备上， 能够避免网络通信设备上运行的通信协 议的邻居关系状态因为得不到及时保活而导致的邻居关系振荡。
本发明的实施例还提供了一种避免邻居关系振荡的通信设备， 该通 信设备能够避免其上运行的通信协议的邻居状态因为得不到及时保活 而导致的邻居关系振荡。
为解决上述技术问题， 本发明实施例的技术方案是这样实现的： 一种避免邻居关系振荡的方法， 包括以下步骤：
将协议任务分离为邻居保活任务和协议主体任务；
邻居保活任务只执行邻居保活功能；
协议主体任务按照协议标准实现协议主体功能， 并将邻居关系信 息、 保活报文同步到邻居保活任务；
在协议任务运行过程中， 独立运行邻居保活任务和协议主体任务。 一种避免邻居关系振荡的通信设备， 包括至少一个协议任务模块， 所述协议任务模块包括邻居保活任务模块和协议主体任务模块；
所述邻居保活任务模块， 用于只执行邻居保活功能；
所述协议主体任务模块， 用于按照协议标准实现协议主体功能， 并 将邻居关系信息、 保活报文实时同步到邻居保活任务模块；
其中， 所述邻居保活任务模块和所述协议主体任务模块独立运行。 由上述技术方案可见， 在本发明的实施例提供的避免邻居关系振荡 的方法和避免邻居关系振荡的通信设备中， 在将协议任务分离为邻居保 活任务和协议主体任务后， 在综合环境中， 协议的邻居关系可以被有效 保活，从而避免了因为 CPU繁忙而导致的协议的邻居关系振荡、 网络故 障、 占用系统资源等问题。 附图简要说明
图 1为本发明一实施例的避免邻居关系振荡的方法的流程示意图； 图 2为本发明一实施例的避免邻居关系振荡的通信设备的结构示意 实施本发明的方式
本发明适用于具有邻居保活特性的通信协议， 比如动态路由协议
( OSPF、 ISIS, BGP等）， 标签分发协议 LDP, 链路控制协议 PPP等。 应用在运行邻居保活特性协议的路由器、 交换机等通信设备。
为使本发明的目的、 技术方案及优点更加清楚明白， 下面参照附图 并结合具体实施例， 对本发明做进一步详细说明。
本发明实施例的核心思想包括： 将协议任务分离为邻居保活任务和 协议主体任务； 通过筒化邻居保活任务， 邻居保活任务只执行邻居保活 功能； 协议主体任务按照协议标准实现协议主体功能， 并将邻居关系信 息、 保活报文实时同步到邻居保活任务； 在协议任务运行过程中， 独立 运行邻居保活任务和协议主体任务。 为了便于描述， 在本文中， 将邻居 保活任务命名为 HELLO任务， 将协议主体任务命名为 PROTO任务。
图 1为本发明一实施例的避免邻居关系振荡的方法的流程示意图。 如图 1所示， 该方法包括如下步骤：
步骤 11： 对协议任务进行任务分离。
在本步骤中， 将协议任务分离为邻居保活任务和协议主体任务。 协 议中的 PROTO任务按照因特网工程任务组（ IETF )发布的互联网协议 草案及标准 （RFC )或者其它标准的描述来具体设计和实现， 其基本流 程可以不受协议任务分离的影响。 邻居保活任务则按照本文所描述的规 则进行设计。 为邻居保活任务设置可以满足高实时性要求的较高优先 级， 为协议主体任务则设置相对较低的优先级， 以避免协议运行时影响 系统中其他任务的调度。
步骤 12: 通过筒化邻居保活任务， 邻居保活任务只执行邻居保活功 能。
在本步骤中， 邻居保活任务按照本文描述的规则进行筒化设计， 筒 化后的邻居保活任务仅实现邻居保活功能， 在邻居关系不能保活（超时 删除） 时通知协议主体任务删除邻居关系。 HELLO任务基本工作流程 主要包括： 获得协议主体任务的邻居关系信息和保活报文； 接收邻居设 备的保活报文保活本设备的邻居关系状态； 定时发送保活报文给邻居设 备； 在邻居关系不能保活（比如邻居设备关机了， 邻居超时时间到期后 仍然没有收到保活报文 ) 时通知协议主体任务删除邻居关系。
在本实施例中， 邻居关系的创建和更新均在 PROTO任务里完成， 在 PROTO任务中新创建的邻居关系被映射到 HELLO任务， 并且邻居 关系的更新也被同步到 HELLO任务， 即 HELLO任务里维护的邻居关 系和 PROTO任务里的邻居关系是——对应的。 具体地， HELLO任务接 收邻居设备的保活报文后， 保活所在设备的邻居关系状态包括： HELLO 任务收到保活报文后， 根据保活报文的关键字段查找到对应的本协议的 邻居并把该邻居关系状态保活。 在过了保活时间之后还没有收到邻居设 备的保活报文时， HELLO任务把相应邻居关系删除， 并且通知 PROTO 任务删除相应的邻居关系， 表明该邻居关系确实无法保活而需要删除。
在本实施例中， HELLO任务需要定时把保活报文发送到邻居设备， 使邻居设备及时收到保活报文以便把邻居关系保活。 在本实施例中， 保 活报文的触发更新由 PROTO任务处理， PROTO任务在处理保活报文的 触发更新的过程中复制一份保活报文给 HELLO任务， 并把发送保活报 文的时间间隔通知 HELLO任务。 HELLO任务根据该时间间隔定时发送 该复制的保活报文给邻居设备。 当 PROTO任务需要更新或中止保活报 文的发送时， PROTO任务通知 HELLO任务， HELLO任务及时更新保 活报文或者中止保活报文的发送。
步骤 13: 协议主体任务按照协议标准实现协议主体功能， 并将邻居 关系信息、 保活报文同步到邻居保活任务。 在本步骤中， PROTO任务基本流程保持不变以实现协议主体功能， 但需要将协议主体任务中的邻居关系信息、 保活报文同步到邻居保活任 务。
在本实施例中， 协议中的 PROTO 任务按照因特网工程任务组 ( IETF )发布的互联网协议草案及标准（RFC )或者其它相关标准的描 述来具体设计和实现， 其基本流程可以不受协议任务分离的影响， 只需 要对邻居关系的保活处理这个流程稍做调整， 即 PROTO任务仍然保活 邻居关系， 但是当 PROTO任务所在通信设备的邻居关系超时还没有收 到保活报文时， PROTO 任务不能直接删除该邻居关系， 只有在收到 HELLO任务邻居已超时的通知时才能删除该邻居关系。 PROTO任务仍 然保活邻居关系是指， 需要根据邻居关系的保活情况更新协议的数据 库。 为了支持协议任务的分离， PROTO任务的基本流程主要包括： 把 邻居关系信息和保活报文同步到 HELLO任务； PROTO任务不能直接删 除本任务维护的超时未保活的邻居， 只有在收到 HELLO任务通知邻居 已超时需要删除邻居时才删除。
在本实施例中， PROTO任务根据协议数据和状态机， 决定创建邻 居、 更新邻居关系状态、 删除邻居关系。 PROTO任务在创建邻居关系 或者更新邻居关系状态时需要把邻居关系信息同步到 HELLO任务， 同 步的邻居关系信息可以是能够唯一标识一个邻居的关键信息，即 PROTO 任务保存的邻居关系和 HELLO 任务保存的邻居关系是——映射的关 系。 HELLO任务能够根据同步过来的邻居关系保活邻居， 收到保活报 文时能够唯一地找到对应的邻居。 PROTO任务删除邻居关系时则需要 通知 HELLO任务把对应的邻居关系删除。 PROTO任务根据协议流程发 送保活报文， 保活报文不直接发送给邻居设备， 而是把保活报文同步到 HELLO任务， 由 HELLO任务把保活报文发送到邻居设备， HELLO任 务需要定时的发送保活报文给邻居设备。 另外， PROTO任务根据协议 运行过程需要更新保活报文时， 需要把更新的保活报文及时同步到 HELLO任务， PROTO任务根据协议运行过程需要停止保活报文时， 需 要通知 HELLO任务停止相应的保活报文发送。
在本实施例中， PROTO任务在本地通信设备上维护邻居关系状态， 并在接收到 HELLO 任务的邻居保活通知后确定邻居关系状态是否保 活。 邻居关系状态作为协议运算的一部分数据库， PROTO任务仍然要 维护邻居关系状态。 因为通信设备外部配置变化、 接口状态变化等外界 因素变化需要删除邻居关系时， PROTO任务可以直接删除邻居关系并 通知 HELLO任务， 使得 HELLO任务也删除相应的邻居。 PROTO任务 不能因为没有及时收到保活报文而删除邻居， 而 HELLO任务能够在没 有及时收到保活报文时删除邻居， 并且把被删除的邻居通知 PROTO任 务， PROTO任务在收到 HELLLO任务的通知后才能删除相应邻居。
步骤 14: 在通信设备的协议任务运行过程中， 独立运行邻居保活任 务和协议主体任务。
在本步骤中， HELLO任务和 PROTO任务之间的通信可以作为两个 一般任务之间的通信来考虑， 并通过采用标准的通信方法来实现。 具体 地， 所述 HELLO 任务和 PROTO任务之间的通信主要可以采用内部 TCP, 管道、 通信信号量触发、 共享数据结构等实现方式。 对 HELLO 任务和 PROTO任务之间的通信， 但需要特别注意的是， 发明人不建议 采用共享数据结构， 因为一旦采用共享数据结构， 就需要 HELLO任务 和 PROTO任务使用同样的信号量来保护这个数据结构， 如果 PROTO 任务获得信号量对共享数据结构进行密集型计算， 这就需要占用较长时 间的信号量， 务必会导致 HELLO任务因为获取不到信号量而得不到调 度， 或者任务发生优先级翻转导致 PROTO 任务的优先级提高到和 HELLO任务的优先级一样， 使得系统中其他任务得不到调度。
在本实施例中， 上述步骤是按照一定的顺序执行的， 但本领域技术 人员可以理解， 上述顺序不是一成不变的， 在将协议任务分离为邻居保 活任务和协议主体任务之后， 可以根据需要对后续步骤的执行顺序进行 调整， 例如， 可以先执行步骤 13 , 再执行步骤 12。
图 2为本发明一实施例的避免邻居关系振荡的通信设备的结构示意 图。 如图 2所示， 该通信设备包括至少一个协议任务模块， 所述协议任 务模块包括邻居保活任务模块和协议主体任务模块；
所述邻居保活任务模块， 用于只执行邻居保活功能；
所述协议主体任务模块， 用于按照协议标准实现协议主体功能， 并 将邻居关系信息、 保活报文实时同步到邻居保活任务模块；
其中， 所述邻居保活任务模块和所述协议主体任务模块独立运行。 在本实施例中， 该通信设备上运行的协议任务被分离为： 由邻居保 活任务模块运行的邻居保活任务和由协议主体任务模块运行的协议主 体任务， 并且为邻居保活任务设置可以满足高实时性要求的较高优先 级， 为协议主体任务则设置相对较低的优先级， 以避免协议运行时影响 系统中其他任务的调度。
具体地， 所述邻居保活任务模块用于： 获得协议主体任务的邻居关 系信息和保活报文； 接收邻居设备的保活报文保活本设备的邻居关系状 态； 定时发送保活报文给邻居设备； 在邻居关系不能保活时通知协议主 体任务模块删除邻居关系。
在本实施例中， 邻居关系的创建和更新均由协议主体任务模块完 成， 协议主体任务模块新创建的邻居关系被映射到邻居保活任务模块， 并且邻居关系的更新也被同步到邻居保活任务模块， 即协议保活任务模 块维护的邻居关系和协议主体任务模块维护的邻居关系是一一对应的。 具体地， 协议保活任务模块收到保活报文后， 根据保活报文的关键字段 查找到对应的本协议邻居关系并把该邻居关系状态保活。 在过了保活时 间之后还没有收到保活报文时， 邻居保活任务模块把相应邻居关系删 除， 并且通知协议主体任务模块删除相应的邻居关系， 表明该邻居关系 确实无法保活而需要删除。
具体地， 协议保活任务模块需要定时把保活报文发送到邻居设备， 使邻居设备及时收到保活报文以便把邻居关系保活。 在本实施例中， 保 活报文的触发更新由协议主体任务模块处理， 协议主体任务模块在处理 保活报文的触发更新的过程中复制一份保活报文给邻居保活任务模块， 并把发送保活报文的时间间隔通知邻居保活任务模块。 协议保活任务模 块根据该时间间隔定时发送该复制的保活报文。 当协议主体任务模块需 要更新或中止保活报文的发送时， 协议主体任务模块通知邻居保活任务 模块， 邻居保活任务模块及时更新保活报文或者中止保活报文的发送。
在本实施例中， 协议主体任务模块按照因特网工程任务组（ IETF ) 发布的互联网协议草案及标准 （RFC )或者其它相关标准的描述来具体 设计和实现， 但需要对邻居关系的保活处理功能稍做调整， 即协议主体 任务模块仍然保活邻居关系， 但是当协议主体任务模块所在的通信设备 的邻居超时还没有收到保活报文时， 不能直接删除自身维护的超时未保 活的邻居， 只有在收到邻居保活任务模块通知邻居已超时时才能删除该 邻居。 协议主体任务模块仍然保活邻居关系是指， 需要根据邻居关系的 保活情况更新协议的数据库。 为了支持协议任务的分离， 协议主体任务 模块的基本流程主要包括： 把邻居关系信息和保活报文同步到邻居保活 任务模块； 协议主体任务模块不能直接删除本任务维护的超时未保活的 邻居， 只有在收到邻居保活任务模块邻居已超时需要删除邻居的通知时 才删除。 在本实施例中， 协议主体任务模块根据协议数据和状态机， 决定创 建邻居、 更新邻居状态、 删除邻居。 协议主体任务模块创建邻居或者更 新邻居状态时需要把邻居关系信息同步到协议保活任务模块， 同步的邻 居关系信息可以是能够唯一标识一个邻居的关键信息， 即协议主体任务 模块保存的邻居关系和协议保活任务模块保存的邻居关系是一一映射 的关系。 协议保活任务模块能够根据同步过来的邻居关系保活邻居， 收 到保活报文时能够唯一的找到对应的邻居。 协议主体任务模块删除邻居 时则需要通知邻居保活任务模块把对应的邻居删除。 协议主体任务模块 根据协议流程发送保活报文， 保活报文不直接发送给邻居设备， 而是把 保活报文同步到协议保活任务模块， 由邻居保活任务模块把保活报文发 送到邻居设备， 邻居保活任务模块需要定时的发送保活报文给邻居设 备。 另外， 协议主体任务模块根据协议运行过程需要更新保活报文时， 需要把更新的保活报文及时同步到邻居保活任务模块， 协议主体任务模 块根据协议运行过程需要停止保活报文时， 需要通知邻居保活任务模块 停止相应的保活报文发送。
在本实施例中， 协议主体任务模块在本地维护邻居关系状态， 并在 接收到邻居保活任务模块的邻居保活通知后确定邻居关系状态是否保 活。 邻居关系状态作为协议运算的一部分数据库， 协议主体任务模块仍 然要维护邻居关系状态。 因为通信设备外部配置变化、 接口状态变化等 外界因素变化需要删除邻居时， 协议主体任务模块可以直接删除邻居并 通知邻居保活任务模块， 使得邻居保活任务模块也删除相应的邻居。 协 议主体任务模块不能因为没有及时收到保活报文而删除邻居， 而邻居保 活任务模块能够在没有及时收到保活报文时删除邻居， 并且把被删除的 邻居通知协议主体任务模块， 协议主体任务模块在收到邻居保活任务模 块的通知后才能删除相应邻居。 在本实施例中， 邻居保活任务模块和协议主体任务模块之间的通信 可以采用标准的通信方法来实现， 例如采用内部 TCP、 管道、 通信信号 量触发、 共享数据结构等。 需要特别注意的是， 对邻居保活任务模块和 协议主体任务模块之间的通信， 需要尽量避免采用共享数据结构。
以上所述仅为本发明的较佳实施例而已， 并非用于限定本发明的保 护范围。 凡在本发明的精神和原则之内所作的任何修改、 等同替换、 改 进等， 均应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种避免邻居关系振荡的方法， 其特征在于， 该方法包括： 将协议任务分离为邻居保活任务和协议主体任务；
邻居保活任务只执行邻居保活功能；
将协议主体任务按照协议标准实现协议主体功能， 并将邻居关系信 息、 保活报文同步到邻居保活任务；
在协议运行过程中， 独立运行邻居保活任务和协议主体任务。
2、 根据权利要求 1所述的避免邻居关系振荡的方法， 其特征在于， 该方法进一步包括：
为邻居保活任务设置实时性较高的优先级， 为协议主体任务设置实 时性较低的优先级。
3、 根据权利要求 1所述的避免邻居关系振荡的方法， 其特征在于， 所述邻居保活任务只执行邻居保活功能包括：
获得协议主体任务的邻居关系信息和保活报文， 接收邻居设备的保 活报文保活本设备的邻居关系状态， 定时发送保活报文给邻居设备。
4、 根据权利要求 3所述的避免邻居关系振荡的方法， 其特征在于， 接收邻居设备的保活报文保活本设备的邻居关系状态包括：
邻居保活任务收到保活报文后， 根据保活报文的关键字段查找到对 应的邻居并把该邻居关系状态保活。
5、 根据权利要求 3所述的避免邻居关系振荡的方法， 其特征在于， 该方法进一步包括：
在过了保活时间之后还没有收到邻居设备的保活报文时， 邻居保活 任务把相应邻居关系删除， 并且通知协议主体任务删除相应的邻居关 系。
6、 根据权利要求 3所述的避免邻居关系振荡的方法， 其特征在于， 定时发送保活报文给邻居设备包括：
协议主体任务在处理保活报文的触发更新的过程中复制一份保活 报文给邻居保活任务， 并把发送保活报文的时间间隔通知邻居保活任 务， 邻居保活任务根据该时间间隔定时发送该复制的保活报文给邻居设 备。
7、 根据权利要求 1所述的避免邻居关系振荡的方法， 其特征在于， 所述将邻居关系信息、 保活报文同步到邻居保活任务包括：
协议主体任务在创建邻居或者更新邻居状态时把邻居信息同步到 邻居保活任务；
协议主体任务需要更新保活报文时， 把更新的保活报文同步到邻居 保活任务；需要停止保活报文时，通知协议保活任务停止保活报文发送。
8、一种避免邻居关系振荡的通信设备， 其特征在于， 该通信设备包 括至少一个协议任务模块， 所述协议任务模块包括功能上相互独立的邻 居保活任务模块和协议主体任务模块；
所述邻居保活任务模块， 用于只执行邻居保活功能；
所述协议主体任务模块， 用于按照协议标准实现协议主体功能， 并 将邻居关系信息、 保活报文实时同步到邻居保活任务模块；
其中， 所述邻居保活任务模块和所述协议主体任务模块独立运行。
9、 根据权利要求 8 所述的避免邻居关系振荡的通信设备， 其特征 在于， 所述邻居保活任务模块运行邻居保活任务， 所述协议主体任务模 块运行协议主体任务； 其中邻居保活任务具有实时性较高的优先级， 为 协议主体任务具有实时性较低的优先级。
10、 根据权利要求 8所述的避免邻居关系振荡的通信设备， 其特征 在于， 所述邻居保活任务模块用于获得协议主体任务模块的邻居关系信 息和保活报文， 接收邻居设备的保活报文保活本设备的邻居关系状态， 定时发送保活报文给邻居设备。
11、 根据权利要求 10 所述的避免邻居关系振荡的通信设备， 其特 征在于， 所述邻居保活任务模块用于在收到保活报文后， 根据保活报文 的关键字段查找到对应的邻居并把该邻居关系状态保活。
12、 根据权利要求 10所述的避免邻居关系振荡的通信设备， 其特 征在于， 所述邻居保活任务模块进一步用于：
在过了保活时间之后还没有收到邻居设备的保活报文时， 把相应邻 居关系删除， 并且通知协议主体任务模块删除相应的邻居关系。
13、 根据权利要求 10所述的避免邻居关系振荡的通信设备， 其特 征在于， 所述邻居保活任务模块用于接收协议主体任务模块在处理保活 报文的触发更新的过程中复制的保活报文和发送保活报文的时间间隔， 并根据该时间间隔定时发送该复制的保活报文给邻居设备。
14、 根据权利要求 8所述的避免邻居关系振荡的通信设备， 其特征 在于， 所述协议主体任务模块在创建邻居或者更新邻居状态时把邻居信 息同步到邻居保活任务模块； 在需要更新保活报文时， 把更新的保活报 文同步到邻居保活任务模块； 在需要停止保活报文时， 通知邻居保活任 务模块停止保活报文发送。
PCT/CN2010/075590 2009-07-30 2010-07-30 避免邻居关系振荡的方法和通信设备 WO2011012086A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910304998.3 2009-07-30
CNA2009103049983A CN101610272A (zh) 2009-07-30 2009-07-30 一种避免邻居关系振荡的方法

Publications (1)

Publication Number Publication Date
WO2011012086A1 true WO2011012086A1 (zh) 2011-02-03

Family

ID=41483853

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/075590 WO2011012086A1 (zh) 2009-07-30 2010-07-30 避免邻居关系振荡的方法和通信设备

Country Status (2)

Country Link
CN (1) CN101610272A (zh)
WO (1) WO2011012086A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101610272A (zh) * 2009-07-30 2009-12-23 迈普通信技术股份有限公司 一种避免邻居关系振荡的方法
CN102014054A (zh) * 2010-11-22 2011-04-13 中兴通讯股份有限公司 保活报文的发送方法和设备
CN103560947B (zh) * 2013-10-25 2016-11-23 福建星网锐捷网络有限公司 一种避免中间系统邻居关系震荡的方法及装置
CN106161355A (zh) * 2015-04-01 2016-11-23 中兴通讯股份有限公司 一种保活报文的处理方法及装置
CN105991449B (zh) * 2015-05-27 2019-09-06 杭州迪普科技股份有限公司 一种保活优化方法及装置
CN112152745B (zh) 2019-08-07 2021-09-28 中兴通讯股份有限公司 时间同步方法、时间同步发送端、接收端及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101222443A (zh) * 2008-01-30 2008-07-16 杭州华三通信技术有限公司 一种处理报文的方法和网络设备
CN101262430A (zh) * 2008-04-25 2008-09-10 中兴通讯股份有限公司 一种分布式保活的路由设备和方法
CN101610272A (zh) * 2009-07-30 2009-12-23 迈普通信技术股份有限公司 一种避免邻居关系振荡的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101222443A (zh) * 2008-01-30 2008-07-16 杭州华三通信技术有限公司 一种处理报文的方法和网络设备
CN101262430A (zh) * 2008-04-25 2008-09-10 中兴通讯股份有限公司 一种分布式保活的路由设备和方法
CN101610272A (zh) * 2009-07-30 2009-12-23 迈普通信技术股份有限公司 一种避免邻居关系振荡的方法

Also Published As

Publication number Publication date
CN101610272A (zh) 2009-12-23

Similar Documents

Publication Publication Date Title
Alsaeedi et al. Toward adaptive and scalable OpenFlow-SDN flow control: A survey
WO2011012086A1 (zh) 避免邻居关系振荡的方法和通信设备
US9491107B1 (en) Non-stop routing with internal session mirroring and adaptive application-level rate limiting
US7860985B2 (en) Method for synchronizing connection state in data communication, and communication node using the same
US8149691B1 (en) Push-based hierarchical state propagation within a multi-chassis network device
AU2004306913B2 (en) Redundant routing capabilities for a network node cluster
US9077617B1 (en) Kernel-based TCP-layer assist for fast recovery by backup control unit of a device
US9401958B2 (en) Method, apparatus, and system for migrating user service
WO2015027739A1 (zh) 一种sdn中流表下发的方法和系统、of控制器和of交换机
US20060262734A1 (en) Transport protocol connection synchronization
WO2017219779A1 (zh) 基于链路协议的设备主备倒换方法和装置、存储介质
US9106580B2 (en) Method of supporting power control in a communication network
CN114844826B (zh) 在网络的节点之间的异步套接字复制
WO2014079271A1 (zh) 一种链路保活方法、控制器及交换机
CN101719838B (zh) 便于主备倒换的处理方法、装置及系统
US20120026900A1 (en) State synchronization of serial data link sessions connected across an ip network
JP6076937B2 (ja) パケット伝送システムおよびネットワークコントローラ
WO2008052463A1 (fr) Procede et appareil de mise a niveau a chaud de processeur de reseau
US11477288B1 (en) High availability for streaming telemetry
WO2015024477A1 (zh) 一种路由更新的实现方法及装置
CN116170367B (zh) 一种bgp链路路由收敛方法、装置、设备及介质
CN117880102A (zh) 一种边缘算力终端的算力通告装置及其算力通告策略
CN103236977B (zh) 多链接透明互联网中触发更新机制的方法和数据转发装置
Oulmahdi et al. Energy saving mechanisms on high communication layers
CN102170399A (zh) 一种调整保活时间的方法、装置、及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10803919

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10803919

Country of ref document: EP

Kind code of ref document: A1