Multi-terminal redundant data transmission method and system, bridge switch and storage medium

Abstract

The invention discloses a multi-terminal redundant data transmission method and system, a bridge switch and a storage medium, and is applied to the bridge switch of the multi-terminal redundant data transmission system, and the multi-terminal redundant data transmission method comprises the following steps: receiving a data message sent by a previous data transmission node; determining an output port corresponding to the data message, and executing an R-TAG mark processing action associated with the output port on the data message, the R-TAG mark processing action being retention or elimination; and transmitting the processed data message to a next data transmission node from the output port. In the invention, each output port corresponds to one independent processing rule, and the R-TAG elimination or reservation operation is carried out on the data message according to the processing rule, so that different ports can respectively send out the R-TAG reservation mark and the R-TAG elimination mark in a multi-terminal scene.

Description

Technical Field

[0001] The present application relates to the technical field of data transmission, and in particular to a multi-terminal redundant data transmission method, system, bridge switch, and storage medium. Background Art

[0002] IEEE 802.1CB is a key protocol in the Time-Sensitive Networking (TSN) standard family, designed to provide highly reliable, low-latency, and deterministic data transmission. In the 802.1CB protocol, when data frames need to be replicated to improve reliability, important data frames to be transmitted are copied into multiple copies. These copies contain identical payload data but are distinguished by specific identifiers (such as sequence numbers and replication tags (R-TAGs)). Through frame replication, even if a copy is lost or damaged during network transmission due to link failures, signal interference, or other reasons, other copies may still successfully reach the receiving end, greatly improving data transmission reliability.

[0003] The current implementation binds the R-TAG frame elimination function (recovery terminate parameter) to the fred instance, which is then bound to the outbound port list. This binding method results in consistent behavior for all outbound ports. Specifically, the value of the recovery terminate parameter determines how all outbound ports handle R-TAGs. If the recovery terminate parameter is set to true, all outbound ports eliminate R-TAGs; if recovery terminate is set to false, all outbound ports retain R-TAGs. This cannot meet the requirement of retaining or eliminating R-TAGs on different ports in multi-terminal scenarios.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a multi-terminal redundant data transmission method, device and storage medium, aiming to solve how to realize the transmission of retained R-TAG and elimination of R-TAG marks from different ports in a multi-terminal scenario.

[0006] In order to solve the above problems, the present application provides a multi-terminal redundant data transmission method, which is applied to a bridge switch of a multi-terminal redundant data transmission system. The multi-terminal redundant data transmission method includes:

[0007] Receive the data message sent by the previous data transmission node;

[0008] Determine the egress port corresponding to the data packet, and perform an R-TAG tag processing action associated with the egress port on the data packet, wherein the R-TAG tag processing action is retaining or eliminating;

[0009] The processed data message is transmitted from the egress port to the next data transmission node.

[0010] In one embodiment, after the step of receiving the data message sent by the previous data transmission node, the method further includes:

[0011] Determining, according to an ingress port of the data message, a target flow instance corresponding to the ingress port;

[0012] According to the identifier of the target flow instance, determine the frer instance bound to the target flow instance.

[0013] In one embodiment, after the step of determining the fred instance bound to the flow instance according to the identifier of the flow instance, the method further includes:

[0014] Match rules in the fred instance according to the egress port and determine a processing rule;

[0015] According to the R-TAG mark processing action in the processing rule, the datagram is subjected to R-TAG mark retention processing or R-TAG mark removal processing.

[0016] In one embodiment, before the step of determining the egress port corresponding to the data packet and performing the R-TAG tag processing action associated with the egress port on the data packet, the method further includes:

[0017] Determining an instance mode of a corresponding instance according to the instance mode parameter, wherein the instance mode is a recovery instance mode or a generation instance mode;

[0018] If the instance mode is the recovery instance mode, the R-TAG tag processing action associated with the egress port is performed on the data packet.

[0019] In one embodiment, after the step of determining the instance mode of the corresponding instance according to the instance mode parameter, the method further includes:

[0020] If the instance mode is the generated instance mode, redundancy backup is performed on the data message to obtain a duplicate data message.

[0021] In one embodiment, the step of performing redundant backup on the data message to obtain redundant data includes:

[0022] Performing redundant backup of the data message at each egress port of the bridge switch, wherein each egress port generates at least one duplicate data message;

[0023] An R-TAG tag is added to the duplicate data message, wherein the R-TAG tags in the duplicate data messages of the same data message are the same.

[0024] In one embodiment, the step of determining the target flow instance corresponding to the ingress port of the data packet includes:

[0025] Perform flow matching with the ingress port in a preset order;

[0026] When the number of the matched flow instances is greater than one, the first matched flow instance is determined as the target flow instance.

[0027] In addition, to achieve the above objectives, the present application also proposes a multi-terminal redundant data transmission system, comprising:

[0028] At least two bridge switches, the bridge switches being configured to execute the steps of the multi-terminal redundant data transmission method as described above;

[0029] At least two data terminals, the data terminals being configured to receive data messages output by the bridge switch and / or output the data messages to the bridge switch.

[0030] In addition, to achieve the above-mentioned purpose, the present application also proposes a bridge switch, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the multi-terminal redundant data transmission method as described above.

[0031] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and stores a computer program on the storage medium. When the computer program is executed by the processor, the steps of the multi-terminal redundant data transmission method as described above are implemented.

[0032] This application provides a multi-terminal redundant data transmission method. When a bridge switch receives a data packet, it matches the corresponding R-TAG tag processing action based on the data packet's egress port number, and performs R-TAG tag removal or retention operations on the data packet based on the R-TAG tag processing action. Each egress port corresponds to an independent R-TAG tag processing action, and the data packet is subjected to corresponding R-TAG processing based on the different egress ports. This enables different ports to transmit R-TAG retention and R-TAG removal in multi-terminal scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0035] Figure 1 A first flow chart of the multi-terminal redundant data transmission method provided in this application;

[0036] Figure 2 It is a structural diagram of a multi-terminal redundant data transmission system;

[0037] Figure 3 This is a frame structure diagram of the frame format of the 802.1Q protocol;

[0038] Figure 4 This is a schematic diagram of a multi-terminal redundant data transmission process;

[0039] Figure 5 A second flow chart of the multi-terminal redundant data transmission method provided by this application;

[0040] Figure 6 Schematic diagram of the structure of the hardware operating environment involved in the multi-terminal redundant data transmission method in the embodiment of the present application.

[0041] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0042] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0043] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0044] To achieve the above-mentioned objectives, the present application proposes a multi-terminal redundant data transmission method, which is applied to a bridge switch of a multi-terminal redundant data transmission system. The multi-terminal redundant data transmission method includes: receiving a data packet sent by a previous data transmission node; determining the egress port corresponding to the data packet, and performing an R-TAG mark processing action associated with the egress port on the data packet, wherein the R-TAG mark processing action is retention or elimination; and transmitting the processed data packet from the egress port to the next data transmission node.

[0045] IEEE 802.1CB is a key protocol in the Time-Sensitive Networking (TSN) standard family, designed to provide highly reliable, low-latency, and deterministic data transmission. In the 802.1CB protocol, when data frames need to be replicated to improve reliability, important data frames to be transmitted are copied into multiple copies. These copies contain identical payload data but are distinguished by specific identifiers (such as sequence numbers and replication tags (R-TAGs)). Through frame replication, even if a copy is lost or damaged during network transmission due to link failures, signal interference, or other reasons, other copies may still successfully reach the receiving end, greatly improving data transmission reliability.

[0046] The current implementation binds the R-TAG frame elimination function (recovery terminate parameter) to the fred instance, which is then bound to the outbound port list. This binding method results in consistent behavior for all outbound ports. Specifically, the value of the recovery terminate parameter determines how all outbound ports handle R-TAGs. If the recovery terminate parameter is set to true, all outbound ports eliminate R-TAGs; if recovery terminate is set to false, all outbound ports retain R-TAGs. This cannot meet the requirement of retaining or eliminating R-TAGs on different ports in multi-terminal scenarios.

[0047] This application provides a multi-terminal redundant data transmission method. When a bridge switch receives a data packet, it matches the corresponding R-TAG tag processing action based on the data packet's egress port number, and performs R-TAG tag removal or retention operations on the data packet based on the R-TAG tag processing action. Each egress port corresponds to an independent R-TAG tag processing action, and the data packet is subjected to corresponding R-TAG processing based on the different egress ports. This enables different ports to transmit R-TAG retention and R-TAG removal in multi-terminal scenarios.

[0048] It should be noted that the execution subject of this embodiment may be a computing service device with network communication and program execution capabilities, such as a tablet computer or personal computer, or an electronic device or apparatus capable of implementing the aforementioned functions. This embodiment and the following embodiments are described below using a bridge switch in a multi-terminal redundant data transmission system as an example.

[0049] Based on this, the embodiment of the present application provides a multi-terminal redundant data transmission method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the multi-terminal redundant data transmission method of the present application.

[0050] In this embodiment, the multi-terminal redundant data transmission method is applied to a first bridge switch in a multi-terminal redundant data transmission system. The method includes steps S10 to S30:

[0051] Step S10: receiving a data message sent by a previous data transmission node.

[0052] Step S20: Determine the egress port corresponding to the data packet, and perform an R-TAG mark processing action associated with the egress port on the data packet, wherein the R-TAG mark processing action is retaining or removing.

[0053] Please refer to Figure 2 , Figure 2 The schematic diagram shows the structure of a multi-terminal redundant data transmission system, which adopts a ring topology, that is, all network devices (bridge switches and terminals) are connected to form a ring through point-to-point links. Each device has two ports connected to the previous and next devices on the ring, forming a closed ring, and data can be transmitted through multiple paths. For example, the data stream sent by terminal 1 enters from port 1 of bridge switch 1. When bridge switch 1 receives the data stream of terminal 1, redundant backup is performed on ports 2 and 3. The data stream output from port 2 of bridge switch 1 passes through port 2 of bridge switch 2, and then is transmitted to terminal 2 through port 1 of bridge switch 2; the data stream output from port 3 of bridge switch 1 passes through port 3 of bridge switch 3, and then through port 3 of bridge switch 4, and finally reaches terminal 4. The ring network redundancy mechanism can quickly detect faults in the network and automatically switch to the backup path. For example, if port 2 of bridge switch 2 fails, the fren protocol will detect the failure and switch the data flow to port 3 of bridge switch 1 and port 3 of bridge switch 3 to ensure continuous data transmission.

[0054] It should be noted that the R-TAG (Recovery Tag) is used for path identification and deduplication during frame replication and elimination. Different terminals may have different requirements for the R-TAG. Some terminals require the R-TAG for path tracking or fault recovery and therefore need to retain the R-TAG. Other terminals do not support R-TAG parsing or require simplified message processing and therefore need to eliminate the R-TAG.

[0055] In this embodiment, N egress ACL matching rules are pre-created, where N corresponds to the number of egress ports specified in the fred recovery instance. Each egress ACL matching rule corresponds to a single egress port, port_list. That is, each port_list contains only one egress port, and each egress port corresponds to an egress ACL (access control list) matching rule. When a bridge switch receives a data packet, it first distinguishes different data streams based on the ingress port number of the data packet (a data packet is the basic component unit of a data stream, which is composed of a series of data packets). It then matches the corresponding egress ACL matching rule based on the egress port number of the data packet and executes the corresponding R-TAG tag processing action.

[0056] In this embodiment, the R-TAG is located in the extended header of the Ethernet frame. When locating the R-TAG, it can be located through a predefined offset or a protocol field, such as the Sequence Number in the 802.1CB standard.

[0057] Please refer to Figure 3 , Figure 3 An 802.1Q frame format is shown. Optionally, by pre-defining offset positioning, a fixed offset value of the R-TAG field relative to the Ethernet frame header is pre-configured in the switching chip to achieve R-TAG field positioning. After receiving the Ethernet data message frame, its EtherType is identified (such as 0x8100, indicating an 802.1Q frame). The R-TAG offset is read from the pre-configured register, and the internal data pointer is moved to the starting position of the frame header + the offset, that is, pointing to the starting position of the R-TAG field. If the R-TAG needs to be retained, the modification is skipped and the message is forwarded directly; if the R-TAG needs to be eliminated, the R-TAG field is removed from the data message, the R-TAG field and its subsequent fields are moved forward to cover the original R-TAG position, and the message length field is updated.

[0058] Step S30: Transmit the processed data message from the egress port to the next data transmission node.

[0059] In this embodiment, the data packet is processed according to the R-TAG tag processing action associated with the egress port, and the processed data packet is transmitted from the corresponding egress port to the next data transmission node, which can be another bridge switch or a data receiving end. When the port corresponding to the above egress port number fails, the fred protocol detects the failure and switches the data flow to another data transmission route, and finally transmits the data packet to the data receiving end. For example, Figure 2 If port 2 of bridge switch 1 fails, the data flow will be transmitted through port 3 of bridge switch 1.

[0060] Optionally, the freder configures a primary path and at least one backup path for each data flow. This path information is sent to the bridge switch via a control plane (e.g., an SDN controller). The bridge switch enables the BFD protocol on its outbound port and sends probe messages at a preset interval (e.g., 100ms) to check link connectivity. If no response is received after M consecutive probe messages, the path is considered faulty and the fault is reported to the SDN controller via an interrupt or asynchronous message. The SDN controller selects a backup path based on the global topology and the freder configuration.

[0061] Please refer to Figure 4 , Figure 4 A schematic diagram of a multi-terminal redundant data transmission process is presented. The first terminal outputs a data packet. When port 1 of the first bridge switch receives the data packet from the first terminal, it uses FRE (Frequency Reset) to generate an instance for redundant backup on ports 2 and 3. The packets output from ports 2 and 3 carry the R-tag and VLAN 10. The data packet output from port 2 of the first bridge switch is transmitted from port 2 of the second bridge switch to the second bridge switch. After receiving the data packet on port 2 of the second bridge switch, it first matches the flow instance corresponding to port 2 and then matches the FRE (Frequency Reset) recovery instance bound to that flow instance. For data packets transmitted to the second terminal via port 1 of the second bridge switch, the processing rule corresponding to port 1 in the FRE (Frequency Reset) instance is determined. If the "Recovery terminate" parameter in the processing rule is true, the R-tag tag is removed; if it is false, the R-tag tag is retained. Finally, the processed data packet is transmitted to the second terminal via port 1 of the second bridge switch.

[0062] This application provides a multi-terminal redundant data transmission method. When a bridge switch receives a data packet, it matches the corresponding R-TAG tag processing action based on the data packet's egress port number, and performs R-TAG tag removal or retention operations on the data packet based on the R-TAG tag processing action. Each egress port corresponds to an independent R-TAG tag processing action, and the data packet is subjected to corresponding R-TAG processing based on the different egress ports. This enables different ports to transmit R-TAG retention and R-TAG removal in multi-terminal scenarios.

[0063] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 5 , after step S10, steps A10 to A20 may also be included:

[0064] Step A10: Determine the target flow instance corresponding to the ingress port according to the ingress port of the data message.

[0065] In this embodiment, a stream instance is configured to match a specific data frame. The stream instance matches the traffic characteristics of the terminal data to achieve the effect of distinguishing different data flows in the topology network.

[0066] In a feasible implementation, the stream instance can distinguish different data flows in the topology network by matching the inbound port number of the terminal data. The parameters required for configuring the stream instance of the switch include:

[0067] Stream_id: specifies the ID of the stream instance, which is used to distinguish other stream instances;

[0068] Inbound port number: specifies the data stream that matches the incoming port. It is a parameter that must be configured for the stream instance.

[0069] Vid: Specifies the VLAN ID carried in the matching traffic data frame. If not configured, it means that VID is not used for filtering.

[0070] For example, the configuration of a stream instance is:

[0071] stream;

[0072] outer-tag vid 20;

[0073] ingress interface ge2;

[0074] ingress interface ge3 matches packets entering from ports 2 and 3 with VLAN ID 20. Stream instances distinguish different data flows in a topology network by matching traffic characteristics of data packets, thus identifying different types of traffic on the network.

[0075] Step A20: Determine the frer instance bound to the target flow instance according to the identifier of the target flow instance.

[0076] In this embodiment, the fred instance performs corresponding processing on the data stream matched by the stream instance by binding to a specific stream instance.

[0077] Optionally, the parameters required for configuring the frer instance of the switch include:

[0078] frer_id: specifies the id of the frer instance, which is used to distinguish other frer instances;

[0079] Mode: Select Generate Instance Mode or Restore Instance Mode;

[0080] Entry stream id: the stream instance id that is bound to the fred instance processing flow;

[0081] Outgoing port number: specifies the data outgoing port;

[0082] frer_vlan: specifies the VLAN ID that the data flow carries after it is transmitted from the switch. This VLAN_ID is added by the switch and is added on the outermost side. If the pvid of the outgoing port is the same as frer_vlan, the outgoing data will not carry the VLAN.

[0083] Recovery terminate: Specifies whether to remove the r-tag. If true, outgoing data no longer has the r-tag; if false, outgoing data still has the r-tag. This setting is only valid when the mode is set to restore the instance.

[0084] For example, the configuration of the fred instance is:

[0085] tsn frer 2;

[0086] mode recovery;

[0087] egress interface ge1 frer-vlan 100recovery terminate true / / The frer-vlan of egress port 1 is set to 100 and the R-TAG is removed.

[0088] egress interface ge3 frer-vlan 20recovery terminate false / / The frer-vlan of egress port 3 is 20 and the R-TAG is retained.

[0089] ingress stream-id-list 2 / / bound stream instance ID;

[0090] admin-state enable / / Enable the instance;

[0091] Step A20 may include steps A21 to A22:

[0092] Step A21, performing rule matching in the fred instance according to the egress port, and determining a processing rule.

[0093] Step A22: Perform R-TAG mark preservation processing or R-TAG mark removal processing on the datagram according to the R-TAG mark processing action in the processing rule.

[0094] In this embodiment, the fred instance is bound to a specific stream instance, and the corresponding processing flow is performed on the data stream matched by the stream instance. The processing flow varies according to different parameter configurations, such as frame duplication, elimination and other operations to ensure the reliability of data transmission. Create N ACL matching rules, where N is the number of output ports specified by the fred recovery instance. The key of each rule is vlan_id and a single output port port_list, that is, each output port corresponds to an export ACL, and each export ACL contains an R-TAG tag processing action. Different output ports under the same fred instance can independently control the R-TAG behavior to meet the diverse needs of multi-terminal scenarios. There is no need to modify the fred instance configuration, only the export ACL rules need to be updated to adjust the R-TAG processing behavior.

[0095] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to above and will not be described in detail. On this basis, steps B10 to B20 may be further included before step S20:

[0096] Step B10: determining an instance mode of the corresponding instance according to the instance mode parameters, wherein the instance mode is a recovery instance mode or a generation instance mode.

[0097] In this embodiment, the instance mode parameter refers to the configuration parameter Mode in the fred instance. After matching a specific processing rule, the fred instance's function is determined based on the Mode parameter: generation (frame replication) or recovery (frame elimination). The generation function is primarily responsible for replicating frames entering the network and adding a unique identifier, R-TAG, to each replica frame. This ensures that in the event of any packet loss that may occur in the network, the receiver can recover the original data by receiving multiple copies. The recovery function is responsible for receiving multiple frame copies and, by identifying the R-TAGs of these copies, eliminating redundant frames to ensure that only one copy of the data is retained. When the recovery function receives multiple frame copies, it first determines which frames are redundant based on the identified R-TAGs. By comparing the R-TAGs of different frames, it identifies frames with identical content but repeated occurrences and eliminates these redundant frames, retaining only one representative copy of the data. After eliminating the redundant frames, the configured recovery terminate parameter determines whether to retain the R-TAGs of the remaining data. If the R-TAG is retained, the data that remains after redundant frame removal will carry the R-TAG and continue to be transmitted on the network or processed later. If the R-TAG is not retained, the data will be further processed and its R-TAG will be removed.

[0098] Step B20: If the instance mode is the recovery instance mode, the R-TAG tag processing action associated with the egress port is performed on the data packet.

[0099] In this embodiment, when the function of the fred instance is the recovery function (frame elimination), the R-TAG tag in the data message is eliminated or retained according to the processing rule matched by the data message and then transmitted to the data terminal or other bridge switch. The R-TAG tag processing action is determined by the recovery terminate parameter in the fred instance, and the recovery terminate parameter is configurable only when the mode parameter in the fred instance is set to the recovery instance. If the recovery terminate parameter is true, the outgoing data no longer has the R-TAG; if it is false, the outgoing data still has the R-TAG. If the parameter value does not conform to the expected format, an error handling mechanism can be triggered, such as recording an error log, reporting an error to an upper-layer application, or using a default value.

[0100] Specifically, when the cross-bridge switch receives the data packet, it parses the data packet and extracts the characteristic information used for rule matching. Optionally, the characteristic information used to match the flow instance is the ingress port number, or the ingress port number and the Vid parameter, wherein the Vid parameter specifies the vlan_id carried by the matching traffic data frame. If it is not configured, it means that vid is not used for filtering. After matching the fred instance bound to it according to the identifier information of the flow instance, the characteristic information used to match the specific processing rules in the fred instance is the vlan_id parameter and the single egress port port_list. Each port_list has only one egress port, and each egress port corresponds to an egress ACL. By comparing the message characteristics with the conditions defined in the rules, it is determined which one or several processing rules the current data packet meets. For example, if the rule stipulates that when the source address of the message belongs to a specific subnet and the recovery terminate parameter is a specific value, the R-TAG mark is eliminated. For the data transmitted by each terminal, it is marked with its own unique vlan through the fred instance generated by the directly connected bridge switch. For example, in Figure 2 In the topology bridge switch ring network, the allocation of fren_vlan to terminals 1, 2, 3, and 4 is 10, 20, 30, and 40 respectively.

[0101] Parse the format of the received data message to determine the message structure and the meaning of each field. Different network protocols or data formats may store the R-TAG differently. For example, in some custom protocols, the R-TAG may be located at a specific position in the message header. Based on the results of the message format parsing, determine the specific location of the R-TAG in the data message. Locating the R-TAG can be done by calculating an offset, searching for a specific identifier, or parsing the message header. For example, if the R-TAG is a fixed-length field located between bytes 10 and 17 in the message header, it can be directly located there. After locating the R-TAG, modify the data message to remove the R-TAG.

[0102] Optionally, the way to eliminate the mark may be to perform a zeroing process, setting all bytes where the R-TAG mark is located to 0. The way to eliminate the mark may be to perform a zeroing process or to fill a specific value, filling the position where the R-TAG mark is located with a specific value according to system requirements. This specific value may be a predefined default value, used to indicate that the original R-TAG mark at that position has been eliminated. For example, fill with 0xFF or 0x00, etc. If the presence of the R-TAG mark affects other parts of the message (such as the message length field), after eliminating the mark, the other parts of the message need to be adjusted accordingly to ensure the integrity and validity of the message. For example, if the message length changes after the R-TAG mark is eliminated, the length field of the message header needs to be updated.

[0103] Optionally, recalculate the checksum value of the data message after the R-TAG mark is removed. The calculation method of the checksum value can be determined according to the protocol or data format used by the message. Common checksum methods include checksum, cyclic redundancy check (CRC), etc. Compare the recalculated checksum value with the original checksum value in the message (if any), or compare it with the checksum value that should be obtained according to the protocol requirements. If the two are consistent, it means that there is no error in the message during the process of removing the R-TAG mark and the message is complete; if the two are inconsistent, it means that the message may be damaged or erroneous and needs to be reprocessed or discarded. Send the data message that has removed the R-TAG mark and passed the verification to the specified output target.

[0104] In another possible implementation, in addition to determining whether to retain or remove the R-TAG based on the Recovery Terminate parameter, a sequence number match can also be used. The R-TAG contains a sequence number that increments for each transmitted frame. The receiver parses the sequence number in the R-TAG to identify duplicate frames and decide whether to retain or remove the R-TAG. If a duplicate sequence number is detected, the frame is considered a duplicate and the R-TAG should be removed. If the sequence number is new, the R-TAG is retained.

[0105] Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereafter. On this basis, step B10 may further include step B30:

[0106] Step B30: If the instance mode is the generated instance mode, redundancy backup is performed on the data message to obtain a duplicate data message.

[0107] In this embodiment, when it is determined according to the parameter Mode that the function of the fred instance is a generation function (frame replication), redundant backup is performed on the data message.

[0108] Step B30 may include steps B31 to B32:

[0109] B31, performing redundant backup of the data message at each egress port of the bridge switch, wherein each egress port generates at least one duplicate data message;

[0110] B32: Add an R-TAG tag to the duplicate data message, wherein the R-TAG tags in the duplicate data messages of the same data message are the same.

[0111] In this embodiment, the number of data message copies required is determined based on configuration parameters or preset rules. Independent memory space is allocated for each duplicate frame to ensure that the duplicate frames are independent of each other and do not interfere with each other. The data portion of the original data message (including the frame header, payload, etc.) is copied byte by byte into the memory space of each duplicate frame, generating a duplicate frame that is identical to the original message content. An appropriate sequence number allocation strategy is employed to ensure that the sequence number of each duplicate frame is unique. For example, an incremental counter method is selected for sequence number allocation. Each time a duplicate frame is generated, the sequence number is incremented by a specific step size (e.g., 1). To prevent sequence number overflow, the sequence number range is managed. For example, a 32-bit or 64-bit sequence number counter is used. When the counter reaches its maximum value, it can wrap around according to specific rules (e.g., a modulo operation). Based on the generated sequence number and pre-configured information such as the stream identifier, an R-TAG is constructed in the format specified by the IEEE 802.1CB protocol. The constructed R-TAG is inserted into the designated position of each duplicate frame.

[0112] After a duplicate frame is generated, the frame header may need to be modified depending on the network topology and forwarding requirements. For example, the destination MAC address can be modified to forward the duplicate frame along a different network path, improving data transmission reliability. The duplicate frame, with the R-TAG added, is placed in the device's forwarding queue. The device schedules the duplicate frames based on a queue scheduling algorithm (such as priority queuing or weighted fair queuing) to determine their forwarding order. Based on the scheduling results, the duplicate frame is forwarded out the corresponding network interface.

[0113] For example, for bridge switch 1, when port 1 of the bridge switch receives the data stream from terminal 1, it will generate an instance (frer_1) through frer to perform CB redundancy backup on ports 2 and 3. The messages output from ports 2 and 3 will carry R-TAG and vlan10. The configuration of frer_1 instance is:

[0114] tsn frer 1;

[0115] egress interface ge2;

[0116] egress interface ge3;

[0117] frer-vlan 10 / / indicates that the frer-vlan of all outbound ports is 10;

[0118] ingress stream-id-list 1 / / bind stream instance ID;

[0119] admin-state enable / / Enable the instance;

[0120] In this embodiment, the generation function can effectively copy the data packets entering the network and add a unique identifier R-TAG, thereby improving the reliability of data transmission in the network and ensuring that the receiving end can restore the original data by receiving multiple copies.

[0121] Based on the first embodiment of the present application, in the fifth embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to above and will not be described in detail. On this basis, step A10 may further include the following steps: matching flows according to a preset order and the ingress port number; when the number of matched flow instances is greater than one, determining the first matched flow instance as the target flow instance.

[0122] In this embodiment, ACL rules are stored in a specific order. Rules are retrieved and matched sequentially according to this predetermined order. This order is typically specified by the network administrator when configuring the ACL, or is based on the device's default rule order (e.g., by configuration date, rule number, etc.). The device retrieves the first rule from the ACL rule storage area and extracts the matching conditions defined in the rule, such as the source IP address range, destination port number, and protocol type.

[0123] The relevant information in the data message is compared with the matching conditions in the rule one by one. If all the relevant attributes of the data message meet the conditions of the rule, the data message is considered to have successfully matched this rule; otherwise, continue to match the next rule. If the first rule fails to match, the next rule is retrieved in the storage order, and the above steps of extracting conditions and comparing information are repeated until a matching rule is found or all ACL rules are traversed. When a data message successfully matches a rule, the policy corresponding to the rule is executed. By matching rules in sequence, the policy is executed immediately when a match is found and subsequent matching is stopped, which reduces unnecessary calculations and comparisons and improves the device's processing efficiency for data messages.

[0124] In another feasible implementation, when a data packet matches multiple ACL matching rules, as long as there are no conflicts between the corresponding ACL policies, the multiple ACL matching rules and the corresponding policies remain in effect. Using parallel processing technology, the relevant information of the data packet is simultaneously compared with the matching conditions of each ACL rule. This parallel matching method can shorten matching time and improve processing efficiency.

[0125] In this embodiment, for all successfully matched ACL rules, the policy corresponding to each rule is obtained, and the collected policies are subjected to conflict analysis. If conflicts are detected between policies, the conflicting policies are marked and the conflict type and the rules involved are recorded.

[0126] Optionally, for conflicting policies, priority processing rules can be set. When multiple rules are matched, the final processing decision is determined based on the priority of the rules. Rule priority can be set by rule number, weight, or other pre-defined mechanisms. For example, rules with higher priorities are set to be executed first. When a rule requires the removal of the R-TAG tag and another rule with lower priority requires it to be retained, the removal operation is performed according to the rule with higher priority. Allowing non-conflicting rules to take effect at the same time allows administrators to configure rules more flexibly without having to pay too much attention to the order of the rules, reducing the difficulty and workload of configuration.

[0127] The present application provides a multi-terminal redundant data transmission system, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-terminal redundant data transmission method of the above-mentioned embodiment 1.

[0128] Reference below Figure 6 , which shows a schematic diagram of the structure of a multi-terminal redundant data transmission system suitable for implementing an embodiment of the present application. The multi-terminal redundant data transmission system in the embodiment of the present application can include, but is not limited to, mobile terminals such as laptop computers, personal digital assistants (PDAs), tablet computers (PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The multi-terminal redundant data transmission system shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0129] like Figure 6As shown, the multi-terminal redundant data transmission system may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the multi-terminal redundant data transmission system. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication device 1009. Communication device 1009 can allow the multi-terminal redundant data transmission system to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a multi-terminal redundant data transmission system with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have alternatively.

[0130] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0131] The multi-terminal redundant data transmission system provided in this application utilizes the multi-terminal redundant data transmission method of the aforementioned embodiment, solving the problem of how to achieve, in a multi-terminal scenario, the transmission of R-TAG retention and R-TAG elimination from different ports. Compared with the prior art, the beneficial effects of the multi-terminal redundant data transmission system provided in this application are the same as those of the multi-terminal redundant data transmission method of the aforementioned embodiment. Other technical features of this multi-terminal redundant data transmission system are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0132] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0133] 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 changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0134] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, wherein the computer-readable program instructions are used to execute the multi-terminal redundant data transmission method in the above embodiment.

[0135] The computer-readable storage medium provided in the present application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM, Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM, CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium can be transmitted using any appropriate medium, including but not limited to: an electric wire, an optical cable, a radio frequency (RF, Radio Frequency), etc., or any suitable combination thereof.

[0136] The computer-readable storage medium may be included in a multi-terminal redundant data transmission system, or may exist independently and not be incorporated into the multi-terminal redundant data transmission system. The computer-readable storage medium carries one or more programs. When executed by the multi-terminal redundant data transmission system, the multi-terminal redundant data transmission system: receives a data packet sent by a previous data transmission node; determines the egress port corresponding to the data packet, and performs an R-TAG tag processing action associated with the egress port on the data packet, wherein the R-TAG tag processing action is to retain or remove the R-TAG tag; and transmits the processed data packet from the egress port to the next data transmission node.

[0137] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0138] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0139] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0140] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., a computer program) for executing the above-mentioned multi-terminal redundant data transmission method. This computer-readable storage medium can solve the problem of how to respectively transmit the retained R-TAG and the eliminated R-TAG marks from different ports in a multi-terminal scenario. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-terminal redundant data transmission method provided in the above-mentioned embodiment, and will not be elaborated here.

[0141] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A multi-terminal redundant data transmission method, characterized in that: A bridge switch applied to a multi-terminal redundant data transmission system, wherein the multi-terminal redundant data transmission method comprises: Receive the data message sent by the previous data transmission node; Determine the egress port corresponding to the data packet, and perform an R-TAG tag processing action associated with the egress port on the data packet, wherein the R-TAG tag processing action is retaining or eliminating; The processed data message is transmitted from the egress port to the next data transmission node.

2. The multi-terminal redundant data transmission method according to claim 1, wherein: After the step of receiving the data message sent by the previous data transmission node, the method further includes: Determining, according to an ingress port of the data message, a target flow instance corresponding to the ingress port; According to the identifier of the target flow instance, determine the frer instance bound to the target flow instance.

3. The multi-terminal redundant data transmission method according to claim 2, wherein: After the step of determining the fred instance bound to the flow instance according to the identifier of the flow instance, the method further includes: Match rules in the fred instance according to the egress port and determine a processing rule; According to the R-TAG mark processing action in the processing rule, the datagram is subjected to R-TAG mark retention processing or R-TAG mark removal processing.

4. The multi-terminal redundant data transmission method according to claim 1, wherein: Before the step of determining the egress port corresponding to the data message and performing the R-TAG tag processing action associated with the egress port on the data message, the method further includes: Determining an instance mode of a corresponding instance according to the instance mode parameter, wherein the instance mode is a recovery instance mode or a generation instance mode; If the instance mode is the recovery instance mode, the R-TAG tag processing action associated with the egress port is performed on the data packet.

5. The multi-terminal redundant data transmission method according to claim 4, wherein: After the step of determining the instance mode of the corresponding instance according to the instance mode parameters, the method further includes: If the instance mode is the generated instance mode, redundancy backup is performed on the data message to obtain a duplicate data message.

6. The multi-terminal redundant data transmission method according to claim 5, wherein: The step of performing redundant backup on the data message to obtain redundant data includes: Performing redundant backup of the data message at each egress port of the bridge switch, wherein each egress port generates at least one duplicate data message; An R-TAG tag is added to the duplicate data message, wherein the R-TAG tags in the duplicate data messages of the same data message are the same.

7. The multi-terminal redundant data transmission method according to claim 2, wherein: The step of determining the target flow instance corresponding to the ingress port according to the ingress port of the data message comprises: Perform flow matching with the ingress port in a preset order; When the number of the matched flow instances is greater than one, the first matched flow instance is determined as the target flow instance.

8. A multi-terminal redundant data transmission system, characterized in that: include: At least two bridge switches, the bridge switches being configured to execute the multi-terminal redundant data transmission method according to any one of claims 1 to 7; At least two data terminals, the data terminals being configured to receive data messages output by the bridge switch and / or output the data messages to the bridge switch.

9. A bridge switch, characterized in that: The bridge switch includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the multi-terminal redundant data transmission method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the multi-terminal redundant data transmission method according to any one of claims 1 to 7 are implemented.

Images