A method for detecting conflicts among public attributes in the entire network

Abstract

The present invention discloses a method for detecting conflicts in public attributes across the entire network, comprising the following steps: 1) agreeing on a unique attribute across the entire network; 2) message format and content; 3) requesting and updating attribute information; 4) secondary forwarding of the attribute message; and 5) comparing old and new attributes. This method provides a data link layer protocol for detecting public attribute conflicts on the network, enabling timely notification to an external controller, which then provides unified planning and a method for detecting conflicts in public attribute value ranges for packet transmission devices with stable physical connections across the entire network.

Description

Technical Field

[0001] The present invention relates to computer network technology, in particular to a method for detecting conflicts of public attributes in the entire network. Background Art

[0002] In a network environment where a large number of packet transmission devices are deployed, the convenient network activation saves a lot of manpower and time, thanks to the dynamic planning of IP and the pre-configuration of configuration files. However, in this process, IP address conflicts or other common attribute conflicts may occur due to the peculiar network structure, human negligence, etc., resulting in the problem of public attribute conflicts of packet transmission devices in large-scale networking due to human negligence or defects in the public attribute allocation method. Summary of the Invention

[0003] The purpose of the present invention is to address the shortcomings of the existing technology and provide a method for detecting public attribute conflicts in the entire network. This method provides a data link layer protocol for detecting public attribute conflicts in the network, which can promptly inform the external controller and enable unified planning by the external controller.

[0004] The technical solution for achieving the purpose of the present invention is:

[0005] A method for detecting conflicts in public attributes across the entire network, comprising the following steps:

[0006] 1) Agree on network-wide unique attributes: One or more non-conflicting attributes are defined for the entire network. For ease of description, these common attributes are defined as the ROUTER-ID and device name DEV_NAME of the packet transmission device. The controller is a computer host connected to the device port in the packet transmission network. The packet transmission devices in the network all know the controller's IP address and can issue network-wide common attribute conflict detection commands through the interfaces provided by the packet transmission devices. When a device in the network comes online, the controller sends a detection command periodically or manually triggers it.

[0007] 2) Message format and content: When the packet transmission device directly connected to the controller receives the detection command, it sends a broadcast TLV_REQ message to all connected ports. The message carries a message header in the following format:

[0008] DA(6B) SA(6B) TYPE(2B) PDU FCS(4B)

[0009] , DA is the destination MAC address, SA is the MAC address of the local device, TYPE is the specific protocol type, which is 0x8582 and has a length of two bytes. PDU is the data portion, which is used in subsequent steps to synchronize neighbor attribute databases, respond to neighbors, and send alarm data. The PDU portion carries header information and has the following fixed format:

[0010] TYPE(1B) PACKET_LENGTH(2B) DATA

[0011] , Where TYPE is the message type, 0 represents the TLV_REQ message requesting the neighbor attribute database, 1 represents the TLV_REQ message, 2 represents the TLV_DD message, 3 represents the TLV_ACK message, and 4 represents the TLV_WARN message. PACKET_LENGTH is the length of the message, which includes the length of the header information of the PDU part. DATA is the data part of the specific message type and has a variable length.

[0012] 3) Request and update attribute information: When a device receives a TLV_REQ message, it queries the value of the public attribute of the device from the public attribute library, organizes the value of the public attribute into a TLV_DD message, and sends it out from all connected ports. When the packet transmission device receives the command from the controller and starts, it needs to send a request message to all ports connected to external devices, recorded as TLV_REQ, to request the neighbor's existing public attribute library, that is, the ROUTER-ID library and DEV_NAME library in step 1). The neighbor replies to the requesting device with a TLV_DD message containing the attribute library content of the device. The device that receives the TLV_REQ needs to forward the request from all ports except the port where the message was received, and record the REQ_ID record. The next time a TLV_REQ message with the same REQ_ID is received, it will no longer process the request, including:

[0013] 3-1) The TLV_REQ message format in step 2) is as follows:

[0014] REQ_ID(2B) NUM(2B) TYPE(1B) … TYPE(1B)

[0015] , The 2-byte REQ_ID in the TLV_REQ message indicates the sequence number of the current request. When a response message is received later, the REQ_ID value of the response message must be the same. The 2-byte NUM indicates the number of public attributes requested. The 1-byte TYPE indicates the specific type of the public attribute. The message contains multiple specific types of public attributes.

[0016] 3-2) The reply message from the attribute library ROUTER-ID library and DEV_NAME library is recorded as TLV_DD, and the message structure is as follows:

[0017] REQ_ID(2B) NUM(2B) TLV … TLV ,

[0018] Each TLV consists of four parts: Mac, Type, Sequence, Valid, Length, and Value:

[0019]

[0020] , Each TVL begins with a MAC address. The Length field only includes the length of the Value field. The Sequence field is used to compare the newness of entries. The MAC address carried in the TLV field uniquely identifies the entry during subsequent propagation. Entries in the public attribute library are compared and updated based on this unique identifier. The comparison and update method uses the Sequence field of the message. This field is a value that increases from 0x80000001 and represents the newness of the current TLV. The Sequence field increases by 1 each time it changes. When the Sequence field reaches its maximum value and changes again, the Sequence field is reset to the initial value 0x80000001, the Valid field is set to 1, and the message is flooded to the entire network. Devices that receive the message reset the Sequence field of the entry in the corresponding attribute library to 0x80000001.

[0021] 3-3) The device that receives the TLV_DD message needs to reply to the sending device with a TLV_ACK message. The PDU part of the message is TYPE 3, and the DATA part contains a 2-byte REQ_ID. If the sending device does not receive the TLV_ACK message, it is set to retransmit the TLV_DD message after a certain period of time. The certain period of time, i.e., the retransmission time, is determined by configuration or agreement and defaults to 5 seconds.

[0022] 4) Secondary forwarding of attribute message: The device that receives the TLV_DD message is in the initialization state at this time, and there is no REQ_ID stored in the cache. The device considers this to be an unprocessed message, so it compares the public attribute value in this TLV_DD message with the corresponding MAC entry in the public attribute library in sequence. If it does not exist or the value in the message is an updated value, it is added, and then the TLV_DD message is forwarded from all ports except the receiving port, otherwise it is discarded. That is, when the device updates the ROUTER-ID or DEV_NAME public attribute through other collaborative methods, it updates the entry in the corresponding attribute library of the device, changes the sequence of the corresponding entry according to steps 2-3), and then sends the entry through all connected ports through the TLV_DD message. If the received entry conflicts with the existing one, a warning message TLV_WARN is sent to the external controller;

[0023] 5) Comparison of new and old attributes: When a device receives a TLV_DD message, it first checks whether there is a public attribute value with the same MAC address in the public attribute library. Then, by comparing the size of the sequence, it retains the entry with the larger sequence value. If the received entry is a new entry, it is forwarded to all other ports except the receiving port.

[0024] The entry diffusion process described in steps 4) and 5) is convergent. When a device updates its public attributes, it sends the new entries it has organized to all adjacent devices. After receiving the latest entries, the adjacent devices update their own public attribute libraries and forward them through all ports except the port where the entries are received. If the entries are not the latest, they are directly discarded.

[0025] This method is used to detect whether there is a conflict between the two public attributes of the router-id and device name in the entire network.

[0026] This method provides a data link layer protocol for network detection of public attribute conflicts, which can promptly inform the external controller and enable unified planning by the external controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 Schematic diagram of the network connection topology in the embodiment. DETAILED DESCRIPTION

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments, but the present invention is not limited thereto.

[0029] Example:

[0030] A method for detecting conflicts in public attributes across the entire network, comprising the following steps:

[0031] 1) Agree on network-wide unique attributes: One or more non-conflicting attributes are defined for the entire network. For ease of description, these common attributes are defined as the ROUTER-ID and device name DEV_NAME of the packet transmission device. The controller is a computer host connected to the device port in the packet transmission network. The packet transmission devices in the network all know the controller's IP address and can issue network-wide common attribute conflict detection commands through the interfaces provided by the packet transmission devices. When a device in the network comes online, the controller sends a detection command periodically or manually triggers it.

[0032] 2) Message format and content: When the packet transmission device directly connected to the controller receives the detection command, it sends a broadcast TLV_REQ message to all connected ports. The message carries a message header in the following format:

[0033] DA(6B) SA(6B) TYPE(2B) PDU FCS(4B)

[0034] , DA is the destination MAC address, SA is the MAC address of the local device, TYPE is the specific protocol type, which is 0x8582 and has a length of two bytes. PDU is the data portion, which is used in subsequent steps to synchronize neighbor attribute databases, respond to neighbors, and send alarm data. The PDU portion carries header information and has the following fixed format:

[0035] TYPE(1B) PACKET_LENGTH(2B) DATA

[0036] , Where TYPE is the message type, 0 represents the TLV_REQ message requesting the neighbor attribute database, 1 represents the TLV_REQ message, 2 represents the TLV_DD message, 3 represents the TLV_ACK message, and 4 represents the TLV_WARN message. PACKET_LENGTH is the length of the message, which includes the length of the header information of the PDU part. DATA is the data part of the specific message type and has a variable length.

[0037] 3) Request and update attribute information: When a device receives a TLV_REQ message, it queries the value of the public attribute of the device from the public attribute library, organizes the value of the public attribute into a TLV_DD message, and sends it out from all connected ports. When the packet transmission device receives the command from the controller and starts, it needs to send a request message to all ports connected to external devices, recorded as TLV_REQ, to request the neighbor's existing public attribute library, that is, the ROUTER-ID library and DEV_NAME library in step 1). The neighbor replies to the requesting device with a TLV_DD message containing the attribute library content of the device. The device that receives the TLV_REQ needs to forward the request from all ports except the port where the message was received, and record the REQ_ID record. The next time a TLV_REQ message with the same REQ_ID is received, it will no longer process the request, including:

[0038] 3-1) The TLV_REQ message format in step 2) is as follows:

[0039] REQ_ID(2B) NUM(2B) TYPE(1B) … TYPE(1B)

[0040] , The 2-byte REQ_ID in the TLV_REQ message indicates the sequence number of the current request. When a response message is received later, the REQ_ID value of the response message must be the same. The 2-byte NUM indicates the number of public attributes requested. The 1-byte TYPE indicates the specific type of the public attribute. The message contains multiple specific types of public attributes.

[0041] 3-2) The reply message from the attribute library ROUTER-ID library and DEV_NAME library is recorded as TLV_DD, and the message structure is as follows:

[0042] REQ_ID(2B) NUM(2B) TLV … TLV ,

[0043] Each TLV consists of four parts: Mac, Type, Sequence, Valid, Length, and Value:

[0044]

[0045] , Each TVL begins with a MAC address. The Length field only includes the length of the Value field. The Sequence field is used to compare the newness of entries. The MAC address carried in the TLV field uniquely identifies the entry during subsequent propagation. Entries in the public attribute library are compared and updated based on this unique identifier. The comparison and update method uses the Sequence field of the message. This field is a value that increases from 0x80000001 and represents the newness of the current TLV. The Sequence field increases by 1 each time it changes. When the Sequence field reaches its maximum value and changes again, the Sequence field is reset to the initial value 0x80000001, the Valid field is set to 1, and the message is flooded to the entire network. Devices that receive the message reset the Sequence field of the entry in the corresponding attribute library to 0x80000001.

[0046] 3-3) The device that receives the TLV_DD message needs to reply to the sending device with a TLV_ACK message. The TYPE of the PDU part of the message is 3, and the DATA part contains a 2-byte REQ_ID. If the sending device does not receive the TLV_ACK message, it is set to retransmit the TLV_DD message after a certain period of time. The certain period of time, i.e., the retransmission time, is determined by configuration or agreement and defaults to 5 seconds.

[0047] 4) Secondary forwarding of attribute message: The device that receives the TLV_DD message is in the initialization state at this time, and there is no REQ_ID stored in the cache. The device considers this to be an unprocessed message, so it compares the public attribute value in this TLV_DD message with the corresponding MAC entry in the public attribute library in sequence. If it does not exist or the value in the message is an updated value, it is added, and then the TLV_DD message is forwarded from all ports except the receiving port, otherwise it is discarded. That is, when the device updates the ROUTER-ID or DEV_NAME public attribute through other collaborative methods, it updates the entry in the corresponding attribute library of the device, changes the sequence of the corresponding entry according to steps 2-3), and then sends the entry through all connected ports through the TLV_DD message. If the received entry conflicts with the existing one, a warning message TLV_WARN is sent to the external controller;

[0048] 5) Comparison of new and old attributes: When a device receives a TLV_DD message, it first checks whether there is a public attribute value with the same MAC address in the public attribute library. Then, by comparing the size of the sequence, it retains the entry with the larger sequence value. If the received entry is a new entry, it is forwarded to all other ports except the receiving port.

[0049] The entry diffusion process described in steps 4) and 5) is convergent. When a device updates its public attributes, it sends the new entries it has organized to all adjacent devices. After receiving the latest entries, the adjacent devices update their own public attribute libraries and forward them through all ports except the port where the entries are received. If the entries are not the latest, they are directly discarded.

[0050] The technical starting point of this example is to enable users to perceive public attributes in the network in real time based on public attribute conflict detection of packet transmission devices. Packet transmission devices aggregate public attribute results across the entire network through inter-device communication information, intelligently detect conflicts, notify users, and promptly adjust the public attribute distribution across the entire network, reducing labor and time costs during the network deployment phase. The specific process is as follows:

[0051] 1) If Figure 1 As shown, the controller is a computer host connected to the device port in the packet transmission network. The packet transmission devices in the network all know the IP address of the packet transmission device connected to the controller. Figure 1The address in the example is 192.168.16.30. The controller is connected to a specific port of a packet device. The specific port and the controller are configured on the same network segment. The controller can issue network-wide public attribute conflict detection commands through the interface provided by the packet transmission device and receive warning messages sent from the packet transmission network. When a device in the network comes online, the user can trigger a conflict detection command through the controller.

[0052] 2) After the packet transmission device in the network is started, it first builds a public attribute library of the device, which stores the public attributes of the device;

[0053] 3) After receiving the command, the packet transmission device dev2, which is directly connected to the controller, caches the REQ_ID in the message, queries the value in the public attribute library of this device, sends a broadcast TLV_REQ message to dev1 and dev3, and organizes the public attribute value into a TLV_DD message and sends it to dev1 and dev3; similarly, after receiving the TLV_REQ, dev1 and dev3 forward it to dev4 and dev6, organize the public attribute value into a TLV_DD message and send it to dev2, dev4, and dev6; after receiving the TLV_REQ, dev4 and dev6 forward it to dev5, and then send the TLV_DD to dev5; dev5 processes the first TLV_REQ message sent by dev4 and dev6, and discards the later one. The forwarded TLV_REQ will be discarded because the device that received the request already has a REQ_ID cache, and then dev5 replies the TLV_DD to all connected ports dev4 and dev6. In the above process, all devices that receive the TLV_DD message reply with a TLV_ACK;

[0054] 4) When receiving a new TLV_DD message, if the device detects that there is an entry in the attribute library that is the same as the public attribute of the device, it sends a TLV_WARN warning message to the controller. Figure 1 In the topology, assuming that the IP addresses of dev5 and dev6 conflict, when dev5 receives a TLV_DD message from dev6, it sends a TLV_WARN warning message to the controller.

Claims

1. A method for detecting conflicts in public attributes across the entire network, characterized in that: The steps are as follows: 1) Agree on unique attributes for the entire network: One or more attributes that cannot conflict are defined for the entire network. The public attributes are defined as the ROUTER-ID and device name DEV_NAME of the packet transmission device. The controller is a computer host connected to the device port in the packet transmission network. The packet transmission devices in the network all know the controller's IP address and can issue a command to detect public attribute conflicts in the entire network through the interface provided by the packet transmission device. When a device in the network comes online, the controller sends a detection command periodically or manually triggers it. 2) Message format and content: When the packet transmission device directly connected to the controller receives the detection command, it sends a broadcast TLV_REQ message to all connected ports. The message carries a message header in the following format: ， DA is the destination MAC address, SA is the MAC address of the local device, TYPE is the specific protocol type, which is 0x8582 and has a length of two bytes. PDU is the data portion, which carries header information and has the following fixed format: ， Where TYPE is the message type, 0 represents the TLV_REQ message requesting the neighbor attribute database, 1 represents the TLV_REQ message, 2 represents the TLV_DD message, 3 represents the TLV_ACK message, and 4 represents the TLV_WARN message. PACKET_LENGTH is the length of the message, which includes the length of the header information of the PDU part. DATA is the data part of the specific message type and has a variable length. 3) Request and update attribute information: When a device receives a TLV_REQ message, it queries the value of the public attribute of the device from the public attribute library, organizes the public attribute value into a TLV_DD message, and sends it out from all connected ports. When the packet transmission device receives the command from the controller and starts, it sends a request message to all ports connected to external devices, recorded as TLV_REQ, requesting the neighbor's existing public attribute library, that is, the ROUTER-ID and DEV_NAME in step 1). The neighbor replies to the requesting device with a TLV_DD message containing the attribute library content of the device. The device that receives the TLV_REQ needs to forward the request from all ports except the port that received the message and record the REQ_ID record. The next time it receives a TLV_REQ message with the same REQ_ID, it will no longer process the request, including: 3-1) The TLV_REQ message format in step 2) is as follows: ， The 2-byte REQ_ID in the TLV_REQ message indicates the sequence number of the current request. When a response message is received later, the REQ_ID value of the response message must be the same. The 2-byte NUM indicates the number of public attributes requested. The 1-byte TYPE indicates the specific type of the public attribute. The message contains multiple specific types of public attributes. 3-2) The reply message is recorded as TLV_DD, and the message structure is as follows: ， Each TLV consists of six parts: Mac, Type, Sequence, Valid, Length, and Value: , Each TVL begins with a MAC address. The Length field only includes the length of the Value field. The Sequence field is used to compare the newness of entries. The MAC address carried in the TLV field uniquely identifies the entry during subsequent propagation. Entries in the public attribute library are compared and updated based on this unique identifier. The comparison and update method uses the Sequence field of the message. This field is a value that increases from 0x80000001 and represents the newness of the current TLV. The Sequence field increases by 1 each time it changes. When the Sequence field reaches its maximum value and changes again, the Sequence field is reset to the initial value 0x80000001, the Valid field is set to 1, and the message is flooded to the entire network. Devices that receive the message reset the Sequence field of the entry in the corresponding attribute library to 0x80000001. 3-3) The device that receives the TLV_DD message needs to reply to the sending device with a TLV_ACK message. The TYPE of the PDU part of the message is 3, and the DATA part contains a 2-byte REQ_ID. If the sending device does not receive the TLV_ACK message, it is set to retransmit the TLV_DD message after a certain period of time. The certain period of time, i.e., the retransmission time, is determined by configuration or agreement and defaults to 5 seconds. 4) Secondary forwarding of attribute messages: When the device receiving the TLV_DD message is in the initialized state, there is no REQ_ID stored in the cache. The device considers this to be an unprocessed message, so it compares the public attribute value in this TLV_DD message with the corresponding MAC entry in the public attribute library. If it does not exist or the value in the message is an updated value, it is added, and then the TLV_DD message is forwarded from all ports except the receiving port. Otherwise, it is discarded. That is, when the local device updates the ROUTER-ID or DEV_NAME public attribute through other collaborative methods, it updates the entry in the corresponding attribute library of the local device, changes the sequence of the corresponding entry according to step 3-2), and then sends the entry through all connected ports through the TLV_DD message. If the received entry conflicts with the existing one, a warning message TLV_WARN is sent to the external controller; 5) Comparison of new and old attributes: When a device receives a TLV_DD message, it first checks whether there is a public attribute value with the same MAC address in the public attribute library. Then, by comparing the size of the sequence, it retains the entry with the larger sequence value. If the received entry is a new entry, it is forwarded to all other ports except the receiving port.

Images