Topology management methods and topology management apparatus, and device and network

Abstract

Disclosed are topology management methods and a topology management apparatus, and a device and a network, wherein the methods are applied in the field of communications. A first device is connected to a second device via a port. A topology management method comprises: sending a topology change request message to the second device; and receiving a topology change response message, which is sent from the second device, wherein the topology change request message comprises a packet header and a topology change identifier, the packet header comprises a type field and a response field, a first value of the type field being used for indicating a topology change, and a first value of the response field being used for indicating a request message, and the topology change identifier is used for indicating the order between topology change request messages generated by the first device; and the topology change request message comprises a packet header, and the packet header comprises a type field and a response field, a first value of the type field being used for indicating a topology change, and a second value of the response field being used for indicating a response message. The order of packets is perceived, such that the occurrence of an abnormal state of a packet and the spread of an error are avoided, thereby improving the reliability of information synchronization.

Description

Topology management method, device, equipment and network Technical Field

[0001] The present application relates to the field of communications, and in particular to a topology management method, apparatus, device, and network. Background Art

[0002] Currently, devices are interconnected using a mesh or star topology, which can create multiple loops. Packet loss and retransmissions can occur during message transmission. This can lead to duplicate processing of messages, incorrect network information transmission, and network instability.

[0003] Summary of the Invention

[0004] The present application provides a topology management method, apparatus, device, and network, thereby improving information synchronization between devices in the network.

[0005] In a first aspect, a topology management method is provided. A network includes a first device and a second device, the first device and the second device being connected via a port. The method includes: sending a topology change request message to the second device, and receiving a topology change response message sent by the second device. The topology change request message includes a message header and a topology change identifier. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change. The first value of the response field is used to indicate a request message. The topology change identifier is used to indicate the order of topology change request messages generated by the first device. The topology change response message includes a message header. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change. The second value of the response field is used to indicate a response message.

[0006] The topology management method provided in the present application indicates the order between topology change request messages according to the topology change identifier in the topology change request message, so that the device receiving the topology change request message can perceive the order of the message, avoid the abnormal status of the message and the spread of errors due to repeated transmission of the message or the loss of the message, and improve the reliability of information synchronization.

[0007] In a possible implementation, before sending the topology change request message, the method further includes: generating a topology change request message and incrementing the topology change identifier by one.

[0008] In a second aspect, a topology management method is provided, wherein a network includes a first device and a second device, the first device and the second device being connected via a port, the method comprising: receiving a topology change request message sent by the first device, and sending a topology change response message to the first device. The topology change request message includes a message header and a topology change identifier, the message header includes a type field and a response field, the first value of the type field is used to indicate a topology change, the first value of the response field is used to indicate a request message, and the topology change identifier is used to indicate the order between topology change request messages generated by the first device. The topology change response message includes a message header, the message header includes a type field and a response field, the first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

[0009] The topology management method provided in the present application indicates the order of topology change request messages according to the topology change identifier in the topology change request message, and the device receiving the topology change request message perceives the order of the message, thereby avoiding abnormal message status and error diffusion due to repeated transmission of messages or message loss, and improving the reliability of information synchronization.

[0010] In one possible implementation, the method also includes: comparing the first carried value of the topology change identifier with the recorded value; if one of the following situations occurs, the topology change identifier is considered to be continuous and the topology change is determined to be normal; the difference between the first carried value and the recorded value is equal to 1; or, the first carried value is the initial value, and the recorded value is the maximum value of the value range of the topology change identifier.

[0011] In another possible implementation, the topology change request message further includes a source address and a device entry, where the source address is used to indicate the first device; and the method further includes: incorporating the first device into the topology map according to the device entry.

[0012] In another possible implementation manner, the method further includes: forwarding a topology change request message.

[0013] In another possible implementation, the method also includes: comparing the first carried value of the topology change identifier with the recorded value; if one of the following situations occurs, it is considered that a duplicate topology change request message has been received, and the topology change is determined to be abnormal; the first carried value is equal to the recorded value; or, the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is less than a threshold; or, the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is greater than or equal to the threshold.

[0014] In another possible implementation manner, the method further includes: discarding the topology change request message.

[0015] In multi-ring out-of-order scenarios, this prevents duplicate information processing, state rollback, or state oscillation, and improves device state stability.

[0016] In another possible implementation, the method also includes: comparing the first carried value of the topology change identifier with the recorded value; if one of the following situations occurs, the topology change identifier is considered to have jumped, and the topology change is determined to be abnormal; the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is greater than or equal to the threshold; or, the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is less than the threshold.

[0017] In another possible implementation, the method also includes: sending a topology query request message to a neighboring device, the neighboring device is used to send a topology change request message; receiving a topology query response message, the device entry in the topology query response message includes a topology change identifier and a change type, the topology change identifier is used to indicate the topology change identifier of the device described by the device entry; when the second carried value of the topology change identifier is equal to the recorded value, the device entry is merged into the local topology map, and the value of the topology change identifier in each device entry is used to overwrite the topology change identifier of the locally recorded device.

[0018] In a third aspect, a topology management method is provided, wherein the network includes a first device, a second device, and a third device, the first device is connected to the second device via a port, and the first device is connected to the third device via a port, and the method includes: sending an adapter change request message to the second device, and receiving an adapter change response message sent by the second device. The adapter change request message includes a message header, a source address, an adapter change identifier, a number of adapter entries NoAE, and NoAE adapter entries, the source address is used to indicate the third device, the adapter change identifier is used to indicate the order of the adapter change request messages generated by the third device, the message header includes a type field and a response field, the second value of the type field is used to indicate an adapter change, and the first value of the response field is used to indicate a request message. The adapter change response message includes a message header, the message header includes a type field and a response field, the second value of the type field is used to indicate an adapter change, and the second value of the response field is used to indicate a response message.

[0019] The topology management method provided in the present application indicates the order between adapter change request messages according to the adapter change identifier in the adapter change request message, thereby enabling the device receiving the adapter change request message to perceive the order of the message, avoiding abnormal message status and error diffusion due to repeated transmission of the message or message loss, and improving the reliability of information synchronization.

[0020] In a possible implementation, the source address includes a source address high bit and a source address low bit.

[0021] In another possible implementation, the adapter entry includes a change type, an adapter type, and an adapter number.

[0022] In another possible implementation, before sending the adapter change request message, the method further includes: generating an adapter change request message and incrementing the adapter change identifier by one.

[0023] In a fourth aspect, a topology management method is provided, wherein a network includes a first device, a second device, and a third device, wherein the first device is connected to the second device via a port, and the first device is connected to the third device via a port, and the method includes: receiving an adapter change request message sent by the first device, and sending an adapter change response message to the first device. The adapter change request message includes a message header, a source address, an adapter change identifier, a number of adapter entries NoAE, and NoAE adapter entries, the source address is used to indicate the third device, the adapter change identifier is used to indicate the order of the adapter change request messages generated by the third device, the message header includes a type field and a response field, the second value of the type field is used to indicate an adapter change, and the first value of the response field is used to indicate a request message. The adapter change response message includes a message header, the message header includes a type field and a response field, and the second value of the response field is used to indicate a response message.

[0024] In one possible implementation, the method also includes: comparing the carried value and the recorded value of the adapter change identifier; if one of the following situations occurs, the adapter change identifier is considered continuous and the adapter change is determined to be normal; the difference between the carried value and the recorded value is equal to 1; or, the carried value is the initial value, and the recorded value is the maximum value of the value range of the adapter change identifier.

[0025] In another possible implementation, the method further includes: merging the local topology map according to the adapter entry.

[0026] In another possible implementation, the method further includes: forwarding the adapter change request message.

[0027] In another possible implementation, the method also includes: comparing the carried value and the recorded value of the adapter change identifier; if one of the following situations occurs, it is considered that a duplicate adapter change request message has been received, and the adapter change is determined to be abnormal; the carried value is equal to the recorded value; or, the carried value is less than the recorded value, and the difference between the recorded value and the carried value is less than a threshold; or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is greater than or equal to a threshold.

[0028] In another possible implementation, the method further includes discarding the adapter change request message.

[0029] In another possible implementation, the method also includes: comparing the carried value and the recorded value of the adapter change identifier; if one of the following situations occurs, it is considered that the adapter change identifier has jumped and the adapter change is determined to be abnormal; the carried value is less than the recorded value, and the difference between the recorded value and the carried value is greater than or equal to the threshold; or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is less than the threshold.

[0030] In another possible implementation, the method further includes: obtaining the adapter status from the third device indicated by the source address by performing a DCCD reading operation.

[0031] In a fifth aspect, a topology management device is provided, comprising modules for executing the operation steps of the method in the first aspect or any possible implementation of the first aspect. For example, the topology management device comprises a receiving module and a sending module.

[0032] a sending module, configured to send a topology change request message to the second device, the topology change request message including a message header and a topology change identifier, the message header including a type field and a response field, the first value of the type field being used to indicate a topology change, the first value of the response field being used to indicate a request message, and the topology change identifier being used to indicate a sequence of topology change request messages generated by the first device;

[0033] The receiving module is used to receive a topology change response message sent by the second device. The topology change response message includes a message header. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

[0034] In a possible implementation, the topology management device further includes a processing module, which is configured to generate a topology change request message and increment the topology change identifier by one.

[0035] In a sixth aspect, a topology management device is provided, comprising modules for executing the operation steps of the method in the first aspect or any possible implementation of the first aspect. For example, the topology management device comprises a receiving module and a sending module.

[0036] A receiving module is used to receive a topology change request message sent by a first device. The topology change request message includes a message header and a topology change identifier. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change. The first value of the response field is used to indicate a request message. The topology change identifier is used to indicate the order between the topology change request messages generated by the first device.

[0037] A sending module is used to send a topology change response message to the first device. The topology change response message includes a message header. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

[0038] In one possible implementation, the topology management device also includes a processing module, which is used to compare the first carried value of the topology change identifier with the recorded value; if one of the following situations occurs, the topology change identifier is considered continuous and the topology change is determined to be normal; the difference between the first carried value and the recorded value is equal to 1; or, the first carried value is the initial value, and the recorded value is the maximum value of the value range of the topology change identifier.

[0039] In another possible implementation, the topology change request message further includes a source address and a device entry, where the source address is used to indicate the first device; and the processing module is further configured to merge the topology map to which the first device belongs according to the device entry.

[0040] In another possible implementation, the sending module is further configured to forward a topology change request message.

[0041] In another possible implementation, the processing module is also used to compare the first carried value of the topology change identifier with the recorded value; if one of the following situations occurs, it is considered that a duplicate topology change request message has been received, and the topology change is determined to be abnormal; the first carried value is equal to the recorded value; or, the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is less than a threshold; or, the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is greater than or equal to the threshold.

[0042] In another possible implementation, the processing module is further configured to discard the topology change request message.

[0043] In another possible implementation, the processing module is also used to compare the first carried value of the topology change identifier with the recorded value; if one of the following situations occurs, the topology change identifier is considered to have jumped, and the topology change is determined to be abnormal; the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is greater than or equal to the threshold; or, the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is less than the threshold.

[0044] In another possible implementation, the sending module is also used to send a topology query request message to a neighboring device, and the neighboring device is used to send a topology change request message; the receiving module is also used to receive a topology query response message, and the device entry in the topology query response message includes a topology change identifier and a change type, and the topology change identifier is used to indicate the topology change identifier of the device described by the device entry; the processing module is also used to, when the second carried value of the topology change identifier is equal to the recorded value, merge the device entry into the local topology map, and overwrite the topology change identifier of the locally recorded device with the value of the topology change identifier in each device entry.

[0045] In a seventh aspect, a topology management device is provided, comprising modules for executing the operation steps of the method in the first aspect or any possible implementation of the first aspect. For example, the topology management device comprises a receiving module and a sending module.

[0046] A sending module is used to send an adapter change request message to the second device. The adapter change request message includes a message header, a source address, an adapter change identifier, the number of adapter entries NoAE and NoAE adapter entries. The source address is used to indicate the third device. The adapter change identifier is used to indicate the order of the adapter change request messages generated by the third device. The message header includes a type field and a response field. The second value of the type field is used to indicate an adapter change. The first value of the response field is used to indicate a request message.

[0047] The receiving module is used to receive the adapter change response message sent by the second device. The adapter change response message includes a message header, the message header includes a type field and a response field, the second value of the type field is used to indicate the adapter change, and the second value of the response field is used to indicate the response message.

[0048] In a possible implementation, the source address includes a source address high bit and a source address low bit.

[0049] In another possible implementation, the adapter entry includes a change type, an adapter type, and an adapter number.

[0050] In another possible implementation, the topology management device further includes a processing module, which is configured to generate an adapter change request message and increment the adapter change identifier by one.

[0051] In an eighth aspect, a topology management device is provided, comprising modules for executing the operation steps of the method in the first aspect or any possible implementation of the first aspect. For example, the topology management device comprises a receiving module and a sending module.

[0052] A receiving module is configured to receive an adapter change request message sent by a first device, wherein the adapter change request message includes a message header, a source address, an adapter change identifier, a number of adapter entries NoAE, and NoAE adapter entries. The source address is used to indicate a third device, and the adapter change identifier is used to indicate the order of adapter change request messages generated by the third device. The message header includes a type field and a response field. The second value of the type field is used to indicate an adapter change, and the first value of the response field is used to indicate a request message.

[0053] The sending module is configured to send an adapter change response message to the first device, wherein the adapter change response message includes a message header, the message header includes a type field and a response field, and the second value of the response field is used to indicate a response message.

[0054] In one possible implementation, the topology management device also includes a processing module, which is used to compare the carried value and the recorded value of the adapter change identifier; if one of the following situations occurs, the adapter change identifier is considered continuous and the adapter change is determined to be normal; the difference between the carried value and the recorded value is equal to 1; or, the carried value is the initial value, and the recorded value is the maximum value of the value range of the adapter change identifier.

[0055] In another possible implementation, the processing module is further configured to merge the adapter entry into the local topology map.

[0056] In another possible implementation, the sending module is further configured to forward the adapter change request message.

[0057] In another possible implementation, the processing module is also used to compare the carried value and the recorded value of the adapter change identifier; if one of the following situations occurs, it is considered that a duplicate adapter change request message has been received, and the adapter change is determined to be abnormal; the carried value is equal to the recorded value; or, the carried value is less than the recorded value, and the difference between the recorded value and the carried value is less than the threshold; or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is greater than or equal to the threshold.

[0058] In another possible implementation, the processing module is further configured to discard the adapter change request message.

[0059] In another possible implementation, the processing module is also used to compare the carried value and the recorded value of the adapter change identifier; if one of the following situations occurs, the adapter change identifier is considered to have jumped, and the adapter change is determined to be abnormal; the carried value is less than the recorded value, and the difference between the recorded value and the carried value is greater than or equal to the threshold; or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is less than the threshold.

[0060] In another possible implementation, the processing module is further configured to obtain the adapter status from the third device indicated by the source address by performing a DCCD reading operation.

[0061] In the ninth aspect, a transmission network is provided, which includes a first device and a second device, the first device and the second device are connected through a port, and the first device and the second device are used to execute the operating steps of the method in the first aspect or any possible implementation of the first aspect.

[0062] In another possible implementation, the network topology of the transmission network is a star topology or a mesh topology.

[0063] In the tenth aspect, an electronic device is provided, which includes a memory and a processor, the memory being used to store a set of computer instructions; when the processor executes the set of computer instructions, the processor executes the operating steps of the method in the first aspect or any possible implementation of the first aspect.

[0064] In the eleventh aspect, a chip is provided, comprising one or more interface circuits and one or more processors; the interface circuit is used to receive signals from a memory of an electronic device and send signals to the processor, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the processor executes the operating steps of the method in the first aspect or any possible implementation of the first aspect.

[0065] In the twelfth aspect, a computer-readable storage medium is provided, which stores a computer program. When the computer program runs on a computer or a processor, it enables the computer or the processor to execute the operating steps of the method in the first aspect or any possible implementation of the first aspect.

[0066] The technical effects brought about by any design method in the second aspect to the twelfth aspect can refer to the technical effects brought about by the first aspect or different design methods in the first aspect, and will not be repeated here.

[0067] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] FIG1 is a schematic diagram of a network topology provided by this application;

[0069] FIG2 is a schematic diagram of a topology update process provided by this application;

[0070] FIG3 is a schematic diagram of another topology update process provided by the present application;

[0071] FIG4 is a schematic diagram of an adapter update process provided by the present application;

[0072] FIG5 is a schematic diagram of another adapter update process provided by the present application;

[0073] FIG6 is a schematic diagram of the structure of a topology management device provided by this application

[0074] FIG7 is a schematic structural diagram of an electronic device provided in this application. DETAILED DESCRIPTION

[0075] To facilitate understanding, the main terms involved in this application are first explained.

[0076] Adapter: Responsible for converting signals / data (such as audio and video, management control information, and third-party protocol data) from external components to messages.

[0077] For example, adapters are divided into three categories: management adapters, audio and video adapters, and third-party protocol adapters (such as Universal Serial Bus (USB) adapters). Management adapters can also be called management control adapters. Audio and video adapters can also be called audio and video signal adapters.

[0078] A management adapter is a special adapter that discovers, manages, and configures the network. It provides functions such as device management, port management, bandwidth management, device control, and content protection.

[0079] The device management functions of the management adapter include topology management, device discovery, device resource discovery, etc.

[0080] Network topology refers to the physical layout of interconnected devices using transmission media, specifically the physical (real) or logical (virtual) arrangement of network members. If two networks have the same connection structure, they can be considered to have the same network topology; however, the physical wiring and inter-node distances within each network may differ.

[0081] The transmission network provided in this application can be a star topology or a mesh topology network. The transmission network includes multiple devices connected through ports.

[0082] The transport network can support up to 128 devices connected via ports. There are a maximum of 127 links between any two devices. The management adapter of each device in the network manages the transport network in a distributed manner, and each device can build a topology map and routing table with itself as the root. A device may be under the jurisdiction of multiple networks managed by multiple management adapters. The topology management method provided in this application can adapt to such scenarios and avoid conflicts between multiple management adapters.

[0083] Topology management functions include topology discovery and topology updates. The management adapter is responsible for implementing these functions through management messages. This topology management function enables the discovery of devices matching its service type, finding the optimal path to the target device, establishing a forwarding list and mapping between device addresses, and graphically displaying each device and its interconnections.

[0084] When any port of a device is connected to a new network, the device's management adapter needs to use the topology discovery function to scan all devices accessible through the port and the connection relationships between devices to complete the construction of the topology map.

[0085] After the topology is built, you need to use the topology update function to monitor changes in the topology of the devices in real time and scan the status of the changes to keep the topology up to date. The topology update function needs to monitor changes such as the addition of new devices to the topology and the disconnection of existing devices.

[0086] In order to cooperate with the management adapters of other devices in the network to complete the topology update function, the device should send a notification message to all other ports when the status of any of its ports changes, and inform the entire network of the latest port status.

[0087] The management adapter uses topology change request messages and topology change response messages to complete the topology update function.

[0088] When a device's local topology changes, it needs to notify all devices on the network via a topology change request message, similar to a broadcast. In a network, one or more loops may exist between two devices, and these paths may vary in length. Topology change request messages can adaptively select high-speed or low-speed links for transmission, as these two links have different transmission delays.

[0089] As shown in Figure 1, there are three paths between device A and device G: path 1, path 2, and path 3. Path 1 and path 2 use high-speed links, while path 3 uses a low-speed link. The order of link delays from smallest to largest is: path 2, path 1, and path 3. In this example, device A generates topology change request messages 1 and 2 consecutively, broadcasting them from these three paths. If message 1 is lost between device D and device G, the order in which device G ultimately receives the messages is: message 2-message 1-message 2-message 1-message 2. This shows that a device in the network may repeatedly receive historical messages that have already been processed, or may receive multiple topology change request messages from another device out of order due to packet loss, i.e., the topology change request message generated earlier arrives later than the one generated later.

[0090] Topology change request messages carry incremental changes; each message carries only the changes from the previous state. This requires that devices process all topology change request messages from a given device sequentially, in the order they are generated, rather than in the order they are received. Otherwise, problems such as information anomalies, state rollbacks, and state oscillation may occur.

[0091] For example, as shown in Figure 1, assume that Messages 1 and 2 are, respectively, disconnect and connect events for a port on Device A. Because the disconnect event, which should have arrived first at Device G, is lost between Device D and Device G, Device G receives the connect event first. At this point, Device G may believe that Device A is in an abnormal state. Subsequently, Device G receives a combination of "disconnect-connect-disconnect-connect" events. Although the final state is correct, the topology graph experiences unnecessary oscillation, increasing system load.

[0092] To prevent out-of-order and duplicate processing of topology change request messages, a "Change ID" field is added to topology change request messages to indicate the order of topology change request messages generated by a device. Upon receiving a topology change request message, a device can use the topology change ID carried in the message to determine whether a packet has been lost or duplicated.

[0093] Each device maintains a topology change identifier, which is initialized to 0 after power-up. Each time a topology change request message is generated, the device enters its current topology change identifier in the "Change ID" field and increments its own topology change identifier by one. The topology change identifier can range from 0 to 255. If the current value is 255, it will be 0 the next time it is received, thus cyclically incrementing. If a receiving device sees the topology change identifier change from 255 to 0, it should consider it continuous.

[0094] In addition, each device records the topology change identifier of each other device in the local topology map. When a device is added to the topology map via a topology query response message or a topology change request message, the value of the "Change ID" field in the device entry should be recorded as the topology change identifier of the device. When a device is removed from the topology map, the topology change identifier of the device does not need to be recorded.

[0095] After receiving a topology change request message and returning a topology change response message, a device compares the value in the topology change request message with the recorded value to determine whether the topology change identifier is continuous and whether the topology change is abnormal. Specifically, the device compares the value in the "Change ID" field in the topology change request message with the locally recorded topology change identifier of the message's source device.

[0096] If any of the following conditions occurs, the topology change flags are considered continuous, the topology change is normal, and the merge and forwarding processes proceed normally:

[0097] ■(carrying value – record value) == 1;

[0098] ■ Carry value == 0, and record value == 255;

[0099] ● If any of the following situations occurs, it is considered that a duplicate topology change request message has been received, and the topology change is determined to be abnormal. The message is discarded directly without merging or forwarding. This can avoid unnecessary topology fluctuations and prevent the topology change request message from being forwarded infinitely in the network:

[0100] ■Carry value == record value;

[0101] ■The carried value is less than the recorded value, and (recorded value - carried value) is less than 128;

[0102] ■The carried value is greater than the recorded value, and (carried value - recorded value) is greater than or equal to 128;

[0103] If any of the following situations occurs, the topology change flag is considered to have changed, packet loss has occurred, and the topology change is considered abnormal. This triggers topology change abnormality handling:

[0104] ■ Carried value < recorded value, and (recorded value - carried value) >= 128;

[0105] ■The carried value is greater than the recorded value, and (carried value - recorded value) is less than 128;

[0106] If a device has multiple ports in the Ready or Standby state, and the speeds of the ports vary significantly, and if multiple topology change request messages are received consecutively from the same source device, it is recommended that the device suspend forwarding topology change request messages when the faster port has forwarded more than N messages ahead of the slower port, and N is less than 128. This prevents other devices from misinterpreting duplicate messages as packet loss.

[0107] If the topology change flag indicates packet loss in a topology change request message, the received topology change request message may not accurately reflect the current topology state. Consequently, the anomalous topology change request message cannot be incorporated into the local topology map. This situation is called a topology change anomaly. The following describes how to resolve a topology change anomaly and the device's behavior requirements until the anomaly is resolved.

[0108] The management adapter maintains a topology change exception status for each device in the topology map, indicating whether a topology change request message from that device has been lost. When an exception is detected for a topology change request message, the adapter temporarily stores the message locally and temporarily stops merging and forwarding it to prevent the error from spreading across the network.

[0109] The neighboring device connected to the receiving port of the topology change request message is able to forward this message, indicating that no packet loss has occurred before. To resolve this topology change anomaly, the neighboring device needs to send a topology query request message to perform a full topology synchronization with it. After receiving the topology query response message from the neighboring device, it must also ensure that its topology map is not behind the local one before merging this topology query response message into the topology map to avoid topology rollback after merging. Only when the value of "Change ID" in each device entry carried in the message is not less than the topology change identifier recorded locally for the device does it mean that its topology map is not behind the local one.

[0110] If the neighboring device's topology lags behind the local topology, retry with a topology query request message after tXXX 1 second. If this situation persists after 10 retries, the neighboring device may also be experiencing a topology change exception and is relying on the local device to resolve the topology change exception first. In this case, the management adapter should attempt to resolve this exception by sending a topology query request to other ports.

[0111] If the neighboring device's topology map is not behind the local topology map, the topology query response message is merged into the local topology map, and the locally recorded topology change identifier of the device is overwritten with the Change ID value in each device entry.

[0112] Before sending a topology query request message to a neighboring device, a device must also complete the following steps to ensure that the local topology map is up to date:

[0113] ● Wait until all previously received topology change request messages have been merged into the local topology map and forwarded;

[0114] ●Wait until all topology query request messages sent by other ports have received corresponding topology query response messages and merged them into the topology map, and the forwarding of the topology change request message generated by the topology query response message has been completed.

[0115] ●After the above two steps, if the exception is still not resolved, start sending topology query request messages to neighboring devices.

[0116] To avoid introducing more errors and to prevent the topology map of neighboring devices from lagging behind the local topology map, if there is any topology change exception, the topology change request message received after the exception occurs will no longer be merged into the local topology map, and a new topology discovery process will no longer be initiated. However, if a topology query request message is received, a topology query response message should be replied according to the rules, carrying the current topology map.

[0117] If a device in the topology diagram is experiencing a topology change anomaly, a topology change request message received from that device on any port will not be merged or forwarded. Instead, the message will be temporarily stored locally and will be merged and forwarded again after the topology change anomaly on the device is resolved. This is unless the message resolves the topology change anomaly on the device, that is, the "Change ID" value carried by the message restores the topology change identifier of the device to a continuous state.

[0118] If any device in the topology diagram experiences a topology change anomaly and receives a topology change request message from a non-anomaly device on any port, the message will not be merged into the process, but will continue to be forwarded normally. The message will also be temporarily stored locally until all previous topology change anomalies are resolved before it is merged into the topology diagram. It is important to note that the continuity of the topology change identifier must be verified during forwarding. If a topology change request message experiences an anomaly, subsequent topology change request messages from that device will be treated as if it were an anomaly and will not be merged or forwarded.

[0119] After resolving the device's topology change anomaly through a topology query response message or a topology change request message, the topology change request messages temporarily stored locally should be processed sequentially in the order in which they were received. None of these messages have been incorporated into the topology map, but some have been forwarded and some have not. Whether to incorporate them into the topology map should be determined based on the topology change identifier currently recorded locally. However, for topology change request messages that have not been forwarded, even if the topology change identifier in the topology change request message is smaller than the topology change identifier currently recorded locally, the forwarding process should be carried out sequentially according to the rules. When processing these topology change request messages temporarily stored locally, new anomalies may be encountered. Simply resolve the anomalies sequentially according to the process described in this section.

[0120] Note 1: If a topology query response message is received that is triggered by an exception, and the exception has been cleared, the topology query response message is directly discarded.

[0121] Note 2: When a topology change exception occurs, if a topology change request message is received on this port after a topology query request message is sent but before a topology query response message is received, the device must temporarily store the topology change message locally and cannot discard it after forwarding it. This is because the topology change exception may be cleared prematurely, ignoring the subsequent topology query response message.

[0122] Note 3: When a topology change exception occurs, the topology change identifier used for forwarding and the topology change identifier merged into the topology map may be temporarily inconsistent. The management adapter should temporarily maintain two topology change identifiers for each source device.

[0123] The difference between the adapter change identifier and the topology change identifier is that each device only maintains the adapter change identifier of the device it is interested in. If it does not match its own business type, it will not incorporate the adapter change request message from the device, but still needs to forward it to other ports.

[0124] When a device receives an adapter change request message, it determines whether the adapter change identifiers are continuous, repeated, or lost based on the value carried in the adapter change identifier and the recorded value. For the judgment rules, refer to the description of the topology change identifier above.

[0125] Unlike the topology change exception handling method, if an adapter change flag anomaly occurs, the device cannot initiate a full synchronization with the receiving port's neighboring devices, as neighboring devices may not maintain the adapter information for the anomaly source device. Instead, by reading the DCCD, a full query is performed on the anomaly source device. Furthermore, even if an anomaly occurs, the adapter change request message must still be forwarded rather than stored locally, as other devices can only perform a full query on the anomaly source device, not on neighboring devices.

[0126] The following describes the topology update process.

[0127] Figure 2 is a schematic diagram of a topology update process provided by this application. A network includes multiple devices connected via ports. Here, a topology update process is initiated by a first device and a second device as an example. The first device and the second device can be any of the devices shown in Figure 2. For example, the first device is device A, and the second device can be device C shown in Figure 2. As shown in Figure 2, the method includes the following steps.

[0128] Step 210: The first device sends a topology change request message to the second device.

[0129] A topology change request message includes a message header, source address, a second topology change identifier (Change ID), the number of device entries (NoDE), and the number of device entries (NoDE). The message header includes a type field and a response field. The first value of the type field indicates a topology change, and the first value of the response field indicates a request message. The source address is the address of the device generating the topology change request message. The second topology change identifier indicates the order in which topology change request messages are generated.

[0130] For example, a Type field value of 1 indicates that the message is a topology change message. A Response field value of 0 indicates that the message is a request message. That is, if the Type field value of a message is 1 and the Response field value is 0, the message is a topology change request message.

[0131] It should be noted that when a topology change request message is generated or a topology query response message is received, the topology change identifier is incremented by one.

[0132] The format of the topology change request message is shown in Table 1, and the description of each field in the topology change request message is shown in Table 2.

[0133] Table 1

[0134] Table 2

[0135] A device entry includes a device address, a first topology change identifier, a change type, a number of port entries (NoPE), an adapter online identifier, and NoPE port entries. The first topology change identifier indicates the topology change identifier for the device described by the device entry. The first value of the change type indicates a change to the device entry. The device address includes the device address high bit and the device address low bit.

[0136] The format of the device entry is shown in Table 3, and the description of each field in the device entry is shown in Table 4. Table 3

[0137] Table 4

[0138] The port entry includes a port identifier, a port status, a link peer device entry index, and a link peer port identifier. The port status indicates the port is disconnected, and the link peer device entry index is invalid.

[0139] The port identifier is used to indicate the port included in the device indicated by the device entry.

[0140] The port status indicates the disconnection status or connection status of the port included in the device indicated by the device entry.

[0141] The link peer device entry index is used to indicate the device indicated by the device entry corresponding to the link peer device entry index in the topology query response message.

[0142] The link peer port identifier is used to indicate the port included in the device indicated by the device entry corresponding to the link peer device entry index.

[0143] The format of the port entry is shown in Table 5, and the description of each field in the port entry is shown in Table 6.

[0144] Table 5

[0145] Table 6

[0146] Step 220: The second device receives the topology change request message sent by the first device.

[0147] The topology change request message includes a message header, a source address, a second topology change identifier (Change ID), a number of device entries (NoDE), and NoDE device entries. The message header includes a type field and a response field. The first value of the type field indicates a topology change, and the first value of the response field indicates a request message. The source address refers to the address of the device generating the topology change request message. The second topology change identifier indicates the order in which the topology change request messages are generated. For an explanation of the topology change request message, refer to the explanation of step 210 above.

[0148] Step 230: The second device sends a topology change response message to the first device.

[0149] The topology change response message includes a message header, which includes a type field and a response field. The first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

[0150] For example, a Type field value of 1 indicates that the message is a topology change message. A Response field value of 1 indicates that the message is a response message. That is, if a message contains both a Type field value of 1 and a Response field value of 1, it indicates that the message is a topology change response message.

[0151] The format of the topology change response message is shown in Table 7, and the description of each field in the topology change response message is shown in Table 8.

[0152] Table 7

[0153] Table 8

[0154] Step 240: The first device receives a topology change response message sent by the second device.

[0155] The topology change response message includes a message header, which includes a type field and a response field. The first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message. For an explanation of the topology change response message, refer to the explanation of step 230 above.

[0156] The second device compares the carried value of the topology change identifier with the recorded value and processes the topology change request message. For example, as shown in FIG3 , the following steps 250 to 290 are also included.

[0157] In some embodiments, the second device compares the first carried value of the topology change identifier with the recorded value; if one of the following conditions is met, the topology change identifier is considered continuous and the topology change is determined to be normal: the second device merges the device entry into the topology map to which the first device belongs (step 250).

[0158] For example, the difference between the first carried value and the recorded value is 1; or the first carried value is the initial value, and the recorded value is the maximum value in the value range of the topology change identifier. The second device modifies the information of the first device in the local topology map based on the topology change request message. The initial value can be 0, and the maximum value can be 255.

[0159] The second device forwards the topology change request message to other devices connected to the second device. For example, the second device forwards the topology change request message through a port in a ready state or a standby state.

[0160] In other embodiments, the second device compares the first carried value of the topology change identifier with the recorded value; if any of the following occurs, it is considered that a duplicate topology change request message has been received, and the topology change is abnormal: The second device discards the topology change request message (step 260).

[0161] For example, if the first carried value is equal to the recorded value; or the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is less than the threshold; or the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is greater than or equal to the threshold, the second device discards the topology change request message. The threshold can be 128.

[0162] In other embodiments, the second device compares the first carried value of the topology change identifier with the recorded value; if any of the following occurs, the topology change identifier is considered to have jumped, and the topology change is determined to be abnormal. The second device executes steps 270 to 280.

[0163] For example, if the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is greater than or equal to the threshold; or if the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is less than the threshold, a topology query request message is sent to the neighboring device.

[0164] Step 270: The second device sends a topology query request message to a neighboring device.

[0165] Step 280: The second device receives the topology query response message.

[0166] The device entry in the topology query response message includes a topology change identifier and a change type. The topology change identifier is used to indicate the topology change identifier of the device described by the device entry.

[0167] Step 290: When the second carried value of the topology change identifier is equal to the recorded value, the second device merges the device entries into the local topology map and overwrites the topology change identifier of the locally recorded device with the value of the topology change identifier in each device entry.

[0168] The values ​​of the change type are shown in Table 4. The change type value is 0, which means deleting the device; the change type value is 1, which means changing the device information; the change type value is 2, which means changing the port entry; and the change type value is 3, which means changing the device entry.

[0169] In this way, when a device receives a topology change request message, it uses the topology change flag to determine if packet loss has occurred. It then queries the upper-level device for the latest status, overwriting the local state, and continues broadcasting until the change flag is returned. If the packet is a duplicate, it is discarded and not broadcast again. This ability to detect packet loss prevents abnormal states and error propagation, improving information synchronization reliability. In multi-loop out-of-order scenarios, this prevents duplicate information processing, which can lead to state rollbacks or oscillations, and improves device stability.

[0170] The following describes the adapter update process.

[0171] When the state of the adapter changes, the device initiates an adapter update process. Figure 4 is a schematic diagram of an adapter update process provided by the present application. Here, the first device and the second device are connected through a port, and the first device and the third device are connected through a port. The first device initiates the adapter update process as an example. The second device initiates the adapter update process with reference to the first device, and will not be described in detail. For example, the first device may be device D shown in Figure 1, the second device may be device C shown in Figure 1, and the third device may be device A shown in Figure 1. As shown in Figure 4, the method includes the following steps.

[0172] Step 410: The first device sends an adapter change request message to the second device.

[0173] Before sending the adapter change request message, an adapter change request message is generated and the adapter change identifier is incremented by one.

[0174] The adapter change request message includes a message header, a source address, an adapter change identifier, a number of adapter entries NoAE, and NoAE adapter entries.

[0175] The source address is used to indicate the address of the device that generates the adapter change request message. For example, the source address is used to indicate the third device. The source address includes the source address high bit and the source address low bit.

[0176] The adapter change identifier is used to indicate the order in which adapter change request messages are generated.

[0177] The message header includes a type field and a response field. The second value of the type field is used to indicate an adapter change, and the first value of the response field is used to indicate a request message.

[0178] For example, a Type field value of 2 indicates that the message is an adapter change. A Response field value of 0 indicates that the message is a request message. That is, if a message contains a Type field value of 2 and a Response field value of 0, it indicates that the message is an adapter change request message.

[0179] The adapter change request message format is shown in Table 9, and the description of each field in the adapter change request message is shown in Table 10.

[0180] Table 9

[0181] Table 10

[0182] An adapter entry includes the change type, adapter type, and adapter number.

[0183] The format of the adapter entry is shown in Table 11, and the description of each field in the adapter entry is shown in Table 12.

[0184] Table 11

[0185] Table 12

[0186] Step 420: The second device receives the adapter change request message sent by the first device.

[0187] The adapter change request message includes a message header, a source address, an adapter change identifier, a number of adapter entries (NoAE), and NoAE adapter entries. The source address indicates the third device. The adapter change identifier indicates the order of adapter change request messages generated by the third device. The message header includes a type field and a response field. The second value of the type field indicates an adapter change, and the first value of the response field indicates a request message. For an explanation of the adapter change request message, refer to the description of step 410 above.

[0188] Step 430: The second device sends an adapter change response message to the first device.

[0189] The adapter change response message includes a message header, which includes a type field and a response field. The second value of the type field is used to indicate an adapter change, and the second value of the response field is used to indicate a response message.

[0190] The adapter change response message message format is shown in Table 13, and the description of each field in the adapter change response message message is shown in Table 14.

[0191] Table 13

[0192] Table 14

[0193] For example, a Type field value of 2 indicates that the message is an adapter change. A Response field value of 1 indicates that the message is a response message. That is, if a message contains a Type field value of 2 and a Response field value of 1, it indicates that the message is an adapter change response message.

[0194] Step 440: The first device receives the adapter change response message sent by the second device.

[0195] The adapter change response message includes a message header including a type field and a response field. The second value of the type field indicates an adapter change, and the second value of the response field indicates a response message. For an explanation of the adapter change response message, refer to the explanation of step 430 above.

[0196] The second device compares the value carried in the adapter change identifier with the recorded value and processes the adapter change request message.

[0197] In some embodiments, the second device compares the carried value of the adapter change identifier with the recorded value; if any of the following conditions are met, the adapter change identifier is considered continuous, and the adapter change is determined to be normal. The second device forwards the adapter change request message (step 450). The second device forwards the adapter change request message to other devices connected to the second device. For example, the second device forwards the adapter change request message via a port in a ready or standby state.

[0198] The second device merges the adapter entry into the local topology map (step 460). For example, the second device modifies the adapter information in the local topology map according to the adapter entry.

[0199] For example, the difference between the carried value and the recorded value is 1; or, the carried value is the initial value, and the recorded value is the maximum value of the adapter change identifier. The initial value can be 0, and the maximum value can be 255.

[0200] In other embodiments, the second device compares the value carried in the adapter change identifier with the recorded value; if any of the following occurs, it is considered that a duplicate adapter change request message has been received, and the adapter change is abnormal: The second device discards the adapter change request message (step 470).

[0201] For example, the carried value is equal to the recorded value; or, the carried value is less than the recorded value, and the difference between the recorded value and the carried value is less than the threshold; or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is greater than or equal to the threshold.

[0202] In other embodiments, the second device compares the carried value of the adapter change flag with the recorded value; if any of the following occurs, the adapter change flag is considered to have changed, and the adapter change is determined to be abnormal. The second device executes step 480 to obtain the adapter status from the third device indicated by the source address by reading the DCCD operation.

[0203] For example, the carried value is smaller than the recorded value, and the difference between the recorded value and the carried value is greater than or equal to the threshold; or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is smaller than the threshold.

[0204] The topology management method provided in the present application indicates the order between adapter change request messages according to the adapter change identifier in the adapter change request message, thereby enabling the device receiving the adapter change request message to perceive the order of the message, avoiding abnormal message status and error diffusion due to repeated transmission of the message or message loss, and improving the reliability of information synchronization.

[0205] It is understood that in order to implement the functions in the above embodiments, the device includes hardware structures and / or software modules that perform the corresponding functions. Those skilled in the art should easily appreciate that, in combination with the units and method steps of each example described in the embodiments disclosed in this application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or in a computer software-driven hardware manner depends on the specific application scenario and design constraints of the technical solution.

[0206] The topology management method provided by the present application is described in detail above in conjunction with Figures 1 to 5. The apparatus provided by the present application will be described below in conjunction with Figure 6. These apparatuses can be used to implement the functions of the apparatus in the above method embodiments, thereby also achieving the beneficial effects of the above method embodiments. In this embodiment, the apparatus can be the apparatus shown in Figure 1, or it can be a module (such as a chip) applied to the apparatus.

[0207] As shown in FIG. 6 , the topology management device 600 includes a receiving module 610 , a sending module 620 , a processing module 630 and a storage module 640 .

[0208] The topology management apparatus 600 is used to implement the function of the first device in the method embodiment shown in FIG. 2 .

[0209] The receiving module 610 is configured to receive a topology change response message. For example, the receiving module 610 is configured to execute step 240 in FIG. 2 .

[0210] The sending module 620 is configured to send a topology change request message. For example, the sending module 620 is configured to execute step 210 in FIG. 2 .

[0211] The topology management apparatus 600 is used to implement the function of the second device in the method embodiment shown in FIG. 2 .

[0212] The receiving module 610 is configured to receive a topology change request message. For example, the receiving module 610 is configured to execute step 220 in FIG. 2 .

[0213] The sending module 620 is configured to send a topology change response message. For example, the sending module 620 is configured to execute step 230 in FIG. 2 .

[0214] The topology management apparatus 600 is used to implement the function of the second device in the method embodiment shown in FIG. 3 .

[0215] Optionally, the sending module 620 is further configured to send a topology query request message. For example, the sending module 620 is configured to execute step 270 in FIG3 .

[0216] Optionally, the receiving module 610 is further configured to send a topology query response message. For example, the receiving module 610 is configured to execute step 280 in FIG3 .

[0217] Optionally, the processing module 630 is configured to merge the topology map to which the first device belongs according to the change type. For example, the processing module 630 is configured to execute step 250 in FIG3 .

[0218] Optionally, the processing module 630 is configured to discard the topology change request message. For example, the processing module 630 is configured to execute step 260 in FIG3 .

[0219] Optionally, the processing module 630 is configured to merge the local topology map according to the change type. For example, the processing module 630 is configured to execute step 290 in FIG. 3 .

[0220] The topology management apparatus 600 is used to implement the function of the first device in the method embodiment shown in FIG. 4 .

[0221] The receiving module 610 is configured to receive an adapter change response message. For example, the receiving module 610 is configured to execute step 440 in FIG. 4 .

[0222] The sending module 620 is configured to send an adapter change request message. For example, the sending module 620 is configured to execute step 410 in FIG. 4 .

[0223] Optionally, the sending module 620 is specifically configured to send an adapter change request message through a port in a ready state or a standby state.

[0224] The topology management apparatus 600 is used to implement the function of the second device in the method embodiment shown in FIG. 5 .

[0225] Optionally, the processing module 630 is configured to merge the local topology map according to the change type. For example, the processing module 630 is configured to execute step 460 in FIG5 .

[0226] Optionally, the processing module 630 is configured to discard the adapter change request message. For example, the processing module 630 is configured to execute step 470 in FIG5 .

[0227] Optionally, the sending module 620 is further configured to send an adapter change request message. For example, the sending module 620 is configured to execute step 450 in FIG5 .

[0228] The topology management apparatus 600 is used to implement the function of the second device in the method embodiment shown in FIG. 4 .

[0229] The receiving module 610 is configured to receive an adapter change request message. For example, the receiving module 610 is configured to execute step 420 in FIG. 4 .

[0230] The sending module 620 is configured to send an adapter change response message. For example, the sending module 620 is configured to execute step 430 in FIG. 4 .

[0231] The storage module 640 is used to store messages and router forwarding tables.

[0232] It should be understood that the topology management device 600 of the embodiment of the present application can be implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), wherein the PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. Alternatively, when the topology management method shown in FIG. 2 to FIG. 5 is implemented by software, the topology management device 600 and its modules can also be software modules.

[0233] According to the embodiment of the present application, the topology management device 600 can correspond to executing the method described in the embodiment of the present application, and the above-mentioned and other operations and / or functions of each unit in the topology management device 600 are respectively for implementing the corresponding processes of each method in Figures 2 to 5. For the sake of brevity, they are not repeated here.

[0234] FIG7 is a schematic diagram of the structure of an electronic device 700 provided in this application. As shown in FIG7 , electronic device 700 includes a processor 710, a bus 720, a memory 730, a communication interface 740, a memory 750 (also referred to as a main memory unit), and a router 760. Processor 710, memory 730, memory 750, communication interface 740, and router 760 are connected via bus 720.

[0235] It should be understood that in this embodiment, the processor 710 may be a CPU, but may also be other general-purpose processors, digital signal processors (DSP), ASICs, FPGAs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0236] The processor may also be a graphics processing unit (GPU), a neural network processing unit (NPU), a microprocessor, an ASIC, or one or more integrated circuits for controlling the execution of the program of the present application.

[0237] The communication interface 740 is used to implement communication between the electronic device 700 and an external device or component. In this application, when the electronic device 700 is used to implement the functions of the device shown in Figure 2 or Figure 7, the communication interface 740 is used to receive and send messages.

[0238] Router 760 is used to forward messages according to the router forwarding table.

[0239] Processor 710 is used to add a cyclically increasing change identification field in various change messages; when a change message is received, it is determined through the change identification field that if packet loss occurs, and the latest status is queried from the superior device to cover the local area until the change identification reply is continuous and then broadcast; when a change message is received, it is determined through the change identification field that if it is a duplicate packet, it is directly discarded and no longer broadcast.

[0240] The bus 720 may include a path for transmitting information between the above-mentioned components (such as the processor 710, the memory 750, and the storage 730). In addition to the data bus, the bus 720 may also include a power bus, a control bus, and a status signal bus. However, for the sake of clarity, various buses are labeled as bus 720 in the figure. The bus 720 may be a Peripheral Component Interconnect Express (PCIe) bus, an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus 720 can be divided into an address bus, a data bus, a control bus, etc.

[0241] As an example, electronic device 700 may include multiple processors. The processor may be a multi-core (multi-CPU) processor. The processor herein may refer to one or more devices, circuits, and / or computing units for processing data (e.g., computer program instructions).

[0242] It is worth noting that Figure 7 only takes the electronic device 700 including 1 processor 710 and 1 memory 730 as an example. Here, the processor 710 and the memory 730 are respectively used to indicate a type of device or equipment. In a specific embodiment, the number of each type of device or equipment can be determined according to business requirements.

[0243] Memory 750 may be a volatile memory pool or a nonvolatile memory pool, or may include both volatile and nonvolatile memory. Nonvolatile memory may be read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM). Memory 750 is used to store packets and router forwarding tables, among other things.

[0244] The memory 730 may correspond to a storage medium for storing information such as messages in the above method embodiments, for example, a disk such as a mechanical hard disk or a solid-state drive.

[0245] The electronic device 700 may be a general-purpose device or a dedicated device. For example, the electronic device 700 may be an edge device (e.g., a box carrying a chip with processing capabilities). Alternatively, the electronic device 700 may also be a server or other device with computing capabilities.

[0246] It should be understood that the electronic device 700 according to this embodiment may correspond to the topology management device 600 in this embodiment, and may correspond to executing the corresponding subject in any method in Figures 2 to 5, and the above-mentioned and other operations and / or functions of each module in the topology management device 600 are respectively for implementing the corresponding processes of each method in Figures 2 to 5. For the sake of brevity, they will not be repeated here.

[0247] The method steps in this embodiment can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in a computing device. Of course, the processor and storage medium can also exist as discrete components in a computing device.

[0248] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the process or function described in the embodiments of the present application is performed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device or other programmable device. The computer program or instruction can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program or instruction can be transmitted from one website, computer, server or data center to another website, computer, server or data center via wired or wireless means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, or a tape; it can also be an optical medium, such as a digital video disc (DVD); it can also be a semiconductor medium, such as a solid state drive (SSD). The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present application, and such modifications or substitutions should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A topology management method, characterized in that, the network includes a first device and a second device, the first device is connected to the second device through a port, and the method includes: sending a topology change request message to the second device, the topology change request message includes a message header and a topology change identifier, the message header includes a type field and a response field, the first value of the type field is used to indicate a topology change, the first value of the response field is used to indicate a request message, and the topology change identifier is used to indicate the order between generated topology change request messages; receiving a topology change response message sent by the second device, the topology change response message includes a message header, the message header includes a type field and a response field, the first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

2. The method according to claim 1, characterized in that, before sending the topology change request message, the method further includes: generating the topology change request message and incrementing the topology change identifier by one.

3. A topology management method, characterized in that, the network includes a first device and a second device, the first device is connected to the second device through a port, and the method includes: receiving a topology change request message sent by the first device, the topology change request message includes a message header and a topology change identifier, the message header includes a type field and a response field, the first value of the type field is used to indicate a topology change, the first value of the response field is used to indicate a request message, and the topology change identifier is used to indicate the order between topology change request messages generated by the first device; sending a topology change response message to the first device, the topology change response message includes a message header, the message header includes a type field and a response field, the first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

4. The method according to claim 3, characterized in that, the method further includes: comparing a first carried value of the topology change identifier with a recorded value; if one of the following conditions is met, it is considered that the topology change identifier is continuous and the topology change is determined to be normal; the difference between the first carried value and the recorded value is equal to 1; or, the first carried value is an initial value and the recorded value is the maximum value of the value range of the topology change identifier.

5. The method according to claim 4, characterized in that, the topology change request message further includes a source address and a device entry, and the source address is used to indicate the first device; the method further includes: incorporating the first device into the topology graph according to the device entry.

6. The method according to claim 5, characterized in that, the method further includes: forwarding the topology change request message.

7. The method according to claim 3, characterized in that, the method further includes: comparing a first carried value of the topology change identifier with a recorded value; if one of the following conditions is met, it is considered that a duplicate topology change request message has been received and the topology change is determined to be abnormal; the first carried value is equal to the recorded value; Alternatively, the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is less than the threshold value; Alternatively, the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is greater than or equal to the threshold value.

8. The method according to claim 7, wherein, the method further comprises: discarding the topology change request message.

9. The method according to claim 3, wherein, the method further comprises: comparing the first carried value of the topology change identifier with the recorded value; if any of the following conditions is met, it is considered that the topology change identifier has jumped, and the topology change is determined to be abnormal; the first carried value is less than the recorded value, and the difference between the recorded value and the first carried value is greater than or equal to the threshold value; Alternatively, the first carried value is greater than the recorded value, and the difference between the first carried value and the recorded value is less than the threshold value.

10. The method according to claim 9, wherein, the method further comprises: sending a topology query request message to a neighbor device, where the neighbor device is used to send the topology change request message; receiving a topology query response message, where the device entry in the topology query response message includes a topology change identifier and a change type, and the topology change identifier is used to indicate the topology change identifier of the device described by the device entry; when the second carried value of the topology change identifier is equal to the recorded value, incorporating the local topology map according to the device entry, and covering the value of the topology change identifier of the device recorded locally with the value of the topology change identifier in each device entry.

11. A topology management method, wherein, the network includes a first device, a second device, and a third device. The first device is connected to the second device through a port, and the first device is connected to the third device through a port. The method includes: sending an adapter change request message to the second device, where the adapter change request message includes a message header, a source address, an adapter change identifier, the number of adapter entries NoAE, and NoAE adapter entries. The source address is used to indicate the third device, the adapter change identifier is used to indicate the sequence of the adapter change request message generated by the third device, the message header includes a type field and a response field, the second value of the type field is used to indicate an adapter change, and the first value of the response field is used to indicate a request message; receiving an adapter change response message sent by the second device, where the adapter change response message includes a message header, and the message header includes a type field and a response field. The second value of the type field is used to indicate an adapter change, and the second value of the response field is used to indicate a response message.

12. The method according to claim 11, wherein, the source address includes a high-order source address and a low-order source address.

13. The method according to claim 12, wherein, the adapter entry includes a change type, an adapter type, and an adapter number.

14. The method according to any one of claims 11-13, wherein, before sending the adapter change request message, the method further comprises: Generate the adapter change request message and increment the adapter change identifier by one.

15. A topology management method, characterized in that the network includes a first device, a second device, and a third device, the first device is connected to the second device through a port, and the first device is connected to the third device through a port. The method includes: Receiving an adapter change request message sent by the first device. The adapter change request message includes a message header, a source address, an adapter change identifier, a number of adapter entries NoAE, and NoAE adapter entries. The source address is used to indicate the third device, the adapter change identifier is used to indicate the order of the adapter change request message generated by the third device. The message header includes a type field and a response field. The second value of the type field is used to indicate adapter change, and the first value of the response field is used to indicate a request message; Sending an adapter change response message to the first device. The adapter change response message includes a message header, and the message header includes a type field and a response field. The second value of the response field is used to indicate a response message.

16. The method according to claim 15, characterized in that the method further includes: Comparing the carried value of the adapter change identifier with the recorded value; If any of the following conditions is met, it is considered that the adapter change identifier is continuous and the adapter change is determined to be normal; The difference between the carried value and the recorded value is equal to 1; Or, the carried value is the initial value and the recorded value is the maximum value of the value range of the adapter change identifier.

17. The method according to claim 16, characterized in that the method further includes: Incorporating the adapter entries into the local topology map according to the adapter entries.

18. The method according to claim 17, characterized in that the method further includes: Forwarding the adapter change request message.

19. The method according to claim 15, characterized in that the method further includes: Comparing the carried value of the adapter change identifier with the recorded value; If any of the following conditions is met, it is considered that a duplicate adapter change request message has been received and the adapter change is determined to be abnormal; The carried value is equal to the recorded value; Or, the carried value is less than the recorded value, and the difference between the recorded value and the carried value is less than the threshold; Or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is greater than or equal to the threshold.

20. The method according to claim 19, characterized in that the method further includes: Discarding the adapter change request message.

21. The method according to claim 15, characterized in that comparing the carried value of the adapter change identifier with the recorded value; If any of the following conditions is met, it is considered that the adapter change identifier has a jump and the adapter change is determined to be abnormal; The carried value is less than the recorded value, and the difference between the recorded value and the carried value is greater than or equal to the threshold; Or, the carried value is greater than the recorded value, and the difference between the carried value and the recorded value is less than the threshold.

22. The method according to claim 21, characterized in that the method further includes: Obtain the adapter status from the third device indicated by the source address through the DCCD operation.

23. A transmission network characterized in that the transmission network includes a first device and a second device, the first device is connected to the second device through a port, and the first device and the second device are used to execute the method steps described in any one of the above claims 1-22.

24. The transmission network according to claim 23 characterized in that the network topology of the transmission network is a star topology or a mesh topology.

25. A topology management device characterized in that it includes: A sending module, configured to send a topology change request message to the second device. The topology change request message includes a message header and a topology change identifier. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change, the first value of the response field is used to indicate a request message, and the topology change identifier is used to indicate the order between the topology change request messages generated by the first device; A receiving module, configured to receive a topology change response message sent by the second device. The topology change response message includes a message header. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

26. A topology management device characterized in that it includes: A receiving module, configured to receive a topology change request message sent by the first device. The topology change request message includes a message header and a topology change identifier. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change, the first value of the response field is used to indicate a request message, and the topology change identifier is used to indicate the order between the topology change request messages generated by the first device; A sending module, configured to send a topology change response message to the first device. The topology change response message includes a message header. The message header includes a type field and a response field. The first value of the type field is used to indicate a topology change, and the second value of the response field is used to indicate a response message.

27. A topology management device characterized in that it includes: A sending module, configured to send an adapter change request message to the second device. The adapter change request message includes a message header, a source address, an adapter change identifier, the number of adapter entries NoAE, and NoAE adapter entries. The source address is used to indicate the third device. The adapter change identifier is used to indicate the order of the adapter change request messages generated by the third device. The message header includes a type field and a response field. The second value of the type field is used to indicate an adapter change, and the first value of the response field is used to indicate a request message; A receiving module, configured to receive an adapter change response message sent by the second device. The adapter change response message includes a message header. The message header includes a type field and a response field. The second value of the type field is used to indicate an adapter change, and the second value of the response field is used to indicate a response message.

28. A topology management device, characterized in that, comprising: a receiving module, configured to receive an adapter change request message sent by the first device, the adapter change request message including a message header, a source address, an adapter change identifier, the number of adapter entries NoAE, and NoAE adapter entries, the source address being used to indicate the third device, the adapter change identifier being used to indicate the order of the adapter change request message generated by the third device, the message header including a type field and a response field, a second value of the type field being used to indicate an adapter change, and a first value of the response field being used to indicate a request message; a sending module, configured to send an adapter change response message to the first device, the adapter change response message including a message header, the message header including a type field and a response field, a second value of the response field being used to indicate a response message.

29. An electronic device, characterized in that, the electronic device includes a memory and a processor, the memory being used to store a set of computer instructions; when the processor executes the set of computer instructions, the processor performs the operation steps of the method according to any one of claims 1-22 above.

30. A chip, characterized in that, including one or more interface circuits and one or more processors; the interface circuits are used to receive signals from the memory of the electronic device and send the signals to the processors, the signals including computer instructions stored in the memory; when the processors execute the computer instructions, the processors are caused to perform the operation steps of the method according to any one of claims 1-22.

31. A computer-readable storage medium, characterized in that, the computer-readable storage medium stores a computer program, when the computer program runs on a computer or a processor, the computer or the processor is caused to perform the operation steps of the method according to any one of claims 1-22.

Images