TWI773394B - Communication method for one-way transmission based on vlan id and switch device using the same - Google Patents

Abstract

A communication method and a switch device for one-way transmission based on VLAN ID are provided. The communication method includes: receiving, by a first port of a switch, a first data packet from a first external device; packing the first data packet with a first VLAN ID corresponding to a first path to generate a second data packet; receiving, by a first PLD, the second data packet from a third port of the switch; filtering, by the first PLD, the second data packet according to a first filtering rule; in response to the second data packet being matched with the first filtering rule, overwriting the first VLAN ID by a second VLAN ID corresponding to a second path to generate a third data packet; and transmitting, by the first PLD, the third data packet to a second port of the switch via the second path.

Description

Communication method for unidirectional transmission based on VLAN ID and switch device using the same

The present disclosure is directed to a communication method and a switch device for unidirectional transmission based on a virtual local area network identifier (VLAN ID).

In order to prevent the security field (or OT field: operation technology site) from being attacked by computer viruses or hackers from the Internet, one-way transmission technology is usually used in the security field and the non-secure field (or IT field: data transmission between information technology sites. A unidirectional link restricts the direction of the signal so that the signal can only be transmitted from the secure field to the non-secure field, and the signal cannot be transmitted from the non-secure field to the secure field.

FIG. 1 shows a schematic diagram of a unidirectional link arrangement 90 . The unidirectional link device 90 includes a switch 91 and a unidirectional link circuit 92 , wherein the switch 91 is coupled to the unidirectional link circuit 92 . Unidirectional link circuit 92 may be, for example, a programmable logic device. A device in the secure field 81 for routine diagnostics or firmware update procedures (eg, Device A Or device B) may be infected with a virus. Therefore, how to prevent the devices in the security field 81 from infecting each other is an important issue in the technical field. In order to prevent the devices in the secure field 81 from infecting each other, the one-way link device 90 may be disposed between the secure field 81 and the non-secure field 82 . Switch 91 of unidirectional link device 90 includes port A, port B, and port C, where port A is coupled to device A in secure domain 81, port B is coupled to device B in secure domain 81, and Port C is coupled to the input of the unidirectional link circuit 92 . The output of the unidirectional link circuit 92 is coupled to the device C. Data from port C can be transmitted to device C via unidirectional link circuit 92 , but data from device C cannot be transmitted to port C via unidirectional link circuit 92 . Thus, data from device A can be transmitted to device C via unidirectional link device 90 , but data from device C cannot be transmitted to device A via unidirectional link device 90 . Data from device B can be transmitted to device C via unidirectional link device 90 , but data from device C cannot be transmitted to device B via unidirectional link device 90 . Unidirectional link device 90 may be configured to separate device A from device B. Since device A cannot communicate with device B, if device A is infected, device A will not infect device B, so viruses or malicious programs cannot be distributed on the security field 81 . However, in some cases, device A may need to exchange data with device B, and the unidirectional link device 90 cannot solve such a problem. Since data cannot be transmitted from device C to device A (or device B), device A and device B cannot exchange data via device C.

Another way to prevent devices in the secure domain 81 from infecting each other is to configure a high-end computer (ie, a firewall) with a large number of Ethernet ports connected to Device A, Device B, and Device C, respectively. Device A can transmit data packets to device B via a high-end computer. The high-end computer will check whether the data packet is secure. If the data packet is safe, the high-end computer will forward the data packet to device B. This method combines delay device A with the Communication between settings B, this is because high-end computers need to implement TCP/IP protocol software for data packets. In addition, high-end computers also need to be protected.

Accordingly, the present disclosure is directed to a method and switch device for VLAN ID based unidirectional transmission. The present disclosure can prevent a device in a secure domain from being attacked by a device in the same secure domain or by a device in a non-secure domain.

The present disclosure is directed to a switch device for virtual area network identifier based unidirectional transmission. The switch device includes a managed switch and a first programmable logic device. The switch includes a first port, a second port, a third port and a controller. The third port is configured to be coupled to the first port via the first path and to the second port via the second path. The controller is coupled to the first port, the second port and the third port. The first programmable logic device is coupled to the third port, wherein the first port receives the first data packet from the first external device; the controller encapsulates the first data packet with the first virtual local area network identifier corresponding to the first path to generate a second data packet; the first programmable logic device receives the second data packet from the third port and filters the second data packet according to the first filtering rule; in response to the second data packet matching the first filtering rule, the first The programmable logic device rewrites the first virtual local area network identifier by the second virtual local area network identifier corresponding to the second path to generate a third data packet; and the first programmable logic device passes through the second path The third data packet is transmitted to the second port for outputting the third data packet through the second port.

In an exemplary embodiment of the present invention, the second data packet includes a destination address, wherein the first programmable logic device stores the mapping table, wherein the first programmable logic device is responsive to the destination address and the second virtual area network Mapping between road identifiers The mapping relationship is recorded in the mapping table, and the first virtual local area network identifier is overwritten by the second virtual local area network identifier.

In an exemplary embodiment of the present disclosure, the first programmable logic device discards the second data packet in response to that the mapping relationship between the destination address and the second virtual area network identifier is not recorded in the mapping table.

In an exemplary embodiment of the present disclosure, the second data packet further includes a frame check sequence, wherein the first programmable logic device is responsive to overwriting the first virtual area network identifier with the second virtual area network identifier And the update frame checks the sequence to generate the third data packet.

In an exemplary embodiment of the present disclosure, the first port receives the address query packet from the first external device and transmits the address query packet to the third port, wherein the address query packet includes an Internet protocol (IP) ) address; the first programmable logic device receives the address query packet from the third port and generates a response packet corresponding to the address query packet; and the first programmable logic device transmits the response packet to the third port through the third port a port.

In an exemplary embodiment of the present disclosure, the first programmable logic device stores a mapping table, wherein the first programmable logic device generates a response packet by: responding to the mapping relationship between the IP address and the MAC address Recording in the mapping table sets the source address of the response packet as a media access control (MAC) address associated with the IP address.

In an exemplary embodiment of the present disclosure, the first programmable logic device generates a response packet by: broadcasting the IP address to the second external device through the second port; The second external device receives a media access control (MAC) address; and sets the source address of the response packet as the MAC address.

In an exemplary embodiment of the present disclosure, the first programmable logic device stores a mapping table, wherein the first programmable logic device associates the IP address with the MAC address in response to receiving the MAC address from the second external device The mapping relationship between them is added to the mapping table.

In an exemplary embodiment of the present disclosure, the first programmable logic device further generates the response packet by setting the target hardware address of the response packet as the MAC address.

In an exemplary embodiment of the present disclosure, the first filtering rule corresponds to at least one of a port number or a transmission protocol, wherein the transmission protocol includes Modbus protocol, IEC 60870-5-101 protocol, distributed network protocol and programmable One of the logical controller contracts.

The present disclosure is directed to a communication method for unidirectional transmission based on a virtual local area network identifier. The communication method includes: coupling the first port of the switch and the third port of the switch via the first path, coupling the second port and the third port of the switch via the second path, and coupling the first programmable logic device and a third port; receiving a first data packet from a first external device by the first port; encapsulating the first data packet with a first virtual local area network identifier corresponding to the first path to generate a second data packet; A programmable logic device receives the second data packet from the third port; the first programmable logic device filters the second data packet according to the first filtering rule; in response to the second data packet matching the first filtering rule, by rewriting the first virtual area network identifier corresponding to the second virtual area network identifier of the second path to generate a third data packet; and transmitting the third data packet by the first programmable logic device via the second path to the second port, so as to output the third data packet through the second port.

In view of the foregoing, the present disclosure may filter multiple devices for use in a secure field The data packets transmitted between the two devices can be transmitted, so the security of the transmission can be guaranteed.

In order to make the foregoing content easier to understand, several embodiments are described in detail below with reference to the drawings.

10: Exchanger device

11, 12, 13, 14, 15, 16, 17: Path

40: Packet format

41, 42: Gateway

43, 44, 45, 50: Devices

61, 62: Storage device

81: Security Field

82: Non-secure field

90: Unidirectional link device

91, 100: Exchanger

92: Unidirectional link circuit

110: Controller

200, 300: Programmable logic device

P1, P2, P3, P4, P5, P6, P7: Port

S301, S302, S303, S304, S305, S306, S307, S308, S309, S310, 0S311, S312, S501, S502, S503, S504, S505, S506, S507: Steps

The accompanying drawings are included to provide a further understanding of the present disclosure, and are incorporated into and constitute a part of this specification. The drawings illustrate exemplary embodiments of the present disclosure, and together with the description serve to explain principles of the present disclosure.

Figure 1 shows a schematic diagram of a unidirectional link arrangement.

FIG. 2 shows a schematic diagram of a switch device according to an embodiment of the present disclosure.

FIG. 3 shows a flowchart of a VLAN ID-based communication method according to an embodiment of the present disclosure.

FIG. 4 shows a schematic diagram of a packet format according to an embodiment of the present disclosure.

FIG. 5 shows a flowchart of a communication method for VLAN ID-based unidirectional transmission according to an embodiment of the present disclosure.

In order to make the present disclosure easier to understand, several embodiments are described below as examples of implementations of the present disclosure. Furthermore, where appropriate, elements/components/steps with the same reference numerals are used in the drawings and the embodiments to refer to the same or similar parts.

FIG. 2 shows a schematic diagram of the switch device 10 according to an embodiment of the present disclosure. The switch device 10 may include a switch (or managed switch) 100 , a programmable logic device (PLD) 200 and a PLD 300 .

Switch 100 may include controller 110, port P1 (also referred to as "first port"), Port P2 (also referred to as the "second port"), port P3, port P4, port P5, port P6 (also referred to as the "fourth port"), and port P7 (also referred to as the "third port"). The controller 110 can determine the routing path between the ports of the switch 100 by configuring a port VLAN ID (port VLAN ID; PVID) for each of the ports. Additionally, the controller 110 can assign ports to VLAN ID groups. Ports belonging to the same VLAN ID group can communicate with each other. Specifically, if the data packet passes through a port with a specific PVID, the data packet may be tagged by the controller 110 with a VLAN ID corresponding to the specific PVID. The switch 100 or the controller 110 can determine the routing path of the data packet according to the VLAN ID of the data packet. After the data packet is received by the other port, if the VLAN ID has not been removed, the other port can identify the path from which the data packet came based on the VLAN ID stored in the VLAN tag column of the data packet.

For example, a default PVID (eg, PVID 1) can be assigned to all ports of switch 100 so that all ports of switch 100 can communicate with each other. That is, the controller 110 may configure all ports to be coupled to each other. However, the final routing path may depend on the destination MAC address of the MAC address table stored in switch 100 . For another example, to assign ports P1 and P6 to a VLAN ID group corresponding to VLAN ID 16, controller 110 may configure the PVIDs of ports P1 and P6 to be PVID 16 corresponding to VLAN ID 16. That is, the controller 110 may configure port P1 to be coupled to port P6 via path 16 . Thus, data packets passing through port P1 can be tagged with VLAN ID 16, and controller 110 can transmit the data packets from port P1 to port P6 via path 16 corresponding to VLAN ID 16. Typically, only data packets traveling inside the switch are marked with PVIDs. The PVID tag is removed when data packets are output from the switch to an external device.

Controller 110 may assign the PVID of port P1 to VLAN ID 11, and Ports P6 and P7 can be configured to join the VLAN ID 11 group. That is, port P1 may be coupled to port P6 via path 16 and may be coupled to port P7 via path 11, where path 11 and path 16 belong to the VLAN ID 11 group. Port P1 may be coupled to a device disposed in secure field 81, such as gateway 41 (or proxy server 41). The controller 110 can assign the PVID of port P2 to VLAN ID 12, and can configure ports P6 and P7 to join the VLAN ID 12 group. That is, port P2 can be coupled to port P6 via path 17 and can be coupled to port P7 via path 12, where path 12 and path 17 belong to the VLAN ID 12 group. Port P2 may be coupled to a device disposed in secure field 81, such as gateway 42 (or proxy server 42). The controller 110 can assign the PVID of port P3 to VLAN ID 13, and can configure port P7 to join the VLAN ID 13 group. That is, port P3 can be coupled to port P7 via path 13 corresponding to the group of VLAN ID 13 . Port P3 may be coupled to a device disposed in secure field 81, such as device 43, where device 43 may include multiple electronic devices or multiple sensors. The controller 110 can assign the PVID of port P4 to VLAN ID 14, and can configure port P7 to join the VLAN ID 14 group. That is, port P4 may be coupled to port P7 via path 14 corresponding to the group of VLAN ID 14 . Port P4 may be coupled to a device disposed in secure field 81, such as device 44, where device 44 may include multiple electronic devices or multiple sensors. The controller 110 can assign the PVID of port P5 to VLAN ID 15, and can configure port P7 to join the VLAN ID 15 group. That is, port P5 may be coupled to port P7 via path 15 corresponding to the group of VLAN ID 15 . Port P5 may be coupled to a device disposed in secure field 81, such as device 45, where device 45 may include multiple electronic devices or multiple sensors.

Port P6 may be coupled to PLD 300, and port P6 may be accessed by a device (eg, a gateway) via port P1 or port P2. Port P7 can be coupled to PLD 200 . in a real In an embodiment, if the VLAN ID is stored in the VLAN tag column of the data packet, the controller may not tag the data packet when the data packet is input to the switch 100 (the route is determined by the VLAN ID at the time of input). For example, assume that data packets transmitted from PLD 200 to port P7 store VLAN IDs. Therefore, the data packet is not tagged with another VLAN ID when passing through port P7. That is, the VLAN IDs of the data packets transmitted from the port P7 to other ports of the switch 100 will not be changed by the controller 110 but can be determined by the PLD 200 . Therefore, the PVID of port P7 does not affect the data routing of switch 100 . In one embodiment, port P6 has been assigned to at least the VLAN ID 11 group and the VLAN ID 12 group. Port P7 has been assigned to at least the VLAN ID 11 group, the VLAN ID 12 group, the VLAN ID 13 group, the VLAN ID 14 group, and the VLAN ID 15 group. Since the data packet will not be input to the switch 100 through the port P6, the PVID of the port P6 will not affect the data routing of the switch 100.

The controller 110 can be, for example, a central processing unit (CPU), a programmable microprocessor, a digital signal processor (DSP), a programmable controller, or an application specific integrated circuit. integrated circuit; ASIC), graphics processing unit (GPU), PLD or other similar elements or combinations thereof. The controller 110 can be coupled to port P1, port P2, port P3, port P4, port P5, port P6 and port P7. The controller 110 may include a storage medium, wherein the storage medium may include, for example, any type of fixed or removable random access memory (RAM), read-only memory (ROM), flash memory A memory, hard disk drive (HDD), solid state drive (SSD), or similar element, or combination thereof, configured to record multiple modules or various applications executed by the controller 110 program.

PLD 200 (or PLD 300 ) may include, for example, optical fibers, diode circuits, RJ45 connectors, programmable array logic (PAL), generic array logic (GAL), complex PLD (complex PLD) ; CPLD), field programmable gate array (field programmable gate array; FPGA) or similar elements or combinations thereof.

Devices in secure domain 81 may transmit data packets to devices in non-secure domain 82 via PLD 300 . For example, if gateway 42 wants to transmit data packets to device 50, gateway 42 can transmit the data packets to PLD 300 via port P2, path 17, and port P6, which can output the data packets to the PLD 300. PLD 300 may forward the data packet to device 50 in response to receiving the data packet from port P6. Specifically, the PLD 300 may store a second filter rule, wherein the second filter rule may limit the direction of the signal passing through the PLD 300 . According to the second filtering rule, PLD 300 can transmit data packets from switch 100 (or port P6 ) to device 50 located in non-secure field 82 , but PLD 300 cannot transmit data packets from device 50 to switch 100 , wherein the device 50 can be an electronic device or a server. Therefore, data packets cannot be sent from the non-secure domain 82 to the secure domain 81 , so the devices in the secure domain 81 will not be attacked by devices in the non-secure domain 82 .

After receiving the data packets from port P6, the PLD 300 can filter the data packets according to the second filtering rule. If the data packet matches the second filtering rule, the PLD 300 may determine to output the data packet to the device 50 . If the data packet does not match the second filter rule, then PLD 300 may determine to discard the data packet, or PLD 300 may determine to transmit the data packet to storage device 62, which may be coupled to PLD 300, for further analysis . In one embodiment, the second filter rule may be associated with a UDP port number or transport protocol. For example, the second filter rule may include port P6 UDP port number. If PLD 300 determines that the data packet received by PLD 300 does not contain a port number that matches the UDP port number of port P6, PLD 300 may discard the data packet or transmit the data packet to storage device 62 . In one embodiment, the transport protocol may be a one-way protocol, such as user datagram protocol (UDP), real time transport protocol (RTP), simple network management protocol (simple network management protocol) ; SNMP) or routing information protocol (routing information protocol; RIP).

A device in secure domain 81 may transmit data packets to another device in secure domain 81 via PLD 200 . For example, if gateway 41 wants to query data from device 44, gateway 41 can transmit data packets to PLD 200 via port P1, path 11, and port P7, which can output data packets to PLD 200 . PLD 200 may forward the data packet to device 44 in response to receiving the data packet from port P7. Specifically, the PLD 200 may pre-store a first filtering rule, wherein the PLD 200 may filter the data packets passing through the PLD 200 according to the first filtering rule. If the data packet from the source device (ie, gateway 41 ) matches the first filter rule, PLD 200 may determine to forward the data packet to the data packet's target device (ie, device 44 ). If the data packet from the source device does not match the first filter rule, PLD 200 may discard the data packet, or PLD 200 may decide to transmit the data packet to storage device 61 for further analysis, where PLD 200 may be coupled to storage device 61 .

In one embodiment, the first filter rule may be associated with a TCP/UDP port number or transport protocol. In one embodiment, the transmission protocol may be a bidirectional protocol such as, but not limited to, protocols such as Modbus, IEC 60870-5-104, distributed network protocol (DNP), or programmable logic controller (Programmable Logic Controller). logic controller; PLC) agreement. For example, the first Filter rules can include TCP/UDP port numbers of data packets. If the PLD 200 determines that the data packet received by the PLD 200 does not contain a port number that matches the TCP/UDP port number of the data packet from port P7, the PLD 200 may discard the data packet or transmit the data packet to the storage device 61. For another example, the first filter rule may be associated with a DNP protocol, where data packets supporting the DNP protocol may have a preamble of 0x27, a header of 0x05, and a header of 0x64. The PLD 200 can determine whether the data packet received from port P7 supports the DNP protocol by checking the preamble and header of the data packet. If the PLD 200 determines that the data packet received from the port P7 does not support the DNP protocol, the PLD 200 may discard the data packet or transmit the data packet to the storage device 61 . For another example, the first filter rule may be associated with the IEC 60870-5-104 protocol, wherein data packets supporting the IEC 60870-5-104 protocol may have a preamble 0x68 and an end code 0x16. The PLD 200 can determine whether the data packet received from port P7 supports the IEC 60870-5-104 protocol by checking the preamble and end code of the data packet. If the PLD 200 determines that the data packet received from port P7 does not support the IEC 60870-5-104 protocol, the PLD 200 may discard the data packet or transmit the data packet to the storage device 61 .

The switch based on IEEE 802.1Q can dynamically update the MAC address table and can perform the internal data transmission of the switch according to the MAC address table. The controller 110 may store a MAC address table of the switch 100, wherein the MAC address table may record the mapping relationship between the ports and the MAC addresses corresponding to the devices coupled to the ports. For example, if port P1 is coupled to gateway 41 , data packets transmitted from gateway 41 to port P1 may include a source address, where the source address may be the MAC address of gateway 41 . The controller 110 can retrieve the MAC address of the gateway 41 from the data packets passing through the port P1. Next, the controller 110 may update the MAC address table according to the MAC address of the gateway 41 , wherein the updated address table may record the mapping relationship between the port P1 and the MAC address of the gateway 41 .

However, since all data packets transmitted between different ports of the switch 100 need to be forwarded through the port P7, the above-mentioned method is not suitable for the switch 100 . Specifically, two data packets with the same source address can be respectively sent to the switch 100 through two different ports. The controller 110 may need to update the previous record of the MAC address table, or treat one of the two data packets as a malformed packet, which may be discarded by the switch 100 . For example, if device 44 wants to transmit a data packet to device 45 , the data packet may be transmitted from device 44 to PLD 200 , where the source address of the data packet may be the MAC address of device 44 . The controller 110 can update the MAC address table to record the mapping relationship between the MAC address of the device 44 and the port P4. In response to receiving the data packets from the device 44, the PLD 200 may filter the data packets according to the first filtering rule. If the data packet matches the first filter rule, PLD 200 may transmit the data packet to device 45 . Since the source address of the data packet is still the MAC address of the device 44, the controller 110 can update the MAC address table to record the mapping relationship between the MAC address of the device 44 and the port P7. Therefore, the switch 100 may consider coupling ports P4 and P7 to devices with the same MAC address. Therefore, the controller 110 needs to rewrite the mapping relationship between the MAC address of the device 44 and the port 4 according to the mapping relationship between the MAC address of the device 44 and the port P7, or discard the self-port P7 (or the self-port P4 ) transmitted data packets. The coupling of more than one device with the same MAC address to different ports of the switch 100 would destroy the basic concept of switch technology.

In order to solve the above-mentioned problems, the present invention discloses a method for internal data transmission of a switch based on a VLAN ID. FIG. 3 shows a flowchart of a VLAN ID-based communication method according to an embodiment of the present disclosure, wherein the communication method may be implemented by the switch device 10 as shown in FIG. 2 . Assume that gateway 41 wants to transmit the first data packet to device 44 . That is, gateway 41 may be the source device, and device 44 may be for the target device.

In step S301, the switch 100 may receive the first data packet from the source device. For example, if the gateway 41 wants to transmit the first data packet to the device 44, the switch 100 may receive the first data packet from the gateway 41 via the port P1.

In step S302, the controller 110 of the switch 100 may encapsulate the first data packet with the first VLAN ID (ie, the PVID of the port) corresponding to the first path to generate the second data packet, and may encapsulate the second data packet Transfer to PLD 200. For example, the controller 110 may encapsulate the first data packet with the VLAN ID 11 (ie, the first VLAN ID or PVID of the port P1) corresponding to the path 11 (ie, the first path), thereby generating the second data packet , and the controller 110 can transmit the second data packet to the PLD 200 via the port P1, the path 11 and the port P7. The controller 110 can obtain the VLAN ID 11 from a preset table, wherein the preset table can be pre-stored in the controller 110 and can include the mapping relationship between the VLAN IDs and the paths of the switch 100 . Table 1 is an example of a preset table. If the data packet entering the switch 100 does not contain a VLAN ID, the controller 110 may encapsulate the data packet with the VLAN ID according to a preset table, wherein the VLAN ID may correspond to the path through which the data packet will pass. If data packets are required to be delivered to the non-secure domain 82, only port P1 (or gateway 41) or port P2 (or gateway 42) can transmit the data packets to the non-secure domain 82 based on VLAN ID 11 or VLAN ID 12 . Data packets delivered to non-secure fields need to meet security criteria. For example, data packets delivered to insecure domain 82 may be converted from bidirectional protocol to unidirectional protocol by gateway 41 or gateway 42 .

4 shows a schematic diagram of a packet format 40 (eg, a standard Ethernet frame) according to an embodiment of the present disclosure. Any data packets transmitted within switch 100 may be formed based on packet format 40 . For example, the controller 110 may encapsulate the first data packet based on the packet format 40 to generate the second data packet. The packet format 40 may include a destination address field, a source address field, a VLAN tag field (eg, 802.1Q tag field), a type/length value field (eg, ether type/length value field), a data field (or payload column) and frame check sequence (FCS) column. The destination address field may store a destination address such as the MAC address of the target device. For example, since the target device of the second data packet is the device 44 , the destination address field of the second data packet can store the MAC address of the device 44 . The source address field may store a source address such as the MAC address of the source device. For example, since the source device of the second data packet is the gateway 41 , the source address field of the second data packet can store the MAC address of the gateway 41 . The VLAN tag column can store a tag protocol identifier (TPID), priority (PRI), canonical format indicator (CFI), or VLAN ID (ie, VID). For example, the controller 110 can generate the second data packet by modifying the VLAN tag column of the first data packet to record the VLAN ID 11 . The Type/Length value field stores the type of data packet. For example, in FIG. 4, if the packet format 40 corresponds to an address resolution protocol (ARP) data packet, the type/length value column may store "0x0806". The data field can store the sender's hardware address (eg, the source device's MAC address), the sender's protocol address (eg, the source's IP address), and the target hardware address (eg, the target's MAC address) or the target contract address (e.g. target IP address of the device). For example, the data field of the second data packet may include the MAC address of the gateway 41 as the sender's hardware address, the IP address of the gateway 41 as the sender's protocol address, and the device 44 as the target hardware address The MAC address of the address and the IP address of the device 44 as the target protocol address. In one embodiment, the target agreement address may be blank. For example, the target agreement address of the ARP query may be blank and the destination address of the ARP query may be the broadcast address (eg, 0xFF). The FCS column can store the FCS value (or cyclic redundancy check (CRC) code) corresponding to the data column. The FCS value can be calculated from the data column. If the data in the data column changes, the FCS value can be changed accordingly. For example, in response to generating the second data packet, the controller 110 may modify the data column of the first data packet to include the VLAN ID 11 . That is, the FCS value of the second data packet should be different from the FCS value of the first data packet. The controller 110 may calculate the FCS value of the second data packet according to the modified data field.

Referring back to FIG. 3, in step S303, in response to receiving the second data packet, the PLD 200 may determine whether the second data packet is an address query packet (or an ARP packet), wherein the address query packet may be, for example, an ARP query. Specifically, the data column of the second data packet can further store the ARP indicator in the operation column (for example, the ether type "0x0806"). The ARP indicator can indicate whether the second data packet is an address query packet. In response to receiving the second data packet from the port P7, the PLD 200 can determine whether the second data packet is an address query packet (or an ARP packet) according to the operation field of the second data packet. If the second data packet is an address query packet, proceed to step S308. If the second data packet is not an address query packet (or an ARP packet), the process proceeds to step S304.

In step S304, the PLD 200 may filter the second data packet and determine the first 2. Whether the data packet matches the mapping table. If the second data packet matches the mapping table, go to step S306. If the second data packet does not match the mapping table, proceed to step S305. Specifically, the PLD 200 can filter the second data packet according to the first filtering rule. The first filter rule may be associated with a TCP/UDP port number or transport protocol. In addition, the filtering rule may include a mapping table, wherein the mapping table may include a mapping relationship between MAC addresses and VLAN IDs. In one embodiment, the mapping table may further include IP addresses corresponding to MAC addresses and VLAN IDs. The PLD 200 may determine that the second data packet matches the mapping table in response to the mapping relationship between the destination address of the second data packet and the VLAN ID of the second data packet being recorded in the mapping table. The PLD 200 may determine that the second data packet does not match the mapping table in response to the fact that the mapping relationship between the destination address of the second data packet and the VLAN ID of the second data packet is not recorded in the mapping table. Table 2 is an example of a mapping table stored in the PLD 200 . The mapping table can record the mapping relationship between the MAC address of the gateway 41 and the VLAN ID 11 . It is assumed that the data column of the second data packet stores VLAN ID 11. The PLD 200 can determine that if the source address of the second data packet is the MAC address of the gateway 41, the second data packet matches the mapping table, and the PLD 200 can determine that if the source address of the second data packet is not the gateway 41 , the second data packet does not match the mapping table.

In step S305, the PLD 200 may discard the second data packet or may transmit the second data packet to the storage device 61 for further analysis.

In step S306, the PLD 200 may rewrite the first VLAN ID of the second data packet by the second VLAN ID corresponding to the second path, thereby generating a third data packet, wherein the second VLAN ID may correspond to the PLD 200 and the Path between target devices. That is, the PLD 200 can select the second VLAN ID from the mapping table according to the destination address of the second data packet. For example, PLD 200 may rewrite VLAN ID 11 in the second data packet by VLAN ID 14 to generate a third data packet, where VLAN ID 14 may correspond to the connection between PLD 200 and device 44 (ie, the target device) Path 14.

In response to overwriting the first VLAN ID of the data column with the second VLAN ID, the PLD 200 may recalculate the FCS value of the third data packet according to the updated data column. In other words, the PLD 200 can update the FCS value of the second data packet to generate the third data packet.

In step S307, the PLD 200 may transmit the third data packet to the target device. For example, PLD 200 may transmit the third data packet to device 44 via port P7, path 14, and port P4.

In step S308, the PLD 200 may determine whether the second data packet matches the mapping table. If the second data packet matches the mapping table, proceed to step S312. If the second data packet does not match the mapping table, proceed to step S309. Specifically, the PLD 200 may store a mapping table, wherein the mapping table may include a mapping relationship among MAC addresses, IP addresses, and VLAN IDs. If the second data packet is an address query packet, the sending end hardware address, the sending end protocol address and the destination protocol address of the second data packet can be filled by the source device, and the source device can store the destination hardware address of the second data packet Body address is left blank. In other words, the MAC address of the target device is unknown to the second data packet. The PLD 200 can check the mapping between the IP address and MAC address of the target device Whether the mapping relationship is recorded in the mapping table. The PLD 200 may determine that the second data packet matches the mapping table in response to the mapping relationship between the IP address and the MAC address of the target device being recorded in the mapping table, and the PLD 200 may respond to the IP address and the MAC address of the target device The mapping relationship between the addresses is not recorded in the mapping table, and it is determined that the second data packet does not match the mapping table.

Table 3 is an example of a mapping table stored in PLD 200. Mapping tables may be added in response to data packets received by PLD 200 . IP address, VLAN ID and MAC address can be recorded in the mapping table. For example, after connecting to switch 100, a network device may publish a broadcast packet (eg, an ARP reply) to an internal network device (eg, a device coupled to switch 100), thereby informing the internal network device The hardware address and software address of the network device. In response to receiving the broadcast packet, the PLD 200 may add the mapping relationship between the IP address of the network device and the MAC address of the network device to the mapping table. In one embodiment, the second data packet transmitted from the gateway 41 to the PLD 200 may include the MAC address of the gateway 41, the IP address of the gateway 41, and the IP address of the target device. The PLD 200 may determine whether the mapping relationship between the IP address and the MAC address of the target device is recorded in Table 3. Since the mapping relationship between the IP address of the target device and the MAC address of the device 44 is recorded in Table 3, the PLD 200 can determine that the IP address of the target device corresponds to the device 44 . Therefore, the PLD 200 can determine that the second data packet matches the mapping table.

Table 4 is an example of a mapping table stored in PLD 200. The second data packet transmitted from the gateway 41 to the PLD 200 may include the MAC address of the gateway 41, the gateway 41 and the IP address of the target device. The PLD 200 can determine whether the mapping relationship between the IP address and the MAC address of the target device is recorded in Table 4. Since the mapping relationship between the IP address and the MAC address of the target device is not recorded in Table 4, the PLD 200 can determine that the second data packet does not match the mapping table.

In step S309 , the PLD 200 may broadcast the IP address of the target device to one or more external devices coupled to the switch 100 . For example, PLD 200 may duplicate the second data packet to generate a plurality of broadcast data packets, where each of the broadcast data packets may include the IP address and private VLAN ID of the target device. That is, different broadcast data packets may have different VLAN IDs. For example, PLD 200 may generate a broadcast data packet from the second data packet and transmit the broadcast data packet to device 44 via port P4, wherein the broadcast data packet may include the IP address and VLAN ID 14 of the target device. Similarly, PLD 200 may generate a broadcast data packet from the second data packet and transmit the broadcast data packet to device 43 via port P3, wherein the broadcast data packet may include the IP address and VLAN ID 13 of the target device. The PLD 200 may generate a broadcast data packet according to the second data packet and transmit the broadcast data packet to the gateway 42 via the port P2, wherein the broadcast data packet may include the IP address and the VLAN ID 12 of the target device. The PLD 200 can generate a broadcast data packet according to the second data packet and transmit the broadcast data packet to the device 45 via the port P5, wherein the broadcast data packet can include the IP address and the VLAN ID 15 of the target device.

In step S310, PLD 200 may receive a MAC address from the target device (ie, device 44) in response to broadcasting the IP address of the target device, and PLD 200 may A response packet corresponding to the second data packet (ie, the address query packet) is generated, wherein the target device is one of the one or more external devices that receive the broadcast data packet. Specifically, it is assumed that the IP address of the target contained in the broadcast data packet is equal to the IP address of device 44 . That is, device 44 is the target device of the second data packet. Thus, device 44 may transmit the MAC address of device 44 to PLD 200 via port P4, path 14, and port P7 in response to receiving the broadcast data packet. After receiving the MAC address of the device 44, the PLD 200 may set the source address of the response packet to the received MAC address. For example, PLD 200 may set the source address of the response packet to be the MAC address of device 44 . In addition, the PLD 200 may set the destination address of the response packet as the source address of the second data packet. For example, the second data packet may include the MAC address of the gateway 41 as the source address. The PLD 200 may set the destination address of the response packet as the MAC address of the gateway 41 . In addition, the PLD 200 may set the target hardware address of the response packet as the received MAC address, wherein the target hardware address is included in the data field of the response packet, and the target hardware address is not yet filled in the second data packet information. For example, the PLD 200 may set the target hardware address of the response packet as the MAC address of the device 44, which has not been stored in the second data packet.

In one embodiment, in response to receiving the MAC address from the target device, the PLD 200 may add the mapping relationship between the IP address of the target device and the MAC address of the target device to the mapping table. For example, assume that the mapping table currently stored in the PLD 200 is Table 4. In response to receiving the MAC address from device 44 as feedback from the broadcast data packet, PLD 200 may determine that the IP address of the target device corresponds to the MAC address of device 44 . Accordingly, PLD 200 may add to Table 4 the relationship between the IP address of the target device and the MAC address of device 44 . Therefore, Table 4 can be modified by PLD 200 for Table 3.

In step S311, the PLD 200 may transmit a response packet to the source device (ie, the gateway 41), wherein the response packet may be an ARP response corresponding to an ARP query. Specifically, the PLD 200 can transmit the response packet to the gateway 41 via the port P7, the path 11 and the port P1.

In step S312, the PLD 200 may generate a response packet corresponding to the second data packet (ie, the address query packet) according to the mapping table. Specifically, the PLD 200 may set the source address of the response packet to the MAC address associated with the IP address of the target device. Taking Table 3 as an example, in response to the mapping relationship between the IP address of the target device and the MAC address of the device 44 being recorded in Table 3, the PLD 200 can determine that the IP address of the target device is related to the MAC address of the device 44 link. Therefore, the PLD 200 can set the source address of the response packet as the MAC address of the device 44 according to the mapping table. That is, the IP address of the target device may not need to be broadcast to the actual target device (ie, device 44) in order to obtain the MAC address of the target device. After receiving the ARP query from the source device, PLD 200 may generate an ARP response corresponding to the ARP query based on the established mapping table. The steps of duplicating the ARP query or broadcasting the ARP query can be omitted. Therefore, the source device can obtain the IP address of the target device in a shorter time.

In addition, the PLD 200 may set the destination address of the response packet as the source address of the second data packet. For example, the second data packet may include the MAC address of the gateway 41 as the source address. The PLD 200 may set the destination address of the response packet as the MAC address of the gateway 41 . In addition, the PLD 200 may set the target hardware address of the response packet as the MAC address associated with the IP address of the target device, wherein the target hardware address is included in the data field of the response packet, and the target hardware address is not yet Information populated in the second data packet. For example, PLD 200 may determine device 44 The MAC address is associated with the IP address of the target device. Therefore, the PLD 200 can set the target hardware address of the response packet as the MAC address of the device 44 .

5 shows a flowchart of a communication method for VLAN ID-based unidirectional transmission according to an embodiment of the present disclosure, wherein the communication method may be implemented by the switch device 10 as shown in FIG. 1 . In step S501, the first port of the switch and the third port of the switch are coupled via the first path, the second port and the third port of the switch are coupled via the second path, and the first programmable logic is coupled device and the third port. In step S502, the first data packet is received from the first external device by the first port. In step S503, the first data packet is encapsulated with the first virtual area network identifier corresponding to the first path to generate a second data packet. In step S504, the first programmable logic device receives the second data packet from the third port. In step S505, the second data packet is filtered by the first programmable logic device according to the first filtering rule. In step S506, in response to the second data packet matching the first filtering rule, rewrite the first virtual local area network identifier with the second virtual local area network identifier corresponding to the second path to generate a third data packet . In step S507, the first programmable logic device transmits the third data packet to the second port through the second path, so as to output the third data packet through the second port.

In conclusion, the present disclosure can reduce the delay of one-way transmission between the secure domain and the non-secure domain by configuring the switch device instead of the high-end computer to connect the secure domain and the non-secure domain. In contrast to high-end computers, when a data packet is forwarded using a predefined protocol, the switch device may not need to retrieve all the contents of the data packet (eg, each layer of the protocol stack of the data packet). The switch device may include a PLD that may filter data packets for transmission between devices in the secure domain. Before forwarding the filtered data packet to the destination, the PLD can update the data packet's VLAN ID, thus preventing data packets from breaking the rules defined by the switch's address table. On the other hand, the PLD may establish or update a mapping table (eg, an ARP table) including the mapping relationship between the IP address and the MAC address of the target device. If the source device transmits an ARP query to the target device, the PLD may reply with an ARP response to the source device of the target device. Therefore, the ARP query may not need to be forwarded to the target device and the source device can obtain the MAC address of the target device in a shorter time.

No element, act, or instruction used in the detailed description of the disclosed embodiments of the present application should be construed as critical or essential to the present disclosure unless explicitly described as such. Furthermore, as used herein, each of the indefinite articles "a (a)" and "an (an)" may include more than one item. If only one item is expected, the term "single" or similar language will be used. Further, as used herein, the term "any of" preceding a list of items and/or categories of items is intended to include the item and/or the category of items (either individually or in combination with other items) and/or other item categories) "Any of," "Any combination of," "Any of," and/or "Any combination of, of." Furthermore, as used herein, the term "collection" is intended to encompass any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero.

It will be apparent to those of ordinary skill in the art that various modifications and variations of the disclosed embodiments can be made without departing from the scope or spirit of the present disclosure. In view of the foregoing, this disclosure is intended to cover modifications and variations, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

S501, S502, S503, S504, S505, S506, S507: Steps

Claims (11)

A switch device for unidirectional transmission based on a virtual local area network identifier, comprising: switches, including: the first port; the second port; a third port configured to be coupled to the first port via a first path and to the second port via a second path; and a controller coupled to the first port, the second port and the third port; and a first programmable logic device coupled to the third port, wherein the first port receives a first data packet from a first external device; the controller encapsulates the first data packet with a first virtual area network identifier corresponding to the first path to generate a second data packet; the first programmable logic device receives the second data packet from the third port and filters the second data packet according to a first filtering rule; In response to the second data packet matching the first filter rule, the first programmable logic device overwrites the first with a second virtual area network identifier corresponding to the second path a virtual local area network identifier to generate the third data packet; and The first programmable logic device transmits the third data packet to the second port through the second path so as to output the third data packet through the second port. The switch device of claim 1, wherein the second data packet includes a destination address, wherein the first programmable logic device stores a mapping table, wherein The first programmable logic device records the mapping relationship between the destination address and the second virtual local area network identifier in the mapping table through the second virtual local area network The identifier overrides the first virtual area network identifier. The switch device of claim 2, wherein the first programmable logic device responds that the mapping relationship between the destination address and the second virtual area network identifier is not recorded in the into the mapping table and discard the second data packet. The switch device of claim 2, wherein the second data packet further includes a frame check sequence, wherein the first programmable logic device responds to overwriting by the second virtual area network identifier The frame check sequence is updated by the first virtual area network identifier to generate the third data packet. The switch device of claim 1, wherein the first port receives an address query packet from the first external device and transmits the address query packet to the third port, wherein the address query packet includes an internet protocol address; the first programmable logic device receives the address query packet from the third port and generates a response packet corresponding to the address query packet; and The first programmable logic device transmits the response packet to the first port via the third port. The switch device of claim 5, wherein the first programmable logic device stores a mapping table, wherein the first programmable logic device generates the response packet by: In response to the mapping relationship between the IP address and the MAC address being recorded in the mapping table, the source address of the response packet is set to be the same as the IP address the associated media access control address. The switch device of claim 5, wherein the first programmable logic device generates the response packet by: broadcasting the Internet Protocol address to a second external device via the second port; receiving a media access control address from the second external device via the second port in response to broadcasting the internet protocol address; and Setting the source address of the response packet as the MAC address. The switch device of claim 7, wherein the first programmable logic device stores a mapping table, wherein the first programmable logic device is responsive to receiving the media access from the second external device The mapping relationship between the Internet Protocol address and the MAC address is added to the mapping table by controlling the address. The switch device of claim 6, wherein the first programmable logic device further generates the response packet by: The target hardware address of the response packet is set as the MAC address. The switch device of claim 1, wherein the first filtering rule corresponds to at least one of a port number or a transmission protocol, wherein the transmission protocol includes Modbus protocol, IEC 60870-5-104 protocol, decentralized One of a network protocol and a programmable logic controller protocol. A communication method for unidirectional transmission based on a virtual local area network identifier, comprising: The first port of the switch and the third port of the switch are coupled via a first path, the second port of the switch and the third port are coupled via a second path, and the first programmable port is coupled via a second path a logic device and the third port; receiving, by the first port, a first data packet from a first external device; encapsulating the first data packet with a first virtual area network identifier corresponding to the first path to generate a second data packet; receiving, by the first programmable logic device, the second data packet from the third port; filtering the second data packet by the first programmable logic device according to a first filtering rule; In response to the second data packet matching the first filter rule, rewriting the first virtual area network identifier with the second virtual area network identifier corresponding to the second path to generate a first virtual area network identifier three data packets; and The third data packet is transmitted by the first programmable logic device to the second port via the second path so as to output the third data packet via the second port.

Images