Method and device for information synchronization between switches

Abstract

The present application provides a method and device for information synchronization between switches. In the present application, the existing BGP is extended to realize automatic synchronization of target data to be synchronized between switches in the SAN, such as the IP service domain configuration information of the access device and / or the device discovery information of the access device and / or the information on whether the switch supports the default IP service domain, etc., so that all switches that need to be synchronized with each other in the SAN can timely perceive each other's changes, such as new access of the access device, addition or change of the IP service domain configuration information, and the switch turning on or off the function of supporting the default IP service domain, etc., and timely and intelligently adjust the relevant configurations to achieve plug-and-play and rapid fault perception, and finally assist in realizing the loss-free and high-throughput transmission of Ethernet in the SAN.

Description

Technical Field

[0001] The present application relates to network communication technology, and in particular to an information synchronization method and device between switches in a storage area network (SAN: Storage Area Network). Background Art

[0002] In SAN, the switch is the core of the network and can access the host (Initiator) and / or storage device (Target), etc. Here, the devices such as host and / or storage device accessed by the switch can be called access devices, and the switch at this time can also be called access switch.

[0003] At present, the technical requirements and test specifications for NVMe over RoCEv2 network control optimization specify the interaction process and message packets between access devices and switches, but do not specify how to synchronize information between switches. Among them, NVMe is the abbreviation of Non-Volatile Memory express, and RoCEv2 is the abbreviation of Remote Direct Memory Access (RDMA: Remote Direct Memory Access) over Converged Ethernet (over Converged Ethernet). However, in the specific implementation, information synchronization is required between switches. For example, when switch s1 is newly connected to storage device a1, host a2 connected to switch s2 needs to know that storage device a1 is online in order to interact with storage device a1. Based on this, switch s1 needs to synchronize the information of storage device a1 online to switch s2 in time when storage device a1 is online, so that switch s2 can forward the information of storage device a1 online to host a2. However, at present, the above-mentioned technical requirements and test specifications for network control optimization do not specify how to synchronize information between switches. Summary of the invention

[0004] The embodiments of the present application provide a method and an electronic device for synchronizing information between switches, so as to realize information synchronization between switches in a SAN.

[0005] The present application provides an information synchronization method between switches in a storage area network SAN, the method comprising:

[0006] Get the target data to be synchronized;

[0007] The BGP route carrying the target data is sent through the BGP session established with the designated switch, so as to synchronize the target data between target switches that need to be synchronized with the switch.

[0008] The embodiment of the present application also provides an electronic device. The electronic device includes: a processor and a machine-readable storage medium;

[0009] The machine-readable storage medium stores machine-executable instructions that can be executed by the processor;

[0010] The processor is used to execute machine executable instructions to implement the steps of the above disclosed method.

[0011] It can be seen from the above technical solutions that in the embodiment of the present application, the target data to be synchronized, such as the IP service domain configuration information of the access device and / or the device discovery information of the access device and / or the information on whether the switch supports the default IP service domain, etc., are automatically synchronized between the switches in the SAN, so that all the switches that need to be synchronized with each other in the SAN can timely perceive each other's changes, such as the new access of the access device, the addition or change of the IP service domain configuration information, the switch turning on or off the function of supporting the default IP service domain, etc., and timely and intelligently adjust the relevant configurations to achieve plug-and-play and rapid fault perception, and finally assist in achieving zero-packet-loss and high-throughput transmission of Ethernet in the SAN;

[0012] Furthermore, in the embodiments of the present application, synchronization between switches in the SAN is achieved in the form of BGP routing by extending the existing BGP, which makes little change to the SAN networking and is conducive to achieving interoperability and standardization among manufacturers. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0014] Figure 1 A flow chart of the method provided in the embodiment of the present application;

[0015] Figure 2 A schematic diagram of a SAN network provided in an embodiment of the present application;

[0016] Figure 3 A first network diagram provided for an embodiment of the present application;

[0017] Figure 4 A second network diagram provided for an embodiment of the present application;

[0018] Figure 5 A third network diagram provided for an embodiment of the present application;

[0019] Figure 6 A fourth network diagram provided for an embodiment of the present application;

[0020] Figure 7 A fifth network diagram provided for an embodiment of the present application;

[0021] Figure 8 A sixth networking diagram provided for an embodiment of the present application;

[0022] Fig. 9 A schematic diagram of IP service domain configuration information provided in an embodiment of the present application;

[0023] Fig.10 A schematic diagram of access device discovery information provided in an embodiment of the present application;

[0024] Fig.11 A schematic diagram of the default IP service domain information provided in the embodiment of the present application;

[0025] Fig.12 A schematic diagram of the network configuration of the embodiment provided for the embodiment of the present application;

[0026] Fig.13 A structural diagram of a device provided in an embodiment of the present application;

[0027] Fig.14 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0029] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0030] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present application and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more obvious and understandable, the technical solutions in the embodiments of the present application are further described in detail below in conjunction with the accompanying drawings.

[0031] See also Figure 1 , Figure 1 A flow chart of a method provided in an embodiment of the present application. As an embodiment, the method is applied to a switch in a SAN. Optionally, as Figure 2 The method is applied to the SAN shown in FIG. Figure 2Any switch in the SAN in the NVMe over RoCEv2 network. Here, the NVMe over RoCEv2 network is implemented based on the UDP layer in the Ethernet TCP / IP protocol. For ease of description, Figure 1 The switch used in the method shown is denoted as Figure 2 One of the switches shown is denoted as switch 201 .

[0032] like Figure 1 As shown, the process may include the following steps:

[0033] Step 101: the switch 201 obtains target data to be synchronized.

[0034] In the SAN, the target data to be synchronized may be the IP service domain configuration information of the access device in the SAN. And / or, the target data to be synchronized may also be the device discovery information of the access device. And / or, the target data to be synchronized may also be the information of whether the switch 201 supports the default IP service domain.

[0035] For example, optionally, when the IP service domain configuration information corresponding to at least one custom-configured IP service domain is added externally to the switch 201, or when the IP service domain configuration information corresponding to at least one custom-configured IP service domain added to the switch 201 is changed, etc., at this time, the newly added IP service domain configuration information or the changed IP service domain configuration information needs to be synchronized to each target switch in the SAN that needs to be synchronized with the switch 201 (for example Figure 2 As shown in the switch 202 to the switch n), the newly added IP service domain configuration information or the changed IP service domain configuration information can be determined as the target data to be synchronized. As for the specific content of the IP service domain configuration information, this embodiment does not specifically limit it, and it will be described by example below, and will not be repeated here.

[0036] For another example, optionally, in this embodiment, when the switch 201 newly accesses an access device such as a host and / or a storage device, the newly accessed access device will send an access message to the switch 201, and the access message may be, for example, a Link Layer Discovery Protocol (LLDP) message. Based on the above access message, such as the LLDP message, the switch 201 will add device discovery information of the newly accessed local access device. The switch 201 needs to synchronize the device discovery information to each target switch in the SAN that needs to be synchronized with the switch 201. At this time, the device discovery information can be determined as the target data to be synchronized. As for the specific content of the device discovery information, this embodiment does not specifically limit it, and an example will be given below, which will not be repeated here.

[0037] For another example, optionally, in this embodiment, when the switch 201 turns on or off the default IP service domain function, the switch 201 needs to synchronize the information of turning on or off the default IP service domain function to each target switch in the SAN that needs to be synchronized with the switch 201. At this time, the information of whether the switch 201 turns on or off the default IP service domain function (recorded as the information of whether the switch 201 supports the default IP service domain) can be determined as the target data to be synchronized. As for the specific content of the information of whether the switch 201 supports the default IP service domain, this embodiment does not specifically limit it, and it will be described by example below, and will not be repeated here.

[0038] It should be noted that the above is only an example of how to determine the target data to be synchronized. The various examples of determining the target data to be synchronized shown above may appear at the same time or at different times, and this embodiment does not specifically limit it. Moreover, in this embodiment, the specific content of the above target data is only an example, not for limitation. In this embodiment, it can also be set according to the actual business needs in the SAN. This embodiment only focuses on the target data to be synchronized as the data that needs to be synchronized between switches in the SAN. As for the specific form or content of the target data to be synchronized, it is not specifically limited.

[0039] Step 102 , the switch 201 sends a BGP route carrying the target data through a Border Gateway Protocol (BGP) session established with a designated switch, so as to synchronize the target data between target switches that need to be synchronized with the switch 201 .

[0040] BGP does not support data to be synchronized between switches in the SAN, such as the above-mentioned IP service domain configuration information, device discovery information of access devices, information on whether switch 201 supports the default IP service domain, etc. This embodiment extends the existing BGP so that the extended BGP supports data to be synchronized between switches in the SAN. Based on the extended BGP, switch 201 can generate a BGP route carrying the target data (also referred to as an extended BGP route).

[0041] Afterwards, as described in step 102, switch 201 sends a BGP route carrying the target data to the BGP session established between the switch 201 and the designated switch, so as to synchronize the target data between the target switches that need to be synchronized with switch 201. Finally, the data that needs to be synchronized between switches in this embodiment is realized by using the extended BGP route.

[0042] As for the designated switch in step 102, it may be at least one of the above-mentioned target switches; or it may be at least one non-target switch other than all the above-mentioned target switches. This embodiment is not specifically limited and will be described below with examples, which will not be repeated here.

[0043] In addition, the BGP session in step 102 may be an internal border gateway protocol (IBGP: Internal Border Gateway Protocol) session or an external border gateway protocol (EBGP: External Border Gateway Protocol) session, which will be described below with examples and will not be repeated here.

[0044] So far, completed Figure 1 The process shown.

[0045] pass Figure 1 The process shown realizes automatic synchronization of target data to be synchronized between switches in SAN, such as IP service domain configuration information of access devices and / or device discovery information of access devices and / or information on whether switches support default IP service domains, etc., so that all switches that need to be synchronized with each other in SAN can timely perceive each other's changes, such as new access of access devices, addition or change of IP service domain configuration information, and switch enabling or disabling the function of supporting default IP service domains, etc., and timely and intelligently adjust relevant configurations to realize plug-and-play and rapid fault perception, and finally assist in realizing zero-packet-loss and high-throughput transmission of Ethernet in SAN;

[0046] Furthermore, in this embodiment, by extending the existing BGP, synchronization between switches in the SAN is achieved in the form of BGP routing, which makes little change to the SAN networking and is conducive to achieving interoperability and standardization among manufacturers.

[0047] The following first describes how the switch 201 in the above step 102 sends a BGP route carrying target data through the BGP session established with the designated switch, so as to synchronize the target data between the target switches that need to be synchronized with the switch 201, by taking a networking example:

[0048] Embodiment 1:

[0049] See also Figure 3 , Figure 3 A first network diagram provided for an embodiment of the present application. Figure 3 The networking shown is relatively simple, such as Figure 3 As shown in FIG. 1 , if the target switches to be synchronized with the switch 201 are switches 202 to 204, then Figure 3 As shown, IBGP sessions are established between switches 201 to 204 in pairs.

[0050] Based on this, in the above step 102, the switch 201 sending the BGP route carrying the target data through the BGP session established between the switch 201 and the designated switch may include: the switch 201 sends the BGP route carrying the target data through the IBGP session established between each switch from switch 202 to switch 204, thereby finally achieving the synchronization of the above target data between switches 202 to switch 204 that need to be synchronized with switch 201.

[0051] Optionally, in this embodiment, an IBGP session can be established between any two switches to send BGP routes. Preferably, to avoid the same BGP route being repeatedly sent in the SAN, the switch can be prohibited from forwarding the received BGP route according to the IBGP characteristics.

[0052] This completes the description of Embodiment 1.

[0053] Embodiment 2:

[0054] In this embodiment, one of the switch 201 and each target switch that needs to be synchronized with the switch 201 can be designated as a reflector, and the remaining ones can be designated as clients of the reflector. Figure 4 , Figure 4 This is a second network diagram provided in the embodiment of the present application. Figure 4 As shown, if the target switches to be synchronized with the switch 201 are switches 202 to 204, in this embodiment, one of the switches 201 to 204 may be designated as a reflector, and the remaining switches may be designated as clients.

[0055] In this embodiment, an IBGP session is established between the reflector and each client, and no IBGP session is established between the clients. The reflector forwards the BGP route generated or received by it to each client through the IBGP session established between it and each client, but the client does not forward the BGP route received from the reflector after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector through the IBGP session established between it and the reflector, so that the reflector can forward the received BGP route to other clients.

[0056] With switch 201 as a reflector and switches 202 to 204 as clients, in this embodiment, an IBGP session is established between switch 201 as a reflector and each client. No IBGP session is established between switch 202 to 204 as clients. Based on this, in the above step 102, switch 201 sends a BGP route carrying target data through a BGP session established with a designated switch, which may include: switch 201 as a reflector sends a BGP route carrying target data to each client through an IBGP session established with each client, thereby finally achieving synchronization of the above target data between switches 202 to 204 that need to be synchronized with switch 201. Here, after switches 202 to 204 as clients receive the BGP route carrying the above target data sent by switch 201 as a reflector, they no longer forward the received BGP route to avoid the same BGP route being repeatedly sent in the SAN.

[0057] With switch 202 as a reflector (switch 203 and switch 204 are similarly reflectors), and switches 201, 203 to 204 are clients, in this embodiment, the sending of the BGP route carrying the target data by switch 201 through the BGP session established with the designated switch in step 102 may include: switch 201 as a client sends the BGP route carrying the target data to switch 202 as a reflector through the IBGP session established with switch 202 as a reflector, so that after receiving the BGP route carrying the target data, switch 202 as a reflector forwards the received BGP route to switch 203 through the IBGP session established with switch 203, and forwards the received BGP route to switch 204 through the IBGP session established with switch 204, thereby finally achieving synchronization of the target data between switches 202 and 204 that need to be synchronized with switch 201. After the switch 203 and the switch 204 as clients receive the BGP route carrying the target data sent by the switch 202 as a reflector, they no longer forward the received BGP route to avoid the same BGP route being repeatedly sent in the SAN.

[0058] This completes the description of Embodiment 2.

[0059] Embodiment 3:

[0060] In this embodiment, a non-target switch other than the switch 201 and each target switch that needs to be synchronized with the switch 201 may be designated as a reflector, and the switch 201 and each target switch that needs to be synchronized with the switch 201 may be designated as a client of the reflector. In an example, the non-target switch here may be a non-access switch, that is, it is not connected to any access device such as a host, a storage device, etc.

[0061] See also Figure 5 , Figure 5 The third network diagram provided in the embodiment of the present application. Figure 5 As shown, if the target switches to be synchronized with switch 201 are switches 202 to 204, in this embodiment, a non-access switch (referred to as switch 205) may be designated as a reflector, and switches 201 to 204 are clients.

[0062] In this embodiment, an IBGP session is established between the reflector and each client, and no IBGP session is established between the clients. The reflector forwards the BGP route generated or received by it to each client through the IBGP session established between it and each client, but the client does not forward the BGP route received from the reflector after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector through the IBGP session established between it and the reflector, so that the reflector can forward the received BGP route to other clients.

[0063] With switch 205 being a reflector and switches 201 to 204 being clients, in this embodiment, the sending of the BGP route carrying the target data by switch 201 through the BGP session established between the switch 201 and the designated switch in step 102 may include: switch 201 sending the BGP route carrying the target data to switch 205 as a reflector through the IBGP session established between the switch 201 and the switch 205 as a reflector, so that after receiving the BGP route carrying the target data, switch 205 as a reflector forwards the received BGP route to switch 202 through the IBGP session established between the switch 202, forwards the received BGP route to switch 203 through the IBGP session established between the switch 203, and forwards the received BGP route to switch 204 through the IBGP session established between the switch 204, thereby finally achieving synchronization of the target data between switches 202 and 204 that need to be synchronized with switch 201. After the switches 202 to 204 as clients receive the BGP route carrying the target data sent by the switch 205 as a reflector, they no longer forward the received BGP route to avoid the same BGP route being repeatedly sent in the SAN.

[0064] This completes the description of Embodiment 3.

[0065] Embodiment 4:

[0066] In this embodiment, two or more switches between the switch 201 and each target switch that needs to be synchronized with the switch 201 may be designated as reflectors, and the remaining switches may be designated as clients of the reflectors. Figure 6 , Figure 6 This is a fourth network diagram provided in the embodiment of the present application. Figure 6 As shown, if the target switches to be synchronized with the switch 201 are switches 202 to 204, in this embodiment, at least two switches among the switches 201 to 204 may be designated as reflectors, and the remaining switches may be designated as clients.

[0067] In this embodiment, IBGP sessions are established between reflectors, and between reflectors and clients, but no IBGP session is established between clients. The reflector forwards the BGP route it generates or receives to each client through the IBGP session established between it and each client, but the client does not forward the BGP route received from the reflector after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector through the IBGP session established between it and the reflector, so that the reflector can forward the received BGP route to other clients.

[0068] With switches 201 and 204 as reflectors, and switches 202 and 203 as clients, in this embodiment, an IBGP session is established between switch 201 as a reflector and switch 204 as a reflector, and an IBGP session is established between switch 201 as a reflector and switch 204 as a reflector and each client, respectively. No IBGP session is established between switch 202 and switch 203 as clients.

[0069] Based on this, the switch 201 sending the BGP route carrying the target data through the BGP session established between the switch 201 and the designated switch in the above step 102 may include: the switch 201 as a reflector sending the BGP route carrying the target data through the IBGP session established between the switch 204 as a reflector, and the switch 201 as a reflector sending the BGP route carrying the target data to each client through the IBGP session established with each client, and finally realizing the synchronization of the above target data between the switch 202 and the switch 204 that need to be synchronized with the switch 201. After the switch 202 and the switch 203 as the client receive the BGP route carrying the target data sent by the switch 201 as the reflector, the received BGP route is no longer forwarded to avoid the same BGP route being repeatedly sent in the SAN.

[0070] Optionally, in this embodiment, when switch 204 serving as a reflector receives a BGP route carrying the target data, optionally, in order to achieve redundant backup, switch 204 serving as a reflector may send the BGP route carrying the target data to each client through an IBGP session established with each client, so that after switch 202 and switch 203 serving as clients receive the same BGP route, i.e., the BGP route carrying the target data, through different BGP sessions, the BGP route received by one of the BGP sessions is determined as the optimal route, and the BGP route received by the other BGP session is a backup record.

[0071] Afterwards, if switch 201 acting as a reflector fails and the IBGP session between switch 203 acting as a client and switch 201 is disconnected, switch 203 acting as a client will delete all routes sent by switch 201. However, since the same routes sent by switch 204 acting as a reflector are still recorded at this time, switch 203 can use the recorded BGP routes for communication, thereby improving communication reliability.

[0072] Assuming that switches 202 and 204 are reflectors, and switches 201 and 203 are clients, in this embodiment, an IBGP session is established between switch 202 as a reflector and switch 204 as a reflector, and an IBGP session is established between switch 202 as a reflector and switch 204 as a reflector and each client. No IBGP session is established between switch 201 as a client and switch 203. Based on this, in the above step 102, the switch 201 sending the BGP route carrying the target data through the BGP session established with the designated switch may include:

[0073] In step 601, the switch 201 as a client sends a BGP route carrying target data through the IBGP session established between the switch 201 and the switch 202 as a reflector, so that when the switch 202 as a reflector receives the BGP route carrying the above-mentioned target data, it sends the BGP route carrying the target data to the client, i.e., the switch 203, through the IBGP session established between the switch 201 and another client, i.e., the switch 203.

[0074] In step 602, the switch 201 as the client sends a BGP route carrying the target data through the IBGP session established between the switch 201 and the switch 204 as the reflector, so that when the switch 204 as the reflector receives the BGP route carrying the above-mentioned target data, it sends the BGP route carrying the target data to the client, i.e., the switch 203, through the IBGP session established between the switch 201 and another client, i.e., the switch 203.

[0075] Finally, the target data is synchronized between switches 202 to 204 that need to be synchronized with switch 201.

[0076] It should be noted that, as described above, the switch 203 as the client finally receives the same BGP route, i.e., the BGP route carrying the above target data, through different BGP sessions. After the switch 203 as the client receives the same BGP route, i.e., the BGP route carrying the above target data, through different BGP sessions, it will determine the BGP route received by one of the BGP sessions as the optimal route, and the BGP route received by the other BGP session as a backup record. Afterwards, if the switch 202 as the reflector fails, the IBGP session between the switch 203 as the client and the switch 202 is disconnected, then the switch 203 as the client will delete all the routes sent by the switch 202, but since the same route sent by the switch 204 as the reflector is still recorded at this time, the switch 203 can use the recorded BGP route for communication, thereby improving the reliability of communication.

[0077] In this embodiment, after receiving the BGP route carrying the target data sent by the reflector, the client no longer forwards the received BGP route to avoid the same BGP route being repeatedly sent in the SAN.

[0078] This completes the description of Embodiment 4.

[0079] Embodiment 5:

[0080] In this embodiment, two or more non-target switches other than the switch 201 and each target switch that needs to be synchronized with the switch 201 may be designated as reflectors, and the switch 201 and each target switch that needs to be synchronized with the switch 201 may be designated as clients of the reflector. In one example, the non-target switch here may be a non-access switch, that is, it is not connected to any access device such as a host, a storage device, etc.

[0081] See also Figure 7 , Figure 7 The fifth network diagram provided in the embodiment of the present application is shown in FIG. Figure 7 As shown, if the target switches to be synchronized with switch 201 are switches 202 to 204, in this embodiment, two non-access switches (referred to as switch 205) may be designated as reflectors, and switches 201 to 204 are clients.

[0082] In this embodiment, an IBGP session is established between the reflector and each client, and no IBGP session is established between reflectors or between clients. The reflector forwards the BGP route generated or received by it to each client through the IBGP session established between it and each client, but the client does not forward the BGP route received from the reflector after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector through the IBGP session established between it and the reflector, so that the reflector can forward the received BGP route to other clients.

[0083] by Figure 7 The switches 205 and 206 shown are reflectors, and the switches 201 to 204 are clients. In this embodiment, in the above step 102, the switch 201 sends a BGP route carrying target data through the BGP session established with the designated switch, which may include:

[0084] Step 701, switch 201 sends a BGP route carrying target data to switch 205 acting as a reflector through the IBGP session established between switch 201 and switch 205 acting as a reflector, so that after receiving the BGP route carrying the above-mentioned target data, switch 205 acting as a reflector forwards the received BGP route to each client, i.e., switch 202 to switch 204, through the IBGP session established between switch 201 and each client, i.e., switch 202 to switch 204.

[0085] In step 702, switch 201 sends a BGP route carrying target data to switch 206 acting as a reflector through the IBGP session established between switch 201 and switch 206 acting as a reflector, so that after receiving the BGP route carrying the above-mentioned target data, switch 206 acting as a reflector forwards the received BGP route to each client, i.e., switch 202 to switch 204, through the IBGP session established between switch 201 and each client, i.e., switch 202 to switch 204.

[0086] Finally, through the above steps 701 to 702, the target data is synchronized between the switches 202 to 204 that need to be synchronized with the switch 201. It should be noted that in this embodiment, after the switches 202 to 204 as clients receive the BGP route carrying the target data sent by the switch 205 or the switch 206 as the reflector, the received BGP route is no longer forwarded to avoid the same BGP route being repeatedly sent in the SAN.

[0087] In addition, in this embodiment, similar to the embodiment 4, the switches 202 to 204 as clients will eventually receive the same BGP route, i.e., the BGP route carrying the above target data, through different BGP sessions. After the switches 202 to 204 as clients receive the same BGP route, i.e., the BGP route carrying the above target data, through different BGP sessions, they will determine the BGP route received by one of the BGP sessions as the optimal route, and the BGP route received by the other BGP session will be backed up to achieve redundant backup and improve reliability. For example, if the switch 205 as a reflector fails, the IBGP session between the switch 203 as a client and the switch 205 is disconnected, then the switch 203 as a client will delete all routes sent by the switch 205, but since the same route sent by the switch 206 as a reflector is still recorded at this time, the switch 203 can use the recorded BGP route for communication, thereby improving communication reliability.

[0088] This completes the description of Embodiment 5.

[0089] Embodiment 6:

[0090] This embodiment takes the EBGP session as an example. Figure 8 As shown, in this embodiment, if the target switches that need to be synchronized with the switch 201 are switches 202 to 204, an EBGP session may be established between the switch 201 and the switch 202, an EBGP session may be established between the switch 201 and the switch 204, and an EBGP session may be established between the switch 202 and the switch 203. Based on this, in the above step 102, the switch 201 may send a BGP route carrying the target data through the BGP session established between the switch 201 and the designated switch, which may include:

[0091] Step 801, switch 201 sends a BGP route carrying target data to switch 202 through the EBGP session established between switch 201 and switch 202, so that after receiving the BGP route carrying the above-mentioned target data, switch 202 forwards the received BGP route to switch 203 through the EBGP session established between switch 203 and switch 203.

[0092] Step 801 : Switch 201 sends a BGP route carrying target data to switch 204 through the EBGP session established between switch 201 and switch 204 .

[0093] Finally, through the above steps 701 to 702 , the above target data is synchronized between the switches 202 to 204 that need to be synchronized with the switch 201 .

[0094] This completes the description of Embodiment 6.

[0095] It should be noted that in this embodiment, as long as the switches are synchronized according to the extended BGP, the specific networking form is not limited. The networking examples in the above embodiments 1 to 6 are only examples and are not intended to be limiting.

[0096] The NGP routing in step 202 is described below:

[0097] In this embodiment, the BGP route is carried in a multi-protocol reachable NLRI (MP_REACH_NLRI) attribute in a BGP Update message.

[0098] As an embodiment, the MP_REACH_NLRI attribute may at least include: an address family identifier (AFI: AddressFamily Identifier), a sub-address family identifier (SAFI: Subsequent Address Family Identifier), and NLRI.

[0099] The AFI in this embodiment may be pre-specified and different from the defined AFI value. For example, in this embodiment, the AFI value is 6000.

[0100] The SAFI in this embodiment may be pre-specified and different from the defined SAFI value. For example, in this embodiment, the SAFI value is 254.

[0101] Optionally, in this embodiment, the BGP route is specifically carried in the NLRI of the MP_REACH_NLRI attribute. As described above, the target data carried by the BGP route includes at least: the IP service domain configuration information of the access device, and / or the device discovery information of the access device, and / or the information on whether the switch 201 supports the default IP service domain.

[0102] Optionally, IP service domain configuration information such as Fig. 9 As shown, it at least includes: the BGP route identifier (Route ID) of the switch 201, the IP service domain identifier (Zone Name), and the IP address (IPAddress) of the access device to which the IP service domain configuration information belongs. Here, the IP service domain identifier is an identifier of a custom configured IP service domain, which is different from the default IP service domain. It should be noted that in this embodiment, the IP Address can be an IPv4 address or an IPv6 address, which is not specifically limited in this embodiment.

[0103] Optionally, the device discovery information of the access device is as follows: Fig.10 As shown, it at least includes: the MAC address of the access device, the port identifier of the port on the access device connected to the switch 201, and the BGP route identifier of the switch 201. Fig.10 The device discovery information of the access device shown may also include the length of the Port Name (remembered as the port identification length), which refers to the length of the Port Name.

[0104] In this embodiment, the device discovery information of the access device further includes device attribute information of the access device.

[0105] Optionally, the device attribute information of the access device includes at least: an IP address of the access device (the IP address is an IPv4 address or an IPv6 address), status information of the access device (the status information includes at least online or offline), and a role type of the access device (the role type includes at least a storage system and / or a host). In this embodiment, the IP address of the access device, the status information of the access device, and the role type of the access device can be represented by TLVs, respectively, and are not limited here.

[0106] Optionally, in an example, when determining whether the current BGP route is the same route as the previously received BGP route, it can be determined directly by relying on the MAC address of the access device, the port identifier of the port on the access device connected to the switch 201, and the BGP route identifier of the switch 201. Therefore, as an embodiment, the MAC address of the access device, the port identifier of the port on the access device connected to the switch 201, and the BGP route identifier of the switch 201 can be considered as part of the prefix in the above-mentioned NLRI.

[0107] In this embodiment, the information about whether the switch 201 supports the default IP service domain includes at least:

[0108] The BGP route identifier (Route ID) of switch 201; or,

[0109] BGP route identifier and enable indicator value (Enable) of switch 201. When the enable indicator value is the first value, it indicates that switch 201 supports the default IP service domain. When the enable indicator value is the second value, it indicates that the switch does not support the default IP service domain. In this embodiment, both the BGP route identifier and the enable indicator value can be represented by TLV. Fig.11 The BGP routing label and enable indication value of switch 201 are shown as an example.

[0110] The above example uses the switch 202 actively sending BGP routes. Optionally, in this embodiment, the switch 202 may also receive BGP routes sent by other switches through a BGP session such as an IBGP session or an EBGP session, and add or update corresponding route configuration information entries locally based on the received BGP routes; the route configuration information entries are related to the data to be synchronized carried by the received BGP routes. For example, if the data to be synchronized is newly added IP service domain configuration information, the route configuration information entries here may include the newly added IP service domain configuration information, etc.

[0111] Optionally, as described above, in this embodiment, the switch 202 may also receive BGP routes carrying the same data to be synchronized through different BGP sessions, and then the optimal route may be determined according to the route optimization method.

[0112] The following describes the route withdrawal provided in the embodiment of the present application:

[0113] In this embodiment, still taking the above switch 201 as an example, the switch 201 may also have a need to revoke at least one stored BGP route. For example, when the host or storage device connected to the switch 201 is offline, the BGP route corresponding to the offline host or storage device needs to be revoked, that is, at this time, the switch 201 determines that at least one stored BGP route needs to be revoked. When the switch 201 determines that at least one stored BGP route needs to be revoked, it will first delete the stored at least one BGP route that needs to be revoked, and send a notification through the BGP session to instruct the above target switches to delete the at least one BGP route that needs to be revoked and the route configuration information entry corresponding to the at least one BGP route.

[0114] Similarly, when the switch 201 receives at least one BGP route to be revoked through the BGP session, it will also delete the stored at least one BGP route and the route configuration information entry corresponding to the at least one BGP route.

[0115] Optionally, in this embodiment, at least one BGP route to be revoked is carried in a multi-protocol unreachable NLRI (MP_UNREACH_NLRI) attribute in a BGP Update message. Here, the AFI and SAFI in the MP_UNREACH_NLRI attribute can refer to the description of the MP_REACH_NLRI attribute above.

[0116] The method provided in the embodiment of the present application is described above, and is described below in conjunction with a specific embodiment:

[0117] See also Fig.12 , Fig.12 This is a schematic diagram of the network configuration of the embodiment provided in this application. Fig.12 In the embodiment, switch 1201 and switch 1202 are configured as reflectors and are configured with the same Cluster ID. Switch 1203 and switch 1204 are configured as clients of the above reflector. Switch 1201 to switch 1204 are configured in the same AS and are IBGP peers to each other. Based on the description of the above embodiment 4, Fig.12 In the example, BGP sessions are established between switch 1201 and switch 1202, between switch 1201 and switch 1203, between switch 1201 and switch 1204, between switch 1202 and switch 1203, and between switch 1202 and switch 1204.

[0118] When the IP service domain configuration of host B is added on switch 1201, switch 1201 obtains the newly added IP service domain configuration, generates and records the BGP route carrying the IP service domain configuration. Afterwards, switch 1201 sends the BGP route through the BGP session established with switch 1202, switch 1201 sends the BGP route through the BGP session established with switch 1203, and switch 1201 sends the BGP route through the BGP session established with switch 1204. Switches 1202 to 1204 receive and record the BGP route, and parse the BGP route to add the IP service domain configuration entry of the remote host B locally.

[0119] When the IP service domain configuration of host B recorded on switch 1201 needs to be modified, switch 1201 updates the corresponding existing BGP route. Afterwards, switch 1201 sends the updated BGP route through the BGP session established with switch 1202, switch 1201 sends the updated BGP route through the BGP session established with switch 1203, and switch 1201 sends the updated BGP route through the BGP session established with switch 1204. Switches 1202 to 1204 receive and record the updated BGP route, and parse the updated BGP route to update the remote IP service domain configuration entry recorded locally. The updated IP service domain configuration entry is the same as the modified IP service domain configuration entry.

[0120] When it is necessary to delete the IP service domain configuration of host B recorded by switch 1201, switch 1201 cancels the corresponding existing BGP route. After that, switch 1201 sends the BGP route cancellation notification through the BGP session established with switch 1202, switch 1201 sends the BGP route cancellation notification through the BGP session established with switch 1203, and switch 1201 sends the BGP route cancellation notification through the BGP session established with switch 1204. After receiving the above BGP route cancellation notification, switches 1202 to 1204 delete the recorded corresponding BGP routes and the recorded corresponding remote IP service domain configuration entries (i.e., the IP service domain configuration entries of host B).

[0121] It should be noted that, in this embodiment, when it is necessary to modify the IP service domain configuration of host B recorded on switch 1201, the corresponding BGP route that has been cancelled can also be sent in the above-mentioned manner of deleting the IP service domain configuration of host B recorded on switch 1201, and a BGP route cancellation notification can be sent to switches 1202 to 1204 to instruct switches 1202 to 1204 to delete the corresponding BGP route that has been recorded and the corresponding remote IP service domain configuration entry that has been recorded (i.e., the IP service domain configuration entry of host B) to indicate. After that, the above-mentioned operation of adding the IP service domain configuration of host B on switch 1201 is performed again. How to perform it specifically depends on whether the modified IP service domain configuration is a key feature, such as a feature parameter used to determine whether the BGP route is the same route as other routes (the feature parameter here can be the above-mentioned IP service domain configuration information, or other parameters set by user, etc., which are not specifically limited in this embodiment). If yes, the update can be realized by first canceling and then adding. If not, as described above, the existing corresponding BGP route is directly updated and sent.

[0122] When a new access device such as a host or storage device is newly connected to switch 1204, the newly connected access device will first send an LLDP message to switch 1204 after going online. Switch 1204 will add local access device discovery information locally, generate and record the corresponding BGP route. Afterwards, switch 1204, as a client, sends the BGP route to switch 1201 through the BGP session established between switch 1201 as a reflector. Also, switch 1204, as a client, sends the BGP route to switch 1202 through the BGP session established between switch 1202 as a reflector. Switch 1201, as a reflector, will reflect the received BGP route to switch 1203, as a client, through the BGP session established between switch 1203 as a client. Switch 1202, as a reflector, will reflect the received BGP route to switch 1203, as a client, through the BGP session established between switch 1203 as a client. Switch 1202, as a reflector, will reflect the received BGP route to switch 1203, as a client, through the BGP session established between switch 1203 as a client. Switch 1203 receives two identical routes reflected from switches 1201 and 1202, and selects the optimal route according to the BGP protocol standard and actual implementation.

[0123] It should be noted that no matter whether the optimal route is the BGP route reflected by switch 1201 or the BGP route reflected by switch 1202, since the routing information (also called the data to be synchronized) carried by the BGP route reflected by switch 1201 and the BGP route reflected by switch 1202 are consistent, switch 1203 can parse the device discovery information of the newly connected access device on switch 1204.

[0124] Based on this, if the optimal route is the BGP route reflected by switch 1201, then when switch 1201 fails, the BGP session between switch 1203 and switch 1201 will be disconnected, and switch 1203 will delete all routes sent by switch 1201. However, since switch 1203 still saves the same route sent by switch 1202, switch 1203 still has the BGP route generated by switch 1204; therefore, deploying both switch 1201 and switch 1202 as two reflectors for redundant backup can improve reliability.

[0125] When the device discovery information of the access device such as a host or storage device on the switch 1204 changes, the access device will send an LLDP message to inform the switch 1204, and the switch 1204 will update the local access device discovery information and update the corresponding recorded BGP route.

[0126] Afterwards, switch 1204 as a client sends the updated BGP route to switch 1201 through the BGP session established between switch 1201 as a reflector. Also, switch 1204 as a client sends the updated BGP route to switch 1202 through the BGP session established between switch 1202 as a reflector.

[0127] Switch 1201 acts as a reflector, and reflects the received BGP route to switch 1203 acting as a client through the BGP session established between switch 1203 and switch 1203 acting as a client.

[0128] The switch 1202 acts as a reflector, and reflects the received BGP route to the switch 1203 acting as a client through the BGP session established between the switch 1203 and the client.

[0129] Finally, switch 1203 receives two identical routes reflected from switch 1201 and switch 1202, and selects the optimal route according to the BGP protocol standard and actual implementation. It should be noted that the change in the device discovery information of the access device is similar to the change in the above IP service domain configuration, and will not be described in detail.

[0130] When the access device connected to the switch 1204, such as a host or storage device, is offline, the switch 1204 finds that the corresponding device is offline (such as LLDP aging, link disconnection, etc.), and then cancels the existing BGP route. After that, the switch 1204, as a client, sends a route cancellation notification to the switch 1201 through the BGP session established between the switch 1201 as a reflector. And, the switch 1204, as a client, sends a route cancellation notification to the switch 1202 through the BGP session established between the switch 1202 as a reflector.

[0131] Switch 1201 acts as a reflector, and reflects the route withdrawal notification to switch 1203 acting as a client through the BGP session established between switch 1203 and the client.

[0132] Switch 1202 acts as a reflector, and reflects the route withdrawal notification to switch 1203 acting as a client through the BGP session established between switch 1203 and the client.

[0133] Finally, after receiving the route withdrawal notification reflected by switches 1201 and 1202, switch 1203 deletes the corresponding BGP route and modifies the device status information corresponding to the BGP route to offline.

[0134] The above description is based on the IP service domain configuration and device discovery information as an example. The rest of the cases are similar and will not be described in detail here.

[0135] The following is a description of the device provided in the embodiment of the present application:

[0136] See also Fig.13 , Fig.13 This is a structural diagram of a device provided in an embodiment of the present application. The device is applied to a switch in a SAN. Fig.13 As shown, the device may include:

[0137] The obtaining unit is used to obtain the target data to be synchronized.

[0138] The routing unit is used to send a BGP route carrying the target data through a BGP session established with a designated switch, so as to synchronize the target data between target switches that need to be synchronized with the switch.

[0139] Optionally, the above target data at least includes:

[0140] IP service domain configuration information of the access device, and / or device discovery information of the access device, and / or information on whether the switch supports the default IP service domain.

[0141] Optionally, the above IP service domain configuration information at least includes:

[0142] The switch's BGP route identifier Route ID, IP service domain identifier, and the IP address of the access device to which the IP service domain configuration information belongs; the IP service domain identifier is an identifier of a custom-configured IP service domain, which is different from the default IP service domain.

[0143] Optionally, the device discovery information of the access device at least includes:

[0144] The MAC address of the access device, the port identifier of the port on the access device connected to the switch, and the BGP route identifier Route ID of the switch.

[0145] Optionally, the device discovery information of the access device further includes device attribute information of the access device; the device attribute information of the access device at least includes:

[0146] The IP address of the access device, where the IP address is an IPv4 address or an IPv6 address;

[0147] Status information of the access device, the status information at least including online or offline;

[0148] The role type of the access device, where the role type includes at least: storage system and / or host.

[0149] Optionally, the information on whether the switch supports the default IP service domain includes at least:

[0150] The BGP route ID of the switch; or

[0151] The BGP route identifier Route ID and the enable indication value of the switch, wherein when the enable indication value is a first value, it indicates that the switch supports the default IP service domain, and when the enable indication value is a second value, it indicates that the switch does not support the default IP service domain.

[0152] Optionally, the designated switch is: at least one of the target switches; or

[0153] The designated switch is: at least one non-target switch other than the switch and the target switch.

[0154] In this embodiment, the routing unit further adds or updates the corresponding routing configuration information entry locally according to the received BGP route when receiving the BGP route sent by other switches through the BGP session established with the designated switch. Here, the routing configuration information entry is related to the data to be synchronized carried by the received BGP route.

[0155] In this embodiment, the routing unit further determines the optimal route according to the route optimization mode when receiving BGP routes carrying the same data to be synchronized through different BGP sessions.

[0156] In this embodiment, the routing unit further stores the above-mentioned BGP routes; when it is necessary to revoke at least one stored BGP route, the stored at least one BGP route that needs to be revoked is deleted, and a notification is sent through the BGP session established with the designated switch to instruct the target switch to delete the at least one BGP route that needs to be revoked and the routing configuration information entry corresponding to the at least one BGP route.

[0157] In this embodiment, when the routing unit further receives at least one BGP route to be revoked through the BGP session established with the designated switch, the at least one BGP route stored and the route configuration information entry corresponding to the at least one BGP route are deleted.

[0158] In this embodiment, the BGP route is carried in the MP_REACH_NLRI attribute in the BGP Update message. The AFI and SAFI in the MP_REACH_NLRI attribute are pre-specified and do not conflict with the defined AFI value and SAFI value.

[0159] In this embodiment, at least one BGP route to be revoked is carried in the MP_UNREACH_NLRI attribute in the BGP Update message, and the AFI and SAFI in the MP_UNREACH_NLRI attribute are pre-specified and do not conflict with the defined AFI value and SAFI value.

[0160] So far, completed Fig.13 Structural description of the device shown.

[0161] The present application also provides Fig.13 The hardware structure of the device shown. Fig.14 , Fig.14 This is a structural diagram of an electronic device provided in an embodiment of the present application. Fig.14 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.

[0162] Based on the same application concept as the above method, an embodiment of the present application also provides a machine-readable storage medium, on which a number of computer instructions are stored. When the computer instructions are executed by a processor, the method disclosed in the above example of the present application can be implemented.

[0163] Exemplarily, the above-mentioned machine-readable storage medium can be any electronic, magnetic, optical or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium can be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as CD, DVD, etc.), or similar storage medium, or a combination thereof.

[0164] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0165] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0166] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0167] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0168] Moreover, these computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0169] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0170] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for synchronizing information between switches in a storage area network SAN, characterized in that: The method is applied to a switch in a SAN, and the method comprises: Get the target data to be synchronized; Sending a BGP route carrying the target data through a Border Gateway Protocol (BGP) session established with a designated switch, so as to synchronize the target data between target switches that need to be synchronized with the switch; The target data at least includes: IP service domain configuration information of the access device, and / or device discovery information of the access device, and / or information on whether the switch supports the default IP service domain; The IP service domain configuration information at least includes: The switch's BGP route identifier Route ID, IP service domain identifier, and the IP address of the access device to which the IP service domain configuration information belongs; the IP service domain identifier is an identifier of a custom-configured IP service domain, which is different from the default IP service domain.

2. The method according to claim 1, characterized in that The device discovery information of the access device includes at least: The MAC address of the access device, the port identifier of the port on the access device connected to the switch, and the BGP route identifier Route ID of the switch.

3. The method according to claim 2, characterized in that The device discovery information of the access device further includes device attribute information of the access device; the device attribute information of the access device at least includes: The IP address of the access device, where the IP address is an IPv4 address or an IPv6 address; Status information of the access device, the status information at least including online or offline; The role type of the access device, where the role type includes at least: storage system and / or host.

4. The method according to claim 1, characterized in that: The information on whether the switch supports the default IP service domain includes at least: The BGP route ID of the switch; or The BGP route identifier Route ID and the enable indication value of the switch, wherein when the enable indication value is a first value, it indicates that the switch supports the default IP service domain, and when the enable indication value is a second value, it indicates that the switch does not support the default IP service domain.

5. The method according to claim 1, characterized in that The designated switch is: at least one of the target switches; or The designated switch is: at least one non-target switch other than the switch and the target switch.

6. The method according to claim 1, characterized in that The method further comprises: When receiving BGP routes sent by other switches through the BGP session established with the designated switch, the corresponding route configuration information entry is added or updated locally according to the received BGP route; the route configuration information entry is related to the data to be synchronized carried by the received BGP route.

7. The method according to claim 1, characterized in that The method further comprises: When BGP routes carrying the same data to be synchronized are received through different BGP sessions, an optimal route is determined according to the route selection mode.

8. The method according to claim 1, characterized in that: The method further comprises: Storing the BGP route; When it is necessary to revoke at least one stored BGP route, the stored at least one BGP route that needs to be revoked is deleted, and a notification is sent through the BGP session established with the designated switch to instruct the target switch to delete the at least one BGP route that needs to be revoked and the route configuration information entry corresponding to the at least one BGP route.

9. The method according to claim 1, characterized in that: The method further comprises: When at least one BGP route to be revoked is received through the BGP session established with the designated switch, the at least one BGP route stored and the route configuration information entry corresponding to the at least one BGP route are deleted.

10. The method according to claim 1, characterized in that The BGP session is: An internal Border Gateway Protocol (IBGP) session or an external Border Gateway Protocol (EBGP) session.

11. The method according to any one of claims 1 to 7, characterized in that: The BGP route is carried in the MP_REACH_NLRI attribute in the BGP Update message; the address family identifier AFI and the sub-address family identifier SAFI in the MP_REACH_NLRI attribute are pre-specified and do not conflict with the defined AFI value and SAFI value.

12. The method according to any one of claims 8 to 9, characterized in that: At least one BGP route that needs to be revoked is carried in the MP_UNREACH_NLRI attribute in the BGP Update message, and the address family identifier AFI and the sub-address family identifier SAFI in the MP_UNREACH_NLRI attribute are pre-specified and do not conflict with the defined AFI value and SAFI value.

13. An electronic device, characterized in that: The electronic device comprises: a processor and a machine-readable storage medium; The machine-readable storage medium stores machine-executable instructions that can be executed by the processor; The processor is used to execute machine executable instructions to implement the method according to any one of claims 1 to 12.

Images