Topology management method, apparatus and device, and network

Abstract

Disclosed are a topology management method, apparatus and device, and a network. The method is applied to the field of communications. A first device is connected to a second device by means of a port. The first device is located in a first network, the second device is located in a second network, and the first network and the second network are independent. The method comprises: sending a topology query request message to a second device; and receiving a topology query response message from the second device. Two newly connected devices send the topology query request message to each other to discover the topological structure of the network where the opposite end device is located, and a combination operation is performed with a local topological graph to obtain a combined topological graph, that is, topology discovery can be completed by means of one topology query request, and the topological graph of the network where the device is located is updated in real time, which significantly improves the topological convergence speed.

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, multimedia devices are interconnected based on a tree-like topology. With the development of the Internet of Things (IoT), the number of multimedia devices is increasing. Devices with topology management capabilities must traverse every device in the network, performing point-by-point enumeration and topology management. This results in low topology management efficiency and slow topology convergence. Each device with topology management functionality must perform network-wide enumeration, resulting in repetitive operations and high congestion of topology management messages.

[0003] Summary of the Invention

[0004] The present application provides a topology management method, apparatus, device, and network, thereby improving the topology management convergence speed.

[0005] In a first aspect, a topology management method is provided, wherein a first device is connected to a second device via a port, the first device is located in a first network, the second device is located in a second network, and the first network and the second network are independent. The method comprises: sending a topology query request message to the second device, and receiving a topology query response message from the second device. The topology query request message comprises a message header, the message header comprises a type field and a response field, the first value of the type field is used to indicate a topology query, and the first value of the response field is used to indicate a request message. The topology query response message comprises a message header, a number of device entries NoDE, and NoDE device entries, the message header comprises a type field and a response field, the first value of the type field is used to indicate a topology query, the second value of the response field is used to indicate a response message, and the NoDE device entries are used to determine the connection relationship between NoDE devices and NoDE devices in the second network.

[0006] The topology management method provided in this application is that two newly connected devices send topology query request messages to each other, discover the topology structure of the network where the other device is located, and merge it with the local topology map to obtain a merged topology map. That is, topology discovery can be completed through a single topology query request, and the topology map of the network where the device is located can be updated in real time, significantly improving the topology convergence speed.

[0007] In one possible implementation, the 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 is used to indicate the topology change identifier of the device described by the device entry; the first value of the change type is used to indicate a changed device entry.

[0008] In another possible implementation, the device address includes a device address high bit and a device address low bit.

[0009] In another possible implementation, the port entry includes a port identifier, a port status, a link-opposite-end device entry index, and a link-opposite-end port identifier.

[0010] In another possible implementation, the port status indicates a port disconnection state, and the link peer device entry index is invalid.

[0011] In another possible implementation, the topology query response message includes a device entry of the second device.

[0012] In another possible implementation, the device entry of the second device does not include a port entry of a receiving port, and the receiving port is used by the second device to receive the topology query request message.

[0013] In another possible implementation, the topology query response message further includes device entries of devices connected to ports of the second device other than the port receiving the topology query request message.

[0014] In another possible implementation, sending a topology query request message to the second device includes: a port state machine of a port connected to the second device in the first device enters a ready state or a standby state, and sending a topology query request message to the second device.

[0015] In another possible implementation, sending a topology query request message to the second device includes: detecting that at least one of the following is satisfied before the first moment: all received topology change request messages are merged into the local topology map, and the topology change request message is forwarded; or, a topology query response message corresponding to a topology query request message issued by other ports has been received and merged into the local topology map, and the topology change request message generated by the topology query response message is forwarded; sending a topology query request message to the second device: wherein the first moment is equal to or earlier than the moment when the first device sends the topology query request message to the second device.

[0016] In another possible implementation, sending the topology query request message to the second device includes: when a topology map of the first network does not include the second device, sending the topology query request message to the second device.

[0017] In another possible implementation, the method also includes: receiving a topology query response message, finding that the topology query response message includes a device entry of a first device, receiving a first topology change request message through a port in the first device other than the receiving port of the topology query response message; and merging the device entry of the second device included in the first topology change request message into the topology map of the first network.

[0018] In another possible implementation, the method also includes: sending a second topology change request message to a device connected to the first device in the first network, the second topology change request message including a message header, a source address, a second topology change identifier, a number of device entries NoDE and NoDE device entries; the message header including a type field and a response field, the second value of the type field is used to indicate a topology change, and the first value of the response field is used to indicate a request message; the second topology change identifier is used to indicate the order in which the first device generates topology change request messages; the device entries include 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.

[0019] After the topology discovery process is completed between two newly connected devices, the device sends a topology change request message to other devices in the network where the device is located. Through a round of topology change request message broadcasting, the topology update of the network where the device is located can be completed, effectively avoiding topology management message congestion.

[0020] In another possible implementation, a loop exists between the first device and the second device, and the second topology change request message includes a device entry of the first device, where the device entry includes a port entry of a port in the first device connected to the second device.

[0021] In another possible implementation, there is no loop between the first device and the second device, and the second topology change request message includes the device entry of the first device and the device entry included in the topology query response message.

[0022] In another possible implementation, sending a second topology change request message to a device connected to the first device in the first network includes: sending a second topology change request message to a device connected to the first device in the first network through a port in the first device that is in a ready state or a standby state.

[0023] In another possible implementation, the ports of the first device and the second device are disconnected, and the method further includes: sending a third topology change request message to a device connected to the first device in the first network, the third topology change request message including a device entry of the first device, and the device entry of the first device including a port entry of the port in the first device connected to the second device.

[0024] In another possible implementation, a loop exists between the first device and the second device, the third topology change request message includes the device entry of the first device, the device entry of the first device further includes a change type, and the second value of the change type is used to indicate a changed port entry.

[0025] In another possible implementation, there is no loop between the first device and the second device, the third topology change request message includes a device entry of the second device and a device entry of a device connected to the second device in the second network, the device entry of the second device also includes a change type, and the third value of the change type is used to indicate deletion of the device.

[0026] In another possible implementation, the method also includes: sending a fourth topology change request message to a device connected to the first device in the first network, the fourth topology change request message including a device entry of the first device, the device entry of the first device including a change type and an adapter online identifier, and the fourth value of the change type is used to indicate the changed device information.

[0027] In another possible implementation, the method also includes: receiving a topology change response message, the topology 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 a topology change, and the second value of the response field is used to indicate a response message.

[0028] In another possible implementation, the method further includes: if no topology change response message is received within a time threshold, retransmitting the topology change request message.

[0029] In a second aspect, a topology management method is provided, wherein a first device is connected to a second device via a port, the first device is located in a first network, the second device is located in a second network, and the first network and the second network are independent. The method comprises: receiving a topology query request message sent by the first device, and sending a topology query response message to the first device. The topology query request message comprises a message header, the message header comprises a type field and a response field, the first value of the type field is used to indicate a topology query, and the first value of the response field is used to indicate a request message. The topology query response message comprises a message header, a number of device entries NoDE, and NoDE device entries, the message header comprises a type field and a response field, the first value of the type field is used to indicate a topology query, the second value of the response field is used to indicate a response message, and the NoDE device entries are used to determine the connection relationship between NoDE devices and NoDE devices in the second network.

[0030] The topology management method provided in this application is that two newly connected devices send topology query response messages to each other, so that the other device updates the topology structure of the network it is in and merges it with the local topology map to obtain a merged topology map. That is, topology discovery can be completed through a single topology query request, and the topology map of the network where the device is located is updated in real time, significantly improving the topology convergence speed.

[0031] In a possible implementation, sending a topology query response message to the first device includes: merging all previously received topology change request messages into a local topology map to obtain a second network, and sending a topology query response message to the first device.

[0032] In one possible implementation, the 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 is used to indicate the topology change identifier of the device described by the device entry; the first value of the change type is used to indicate a changed device entry.

[0033] In another possible implementation, the device address includes a device address high bit and a device address low bit.

[0034] In another possible implementation, the port entry includes a port identifier, a port status, a link-opposite-end device entry index, and a link-opposite-end port identifier.

[0035] In another possible implementation, the port status indicates a port disconnection state, and the link peer device entry index is invalid.

[0036] On the 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 and the third device are connected through a port, and the second device and the third device are connected through a port, and the method includes: when the first device is connected to the second device and there is a loop, the connection relationship between the first device and the second device is merged into the local topology map.

[0037] Since there is a loop between the first device and the second device, that is, the first device and the second device are in the same network, the topology of the network in which the first device and the second device are located is the same. After the first device is connected to the second device, the connection relationship between the first device and the second device is merged into the local topology, and the topology discovery can be completed. The topology of the network in which the device is located is updated in real time, which significantly improves the topology convergence speed.

[0038] In a fourth aspect, a topology management method is provided, comprising: receiving a topology change request message; merging device entries included in the topology change request message into a local topology map to obtain a merged topology map.

[0039] After the topology discovery process is completed between two newly connected devices, the devices can complete the topology update of the network in which they are located through topology change request messages, effectively avoiding topology management message congestion.

[0040] In a possible implementation manner, the method further includes: the local topology map includes a source device that sends the topology change request message, and forwarding the topology change request message through a port in a ready state or a standby state.

[0041] In another possible implementation, the method further includes: if the local topology map does not include a source device that sends the topology change request message, discarding the topology change request message.

[0042] In a fifth aspect, a transmission network is provided, which includes a first network and a second network, wherein the first device is located in the first network, the second device is located in the second network, the first network and the second network are independent, 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.

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

[0044] 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.

[0045] The sending module is used to send a topology query request message to the second device. The topology query request 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 query, and the first value of the response field is used to indicate a request message.

[0046] A receiving module is used to receive a topology query response message from a second device. The topology query response message includes a message header, the 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 is used to indicate a topology query. The second value of the response field is used to indicate a response message. The NoDE device entries are used to determine the connection relationship between NoDE devices and NoDE devices in the second network.

[0047] In one possible implementation, the 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 is used to indicate the topology change identifier of the device described by the device entry; the first value of the change type is used to indicate a changed device entry.

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

[0049] In another possible implementation, the port entry includes a port identifier, a port status, a link-opposite-end device entry index, and a link-opposite-end port identifier.

[0050] In another possible implementation, the port status indicates a port disconnection state, and the link peer device entry index is invalid.

[0051] In another possible implementation, the topology query response message includes a device entry of the second device.

[0052] In another possible implementation, the device entry of the second device does not include a port entry of a receiving port, and the receiving port is used by the second device to receive the topology query request message.

[0053] In another possible implementation, the topology query response message further includes device entries of devices connected to ports of the second device other than the port receiving the topology query request message.

[0054] In another possible implementation, when the sending module sends a topology query request message to the second device, it is specifically used to: the port state machine of the port connected to the second device in the first device enters the ready state or the standby state, and sends the topology query request message to the second device.

[0055] In another possible implementation, when the sending module sends a topology query request message to the second device, it is specifically used to: detect that at least one of the following is met before the first moment: all received topology change request messages are merged into the local topology map, and the topology change request message is forwarded; or, a topology query response message corresponding to the topology query request message issued by other ports has been received and merged into the local topology map, and the topology change request message generated by the topology query response message is forwarded; send a topology query request message to the second device: wherein the first moment is equal to or earlier than the moment when the first device sends the topology query request message to the second device.

[0056] In another possible implementation, when the sending module sends the topology query request message to the second device, it is specifically configured to: send the topology query request message to the second device if the topology map of the first network does not include the second device.

[0057] In another possible implementation, the receiving module is also used to receive a topology query response message, find that the topology query response message contains a device entry of the first device, receive a first topology change request message through a port in the first device other than the receiving port of the topology query response message; and merge the device entry of the second device contained in the first topology change request message into the topology map of the first network.

[0058] In another possible implementation, the sending module is further used to send a second topology change request message to a device connected to the first device in the first network, where the second topology change request message includes a message header, a source address, a second topology change identifier, the number of device entries NoDE, and NoDE device entries; the message header includes a type field and a response field, the second value of the type field is used to indicate a topology change, and the first value of the response field is used to indicate a request message; the second topology change identifier is used to indicate the order in which the first device generates topology change request messages; the device entries include a device address, a first topology change identifier, a change type, the number of port entries NoPE, an adapter online identifier, and NoPE port entries.

[0059] In another possible implementation, a loop exists between the first device and the second device, and the second topology change request message includes a device entry of the first device, where the device entry includes a port entry of a port in the first device connected to the second device.

[0060] In another possible implementation, there is no loop between the first device and the second device, and the second topology change request message includes the device entry of the first device and the device entry included in the topology query response message.

[0061] In another possible implementation, when the sending module sends a second topology change request message to a device connected to the first device in the first network, it is specifically used to: send a second topology change request message to a device connected to the first device in the first network through a port in the first device that is in a ready state or a standby state.

[0062] In another possible implementation, the ports of the first device and the second device are disconnected, and the sending module is further used to send a third topology change request message to the device connected to the first device in the first network, where the third topology change request message includes the device entry of the first device, and the device entry of the first device includes the port entry of the port in the first device connected to the second device.

[0063] In another possible implementation, a loop exists between the first device and the second device, the third topology change request message includes the device entry of the first device, the device entry of the first device further includes a change type, and the second value of the change type is used to indicate a changed port entry.

[0064] In another possible implementation, there is no loop between the first device and the second device, the third topology change request message includes a device entry of the second device and a device entry of a device connected to the second device in the second network, the device entry of the second device also includes a change type, and the third value of the change type is used to indicate deletion of the device.

[0065] In another possible implementation, the sending module is also used to send a fourth topology change request message to a device connected to the first device in the first network, the fourth topology change request message including a device entry of the first device, the device entry of the first device including a change type and an adapter online identifier, and the fourth value of the change type is used to indicate the changed device information.

[0066] In another possible implementation, the sending module is also used to receive a topology change response message, which 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 a topology change, and the second value of the response field is used to indicate a response message.

[0067] In another possible implementation, the sending module is further configured to retransmit the topology change request message if no topology change response message is received within a time threshold.

[0068] 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.

[0069] The receiving module is used to receive a topology query request message sent by the first device. The topology query request 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 query. The first value of the response field is used to indicate a request message.

[0070] A sending module is used to send a topology query response message to the first device. The topology query response message includes a message header, the 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 is used to indicate a topology query, the second value of the response field is used to indicate a response message, and the NoDE device entries are used to determine the connection relationship between NoDE devices and NoDE devices in the second network.

[0071] In an eighth aspect, a topology management device is provided, comprising modules for executing the steps of the method of 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. The receiving module is configured to receive a topology change request message; the processing module is configured to merge the device entries contained in the topology change request message into a local topology map, thereby obtaining a merged topology map.

[0072] In a possible implementation, the apparatus further includes a sending module, which is configured to forward the topology change request message through a port in a ready state or a standby state when the local topology map includes a source device that sends the topology change request message.

[0073] In another possible implementation, the processing module is further configured to discard the topology change request message if the local topology map does not include the source device that sends the topology change request message.

[0074] In the ninth 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.

[0075] In the tenth 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.

[0076] In the eleventh 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.

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

[0078] 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

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

[0080] FIG2 is a schematic diagram of a topology discovery process provided by this application;

[0081] FIG3 is a schematic diagram of another network topology provided by the present application;

[0082] FIG4 is a schematic diagram of another network topology provided by the present application;

[0083] FIG5 is a schematic diagram of another topology discovery process provided by the present application;

[0084] FIG6 is a schematic diagram of another path topology discovery process provided by the present application;

[0085] FIG7 is a schematic diagram of a topology update process provided by the present application;

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

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

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

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

[0090] 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.

[0091] 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.

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

[0093] 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.

[0094] 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.

[0095] 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 single 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] To coordinate topology updates with the management adapters of other devices on the network, a device should send notification messages to all other ports when the status of any of its ports changes, informing the entire network of the latest port status. Management adapters use topology query request and topology query response messages to discover topology. Management adapters use topology change request and topology change response messages to update topology.

[0100] The following describes the topology discovery process.

[0101] Each device in the network constructs a local topology map of its own network and keeps it updated in real time. Even if two devices are on separate networks, when they connect, their networks become connected, forming a new, larger network. Each connected device is responsible for discovering the network topology of the other device's network and merging it with its local topology map to create a combined topology.

[0102] For example, as shown in Figure 1, Network 1 and Network 2 were originally two independent, disconnected networks. Network 1 includes Device A, and Network 2 includes Device E. In this example, Network 1 and Network 2 are connected by connecting Device A and Device E. After the port state machines of Device A and Device E transition to the Ready or Standby state through a series of transitions, the topology discovery process begins.

[0103] First, the local device constructs a topology query request message and sends it to the peer device via the port connecting the two devices. Then, after receiving the topology query response message from the peer device, the local device determines all newly connected devices and their connection relationships based on the device entries carried in the topology query response message and the port entries in each device entry. Finally, the local device calculates the merged topology map, i.e., it modifies the local topology map based on the topology query response message. This application does not specify the algorithm used for topology calculations.

[0104] It should be noted that before executing the topology discovery process, the device completes the following two steps to ensure that the local topology map is up to date.

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

[0106] 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 is completed.

[0107] After receiving the topology query request message, the peer device first merges all previously received topology change request messages into the local topology map and forwards the topology change request message. It then constructs a topology query response message corresponding to the topology query request message and feeds back the topology query response message. The topology query response message contains the device entry of the peer device and the device entries of all devices that can be connected to other ports except the receiving port of the topology query request message. The topology query response message does not contain the port entry of the receiving port. Whether the topology query response message carries the port entry of the port in the disconnected state is not mandatory in this application.

[0108] It should be noted that since the peer device does not carry the port entry for receiving the topology query request message when constructing the topology query response message, the local device cannot obtain which port the local device is connected to through the topology query response message replied by the peer device. The local device should record the port identifier (PortID) in the capability negotiation request message sent by the peer device, and after receiving this topology query response message, follow the other device entries and merge the peer device into the local topology map.

[0109] Figure 2 is a schematic diagram of a topology discovery process provided by the present application. Here, the first device is located in the first network, the second device is located in the second network, the first network and the second network are independent, the first device and the second device are connected through a port, and the first network and the second network are merged into a larger network. Take the first device and the second device initiating the topology discovery process as an example. For example, the first device can be device A shown in Figure 1, and the second device can be device E shown in Figure 1. Alternatively, the first device can be device E shown in Figure 1, and the second device can be device A shown in Figure 1. As shown in Figure 2, the method includes the following steps.

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

[0111] The topology query request 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 query, and the first value of the response field is used to indicate a request message.

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

[0113] Table 1

[0114] Table 2

[0115] A value of 0 in the Type field indicates that the message is a topology query message. A value of 0 in the Response field indicates that the message is a request message. That is, if both the Type field and the Response field in a message are 0, the message is a topology query request message.

[0116] In some embodiments, a port state machine of a port connected to a second device on a first device enters a ready state or a standby state, and a topology query request message is sent to the second device. For example, after the first device and the second device are connected via a port, the port state machine of the port of the first device connected to the second device enters a ready state or a standby state, and the first device sends a topology query request message to the second device.

[0117] In other embodiments, the first device sends a topology query request message to the second device after detecting that at least one of the following conditions is satisfied before a first time point, wherein the first time point is equal to or earlier than the time point when the first device sends the topology query request message to the second device.

[0118] All topology change request messages received by the first device are merged into the local topology map, and the topology change request message forwarding is completed. Alternatively, the first device has received a topology query response message corresponding to a topology query request message sent by another port, merged it into the local topology map, and the topology change request message generated by the topology query response message is forwarded.

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

[0120] The topology query request 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 query, and the first value of the response field is used to indicate a request message. For an explanation of the topology query request message, refer to the explanation of step 210 above.

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

[0122] The topology query response message includes a message header, the 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 query, and the second value of the response field indicates a response message. The NoDE device entries are used to determine the connection relationships between NoDE devices and NoDE devices in the second network.

[0123] The format of the topology query response message is shown in Table 3, and the description of each field in the topology query response message is shown in Table 4.

[0124] Table 3

[0125] Table 4

[0126] A Type field value of 0 indicates that the message is a topology query. A Response field value of 1 indicates that the message is a response message. That is, if the Type field value is 0 and the Response field value is 1, the message is a topology query response message.

[0127] 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.

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

[0129] Table 5

[0130] Table 6

[0131] 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.

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

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

[0134] 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.

[0135] 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.

[0136] The format of the port entry is shown in Table 7, and the description of each field in the port entry is shown in Table 8.

[0137] Table 7

[0138] Table 8

[0139] It should be noted that the topology query response message includes the device entry of the second device and the device entries of the devices connected to the ports of the second device other than the receiving port of the topology query request message. The device entry of the second device does not include the port entry of the receiving port, which is used by the second device to receive the topology query request message.

[0140] In addition, the second device merges all previously received topology change request messages into the local topology map to obtain a second network, and sends a topology query response message to the first device.

[0141] Step 240: The first device receives a topology query response message from the second device.

[0142] The topology query response message includes a message header, 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 query, the second value of the response field indicates a response message, and the NoDE device entries are used to determine the connection relationships between the NoDE devices and the NoDE devices in the second network. For an explanation of the topology query response message, refer to the description of step 230 above.

[0143] The topology management method provided in this application is that two newly connected devices send topology query request messages to each other, discover the topology structure of the network where the other device is located, and merge it with the local topology map to obtain a merged topology map. That is, topology discovery can be completed through a single topology query request, and the topology map of the network where the device is located can be updated in real time, significantly improving the topology convergence speed.

[0144] Network topologies may contain loops or parallel paths. The management adapter is responsible for identifying loops and parallel paths using device addresses and forwarding lists. When multiple paths exist to access a device, the management adapter selects the path to be taken based on service requirements. For example, Figure 3 (a) shows a network topology diagram without loops, while Figure 3 (b) shows a network topology diagram with loops.

[0145] The management adapter uses topology discovery and updates to obtain the latest status information and connectivity for each device on the network. This stored connectivity information allows it to maintain a topology map rooted in itself. After discovering a device, the management adapter uses forwarding lists and device addresses to identify loops or parallel links. If a target address has two or more forwarding lists, this indicates that multiple paths exist from this device to the target device, indicating a loop.

[0146] The local device first determines whether the peer device exists in the local topology map, and then determines whether to send a topology query request message to the peer device to perform the topology discovery process.

[0147] If the peer device already exists in the local topology, the local device and the peer device were already connected before the connection. This means that one or more parallel paths exist between the two devices, creating a loop. In this case, the local device does not need to send a topology query request message and can simply merge the newly connected link into the local topology.

[0148] For example, as shown in Figure 4, before devices A and E connect, Network 1 and Network 2 are already connected through devices B and G. Therefore, before devices A and E connect, their local topology maps already include Network 1 and Network 2. After connecting, devices A and E no longer need to query the other end's topology map via a topology query request message. Devices A and E each merge the connection relationship between them into their local topology maps.

[0149] If the peer device does not exist in the local topology map, a topology query request message is sent to the peer device to perform a topology discovery process.

[0150] For example, as shown in Figure 5, the difference from Figure 2 is that the first device sends a topology query request message to the second device, the first device executes step 250, the first device determines whether the topology map of the first network includes the second device, and the first device determines that the topology map of the first network does not include the second device, then executes step 210, and the first device sends a topology query request message to the second device.

[0151] In other embodiments, if the opposite device does not exist in the local topology map, but after the local device receives the topology query response message, the local device finds that its own device entry already exists in the device entry carried by the topology query response message, which means that the local device already exists in the topology map of the opposite device. If the local device cannot determine which side's topology map is lagging behind, that is, it cannot determine whether there is actually a loop between the two devices. In this case, the local device waits for the topology change request message carrying the opposite device entry received through other ports to merge the opposite device into the local topology map. If the topology map of the local device lags behind the topology map of the opposite device, that is, there is a loop, the local device can receive the expected topology change request message, and then merge the newly connected link into the topology map according to the rules of the loop.

[0152] If there is no loop, that is, the topology map of the other device lags behind the topology map of the local device, the local device will not receive the expected topology change request message. After a timeout (e.g., tXXX (1 second)), the local device will retry the topology query request message. It is expected that after the above waiting period, the other device will have completed the topology update. After receiving the retried topology query response message, if the local device finds that the device entry of the local device no longer exists in the topology map of the other device, it will complete the topology discovery process according to the rules of no loop. If it still exists in the topology map of the other device, it will start a new waiting process according to the above process.

[0153] For example, as shown in Figure 6, the difference from Figure 2 is that when the first device receives a topology query response message and finds that the topology query response message contains the device entry of the first device, step 260 is executed to receive a topology change request message through a port in the first device other than the receiving port of the topology query response message; and the device entry of the second device contained in the topology change request message is merged into the topology map of the first network.

[0154] The following describes the topology update process.

[0155] When the local topology changes due to events such as connection or disconnection between devices or adapter status changes, the device initiates a topology update process.

[0156] When two devices connect, their networks are interconnected, and the two connected devices complete the topology discovery process. However, other devices in the two networks are still unaware of this connection, and their locally maintained topology maps must be updated. The connected devices then use Topology Change Request and Topology Change Response messages to complete the topology update process.

[0157] As shown in Figure 1, there is no loop between device A and device E. After completing the topology discovery process according to the above topology discovery solution, devices A and E initiate a topology update process. They first construct a topology change request message. The device entries in this message include the device entry for the local device, including the newly connected port entry. The topology change request message also includes all device entries carried in the topology query response message received during the topology discovery process. The local device then sends the request through all other ports in the ready or standby state.

[0158] As shown in Figure 4, there is a loop between device A and device E. After completing the topology discovery process, devices A and E also generate a topology change request message and forward it according to the topology update process described above. The difference is that this topology change request message only needs to indicate the change in the current connection and does not include any new device entries. In other words, the topology change request message only contains the device entry for the local device, which must include the port entry for the new connection. The topology change request message does not need to include all the device entries carried in the topology query response message.

[0159] The two topology update scenarios described above are both subsequent processes of the topology discovery process triggered by port connections.

[0160] When a port is disconnected or the adapter type changes, the device that has changed must also perform a topology update after completing the local topology update. That is, the device generates a corresponding topology change request message and forwards it to all ports in the ready or standby state.

[0161] If a port is disconnected, the topology change request message includes the local device entry, with the "CT" field set to 2, indicating the disconnected port entry. If there is no loop between the local device and the disconnected peer device, the topology change request message also includes the device entries for the disconnected peer device and all connected devices behind it, with the "CT" field set to 0.

[0162] If the adapter status changes, the topology change request message contains its own device entry, the "CT" field is 1, "NoPE" is 0 and does not carry any port entry, and the "AOF" field is filled according to the current latest status.

[0163] The device that receives the topology change request message first constructs a topology change response message and replies to the topology change response message through the receiving port, then merges the device entries carried by this topology change request message into the local topology map, that is, modifies the local topology map according to the device entries contained in the topology change request message, and finally sends this topology change request message through other ports that are in ready state or standby state, that is, the local topology map includes the source device that sent the topology change request message.

[0164] However, if the source device of this topology change request message does not exist in the local topology map, the message will be directly discarded after replying the topology change response message, and the merging and forwarding process will no longer be performed.

[0165] It should be noted that after the topology change response message is forwarded, subsequent devices that receive this topology change request message will also process and forward it according to the above process, similar to the broadcast mechanism, until all other devices in the network have received this topology change request message and all devices in the entire network have completed the topology map update.

[0166] Figure 7 is a schematic diagram of a topology update process provided by the present application. Here, the first device and the second device are connected through a port, so that the first network where the first device is located and the second network where the second device is located are connected, and the first network and the second network are merged into a larger network. The first device initiates the topology update process as an example. The second device initiates the topology update process with reference to the first device and is not described in detail. For example, the first device may be device A shown in Figure 1, and the second device may be device E shown in Figure 1. Alternatively, the first device may be device E shown in Figure 1, and the second device may be device A shown in Figure 1. As shown in Figure 7, the method includes the following steps.

[0167] Step 710: The first device sends a topology change request message to a device connected to the first device in the first network.

[0168] A topology change request message includes a message header, a source address, a second topology change identifier, a number of device entries (NoDE), and NoDE device entries. The message header includes a type field and a response field. The second 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 the first device generates the topology change request message.

[0169] 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.

[0170] The device entry includes the device address, the first topology change identifier, the change type, the number of port entries NoPE, the adapter online identifier, and the NoPE port entries. For explanations of the device entry, please refer to the explanations of Table 5 and Table 6 above.

[0171] It should be noted that a loop exists between the first device and the second device. The topology change request message includes a device entry of the first device. The device entry includes a port entry of a port in the first device connected to the second device.

[0172] There is no loop between the first device and the second device, and the topology change request message includes the device entry of the first device and the device entry included in the topology query response message.

[0173] In addition, the first device sends a topology change request message to a device connected to the first device in the first network through a port in the ready state or the standby state of the first device.

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

[0175] Table 9

[0176] Table 10

[0177] Step 720: The first device receives a topology change response message sent by a device connected to the first device in the first network.

[0178] The first device sends a topology change request message to a device connected to the first device in the first network, and the device connected to the first device sends a topology change response message. For an explanation of the topology change request message, refer to the explanation of step 710 above.

[0179] The topology 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 a topology change, and the second value of the response field is used to indicate a response message.

[0180] The format of the topology change response message is shown in Table 11, and the description of each field in the topology change response message is shown in Table 12.

[0181] Table 11

[0182] Table 12

[0183] A value of 1 in the Type field indicates that the message is a topology change message. A value of 1 in the Response field indicates that the message is a response message. That is, if both the Type field and the Response field in a message are 1, the message is a topology change response message.

[0184] The device connected to the first device may further perform the following steps, which will be described using the third device as an example.

[0185] Step 730: The third device receives a topology change request message.

[0186] The third device merges the device entries included in the topology change request message into the local topology map to obtain a merged topology map.

[0187] In some embodiments, the local topology map includes a source device that sends a topology change request message, and the topology change request message is forwarded through a port in a ready state or a standby state.

[0188] In other embodiments, the local topology map does not include the source device that sends the topology change request message, and step 740 is executed to discard the topology change request message.

[0189] After the topology discovery process is completed between two newly connected devices, the device sends a topology change request message to other devices in the network where the device is located. Through a round of topology change request message broadcasting, the topology update of the network where the device is located can be completed, effectively avoiding topology management message congestion.

[0190] In other embodiments, the ports of the first device and the second device are disconnected, and the first device sends a topology change request message to the device connected to the first device in the first network, where the topology change request message includes the device entry of the first device, and the device entry of the first device includes the port entry of the port in the first device connected to the second device.

[0191] Optionally, a loop exists between the first device and the second device. The topology change request message includes the device entry for the first device. The device entry for the first device also includes a change type. The second value of the change type indicates a change in the port entry. As shown in the Change Type field in Table 6, the value of the Change Type is 2, indicating a change in the port entry.

[0192] Optionally, if no loop exists between the first device and the second device, the topology change request message includes a device entry for the second device and device entries for devices connected to the second device in the second network. The device entry for the second device also includes a change type, where a third value of the change type indicates device deletion. As shown in the Change Type field in Table 6, a value of 0 for the Change Type indicates device deletion.

[0193] In other embodiments, a first device sends a topology change request message to a device connected to the first device in a first network. The topology change request message includes a device entry for the first device. The device entry for the first device includes a change type and an adapter online identifier. The fourth value of the change type indicates that device information has been changed. As shown in the change type field in Table 6, a value of 1 for the change type indicates that device information has been changed.

[0194] In other embodiments, the topology change request message is sent to every device in the network in a broadcast-like manner, without an end-to-end reply response message. To ensure reliability, the topology change request message needs to be retransmitted at the link level in the event of an error. If the topology change request message times out (the timeout period should be shorter than that of the end-to-end message) without receiving a topology change response request, the topology change request message should be retransmitted. Optionally, a maximum of five retries may be performed; if all five times fail, the topology change request message is considered to have failed.

[0195] Topology Change Request messages can be sent adaptively over high-speed or low-speed links, which have different transmission delays. To prevent Topology Change Request messages from being out of order, if a port has already sent a Topology Change Request message but has not received a corresponding Topology Change Response message, no further Topology Change Request messages can be sent to that port. Instead, the port queues and waits for the previous Topology Change Request message to complete or fail.

[0196] 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.

[0197] The topology management method provided by the present application is described in detail above in conjunction with Figures 1 to 7. The apparatus provided by the present application will be described below in conjunction with Figure 8. 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.

[0198] As shown in FIG8 , the topology management device 800 includes a receiving module 810 , a sending module 820 and a storage module 830 .

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

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

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

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

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

[0204] The sending module 820 is configured to send a topology query response message. For example, the sending module 820 is configured to execute step 230 in FIG2 .

[0205] The topology management apparatus 800 is used to implement the function of the first device in the method embodiment shown in FIG. 7 .

[0206] The receiving module 810 is configured to receive a topology change response message. For example, the receiving module 810 is configured to execute step 720 in FIG. 7 .

[0207] The sending module 820 is configured to send a topology change request message. For example, the sending module 820 is configured to execute step 710 in FIG. 7 .

[0208] Optionally, the sending module 820 is specifically configured to send a topology query request message or a topology change request message through a port in a ready state or a standby state.

[0209] The topology management apparatus 800 is used to implement the function of the first device in the method embodiment shown in FIG. 6 .

[0210] Optionally, the sending module 820 is specifically configured to send a topology query request message to the second device if the topology map for the first network does not include the second device. For example, the sending module 820 is configured to execute step 250 in FIG6 .

[0211] Optionally, the sending module 820 is specifically configured to receive a topology change request message via a port of the first device other than the port for receiving the topology query response message, and merge the device entry of the second device included in the topology change request message into the topology map of the first network. For example, the sending module 820 is configured to execute step 260 in FIG. 6 .

[0212] The storage module 830 is used to store messages and router forwarding tables.

[0213] It should be understood that the topology management device 800 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 or FIG. 7 is implemented by software, the topology management device 800 and its modules can also be software modules.

[0214] According to the embodiment of the present application, the topology management device 800 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 800 are respectively for implementing the corresponding processes of each method in Figure 2 or Figure 7. For the sake of brevity, they are not repeated here.

[0215] Figure 9 is a schematic diagram of the structure of an electronic device 900 provided in this application. As shown in Figure 9, electronic device 900 includes a processor 910, a bus 920, a memory 930, a communication interface 940, a memory 950 (also referred to as a main memory unit), and a router 960. Processor 910, memory 930, memory 950, communication interface 940, and router 960 are connected via bus 920.

[0216] It should be understood that in this embodiment, the processor 910 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.

[0217] 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.

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

[0219] Router 960 is used to forward messages according to the router forwarding table.

[0220] The processor 910 is configured to complete topology discovery between two newly connected devices through a single topology query request, thereby significantly improving topology convergence speed.

[0221] The processor 910 is configured to complete the topology update of the entire network by broadcasting a round of topology change request messages, thereby effectively avoiding topology management message congestion.

[0222] The bus 920 may include a path for transmitting information between the above-mentioned components (such as the processor 910, the memory 950, and the storage 930). In addition to the data bus, the bus 920 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 920 in the figure. The bus 920 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 920 can be divided into an address bus, a data bus, a control bus, etc.

[0223] As an example, electronic device 900 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).

[0224] It is worth noting that Figure 9 only takes the electronic device 900 including 1 processor 910 and 1 memory 930 as an example. Here, the processor 910 and the memory 930 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.

[0225] Memory 950 may be a volatile memory pool or a non-volatile memory pool, or may include both volatile and non-volatile memory. Non-volatile 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 RAM (DR RAM). Memory 950 is used to store packets and router forwarding tables, among other things.

[0226] The memory 930 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.

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

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

[0229] 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.

[0230] 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, a first device and a second device are connected through ports, the first device is in a first network, the second device is in a second network, and the first network and the second network are independent. The method includes: sending a topology query request message to the second device, the topology query request message including a message header, the message header including a type field and a response field, a first value of the type field being used to indicate a topology query, and a first value of the response field being used to indicate a request message; receiving a topology query response message from the second device, the topology query response message including a message header, a number of device entries NoDE, and NoDE device entries. The message header includes the type field and the response field, a first value of the type field being used to indicate a topology query, a second value of the response field being used to indicate a response message, and the NoDE device entries being used to determine the connection relationship between the NoDE devices in the second network and the NoDE devices.

2. The method according to claim 1, characterized in that, the 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 is used to indicate the topology change identifier of the device described by the device entry; a first value of the change type is used to indicate a changed device entry.

3. The method according to claim 1 or 2, characterized in that, the device address includes a high device address and a low device address.

4. The method according to claim 2 or 3, characterized in that, the port entry includes a port identifier, a port status, a link peer device entry index, and a link peer port identifier.

5. The method according to claim 4, characterized in that, the port status indicates a port disconnection status, and the link peer device entry index is invalid.

6. The method according to any one of claims 1-5, characterized in that, the topology query response message includes the device entry of the second device.

7. The method according to claim 6, characterized in that, the device entry of the second device does not include the port entry of the receiving port, and the receiving port is used for the second device to receive the topology query request message.

8. The method according to claim 6 or 7, characterized in that, the topology query response message further includes the device entry of the device connected to the port of the second device other than the receiving port of the topology query request message.

9. The method according to any one of claims 1-8, characterized in that, sending a topology query request message to the second device includes: the port state machine of the port of the first device connected to the second device enters a ready state or a standby state, and sends a topology query request message to the second device.

10. The method according to any one of claims 1-9, characterized in that, sending a topology query request message to the second device includes: detecting that at least one of the following is satisfied before a first moment: All received topology change request messages are incorporated into the local topology map, and the forwarding of the topology change request messages is completed; or, a topology query response message corresponding to a topology query request message sent from another port has been received and incorporated into the local topology map, and the forwarding of the topology change request message generated from the topology query response message is completed; Sending the topology query request message to the second device: wherein, the first moment is equal to or earlier than the moment when the first device sends the topology query request message to the second device.

11. The method according to any one of claims 1-10, characterized in that, Sending a topology query request message to the second device includes: When the topology map of the first network does not include the second device, sending the topology query request message to the second device.

12. The method according to any one of claims 1-10, characterized in that, The method further includes: Upon receiving the topology query response message and finding that the topology query response message contains the device entry of the first device, receiving a first topology change request message through a port of the first device other than the port for receiving the topology query response message; Incorporating the device entry of the second device included in the first topology change request message into the topology map of the first network.

13. The method according to any one of claims 1-12, characterized in that, The method further includes: Sending a second topology change request message to a device connected to the first device in the first network, the second topology change request message including a message header, a source address, a second topology change identifier, a number of device entries NoDE, and NoDE device entries; The message header includes a type field and a response field, a second value of the type field is used to indicate a topology change, and a first value of the response field is used to indicate a request message; The second topology change identifier is used to indicate the order between topology change request messages generated by the first device; The 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.

14. The method according to claim 13, characterized in that, When there is a loop between the first device and the second device, the second topology change request message includes the device entry of the first device, and the device entry includes the port entry of the port of the first device connected to the second device.

15. The method according to claim 13, characterized in that, When there is no loop between the first device and the second device, the second topology change request message includes the device entry of the first device and the device entry included in the topology query response message.

16. The method according to any one of claims 13-15, characterized in that, Sending a second topology change request message to a device connected to the first device in the first network includes: Sending a second topology change request message to a device connected to the first device in the first network through a port of the first device in a ready state or a standby state.

17. The method according to any one of claims 1-16, wherein, the ports of the first device and the second device are disconnected, and the method further includes: sending a third topology change request message to the devices connected to the first device in the first network, the third topology change request message including the device entry of the first device, and the device entry of the first device including the port entry of the port of the first device connected to the second device.

18. The method according to claim 17, wherein, there is a loop between the first device and the second device, the third topology change request message includes the device entry of the first device, and the device entry of the first device further includes a change type, and the second value of the change type is used to indicate a changed port entry.

19. The method according to claim 17, wherein, there is no loop between the first device and the second device, the third topology change request message includes the device entry of the second device and the device entries of the devices connected to the second device in the second network, the device entry of the second device further includes a change type, and the third value of the change type is used to indicate deleting a device.

20. The method according to any one of claims 1-16, wherein, the method further includes: sending a fourth topology change request message to the devices connected to the first device in the first network, the fourth topology change request message including the device entry of the first device, and the device entry of the first device including a change type and an adapter online identifier, and the fourth value of the change type is used to indicate changing device information.

21. The method according to any one of claims 13-20, wherein, the method further includes: receiving a topology change response message, the topology change response message including a message header, the message header including a type field and a response field, the second value of the type field being used to indicate a topology change, and the second value of the response field being used to indicate a response message.

22. The method according to claim 21, wherein, the method further includes: if the topology change response message is not received after exceeding a time threshold, retransmitting the topology change request message.

23. A topology management method, wherein, a first device and a second device are connected through a port, the first device is in a first network, the second device is in a second network, and the first network and the second network are independent, and the method includes: receiving a topology query request message sent by the first device, the topology query request message including a message header, the message header including a type field and a response field, the first value of the type field being used to indicate a topology query, and the first value of the response field being used to indicate a request message; Send a topology query response message to the first device. The topology query response message includes a message header, the number of device entries NoDE, and NoDE device entries. The message header includes the type field and the response field. The first value of the type field is used to indicate a topology query, and the second value of the response field is used to indicate a response message. The NoDE device entries are used to determine the connection relationships and the NoDE devices among the NoDE devices of the second network.

24. The method according to claim 23, wherein, the device entry includes a device address, a first topology change identifier, a change type, the number of port entries NoPE, an adapter online identifier, and NoPE port entries; the first topology change identifier is used to indicate the topology change identifier of the device described by the device entry; the first value of the change type is used to indicate a changed device entry.

25. The method according to claim 23 or 24, wherein, the device address includes a high-order device address and a low-order device address.

26. The method according to claim 24 or 25, wherein, the port entry includes a port identifier, a port status, a link peer device entry index, and a link peer port identifier.

27. The method according to claim 26, wherein, the port status indicates a port disconnection status, and the link peer device entry index is invalid.

28. The method according to claim 27, wherein, sending the topology query response message to the first device includes: incorporating all previously received topology change request messages into the local topology map to obtain the second network, and sending the topology query response message to the first device.

29. A topology management method, wherein, a network includes a first device, a second device, and a third device. The first device is connected to the third device through a port, and the second device is connected to the third device through a port. The method includes: When the connection between the first device and the second device is established and there is a loop in the first device, incorporate the connection relationship between the first device and the second device into the local topology map.

30. A topology management method, wherein, includes: receiving a topology change request message; incorporating the device entries included in the topology change request message into the local topology map to obtain an incorporated topology map.

31. The method according to claim 30, wherein, the method further includes: the local topology map includes the source device that sent the topology change request message, and forward the topology change request message through a port in a ready state or a standby state.

32. The method according to claim 30, wherein, the method further includes: if the local topology map does not include the source device that sent the topology change request message, discard the topology change request message.

33. A transmission network, wherein, The transmission network includes a first network and a second network. The first device is in the first network, and the second device is in the second network. The first network and the second network are independent. The first device and the second device are connected through ports. The first device and the second device are configured to perform the method steps described in any one of claims 1-28 above.

34. The transmission network according to claim 33, wherein, the network topology of the transmission network is a star topology or a mesh topology.

35. A topology management device, wherein, it includes: a sending module, configured to send a topology query request message to the second device. The topology query request message includes a message header, and the message header includes a type field and a response field. The first value of the type field is used to indicate a topology query, and the first value of the response field is used to indicate a request message; a receiving module, configured to receive a topology query response message from the second device. The topology query response message includes a message header, the number of device entries NoDE, and NoDE device entries. The message header includes the type field and the response field. The first value of the type field is used to indicate a topology query, and the second value of the response field is used to indicate a response message. The NoDE device entries are used to determine the connection relationships and the NoDE devices among the NoDE devices in the second network.

36. A topology management device, wherein, it includes: a receiving module, configured to receive a topology query request message sent by the first device. The topology query request message includes a message header, and the message header includes a type field and a response field. The first value of the type field is used to indicate a topology query, and the first value of the response field is used to indicate a request message; a sending module, configured to send a topology query response message to the first device. The topology query response message includes a message header, the number of device entries NoDE, and NoDE device entries. The message header includes the type field and the response field. The first value of the type field is used to indicate a topology query, and the second value of the response field is used to indicate a response message. The NoDE device entries are used to determine the connection relationships and the NoDE devices among the NoDE devices in the second network.

37. A topology management device, wherein, it includes: a receiving module, configured to receive a topology change request message; a processing module, configured to merge the device entries included in the topology change request message into a local topology map to obtain a merged topology map.

38. An electronic device, wherein, the electronic device includes a memory and a processor. The memory is 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 described in any one of claims 1-28 above.

39. A chip, wherein, comprising one or more interface circuits and one or more processors; the interface circuits are configured to receive signals from a memory of an 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 operational steps of the method according to any one of claims 1-28.

40. A computer-readable storage medium, wherein, the computer-readable storage medium stores a computer program which, when running on a computer or a processor, causes the computer or the processor to perform the operational steps of the method according to any one of claims 1-28.

Images