JP6332497B2 - Process control system and data transfer method - Google Patents

Description

  The present invention relates to a process control system and a data transfer method.

  Generally, a network device (for example, a switch) constituting a network includes an access control list (ACL), and performs data transfer control with reference to the contents of the access control list. . In the above-mentioned access control list, abstract contents (for example, a transmission destination address and a software port number) can be set regardless of the specific configuration of the network. The contents of such an access control list can be set by, for example, a Linux (registered trademark) command “iptables”.

  In recent years, it has been called OpenFlow developed based on the concept of “Software-Defined Network” that controls the network by programming to enable complex transfer control and flexible network configuration changes. Technology is being used. This OpenFlow is a flow in which a network device constituting a network is separated into a route control device (OFC: OpenFlow Controller) and a data transfer device (OFS: OpenFlow Switch), and the route control device is provided in the data transfer device. Transfer control is performed by collectively managing a table (FlowTable).

  Here, the flow table used in the above OpenFlow can describe the access control list described above, and there are conditions for performing transfer control (match), processing to be executed when the conditions are met (Action), etc. It is a table in which associated information is stored. The following Patent Document 1 discloses an example of a conventional technique for performing transfer control with reference to an access control list.

JP 2007-74383 A

  By the way, in an environment called a critical infrastructure such as a plant, there is a demand for strictly controlling communication performed via a network in order to ensure security. For example, basically, all communication is rejected, and whitelist control is required such that only communication of a specific application between specific devices explicitly specified is permitted.

  Here, as described above, a network device that performs transfer control using an access control list (hereinafter referred to as “conventional network device”) sets abstract contents such as a destination address in the access control list. Is possible. Therefore, even if the network administrator does not know the specific configuration of the network, it is possible to create an access control list as a white list and perform strict transfer control.

  However, the setting of the access control list in the conventional network device must be performed using a command depending on the vendor and model of the network device. For this reason, in a network in which network devices provided by various vendors are mixed, the access control list must be set using a command suitable for the network device to be set, and complicated management is required. There is a problem that it is difficult to perform strict transfer control in a timely manner.

  On the other hand, a network device compliant with the above-described OpenFlow specification can set a flow table with a unified protocol. For this reason, it is not necessary to use commands depending on the above-mentioned models, and management is simplified. Even in a network in which network devices provided by various vendors are mixed, strict transfer control is performed in a timely manner. It seems possible to do.

  However, the flow table has a part that must be described based on the specific configuration of the network. For example, when the processing (Action) to be performed when the transfer control condition is met is data transmission (output), it is necessary to describe the physical port of the data transfer device that outputs the data. For this reason, there is a problem that the network administrator cannot create a flow table unless the network configuration (specific connection status) is grasped in advance.

  In addition, when introducing a network device that conforms to the OpenFlow specification to a network that is composed of conventional network devices, the existing network device and the network device that conforms to the OpenFlow specification are mixed. It is possible to become. In such a situation, since different management is required for each network device, there is a problem that management becomes more complicated.

  The present invention has been made in view of the above circumstances, and performs strict transfer control in a timely manner even if the specific configuration of the network is not grasped in advance or the specific configuration device is replaced during operation. It is an object of the present invention to provide a data transfer system and method that can be used.

In order to solve the above-described problems, a process control system including a data transfer system of the present invention includes a data transfer system that performs operation control of a plant and transfers data transmitted from a transmission source toward a transmission destination. In the process control system, the data transfer system includes first information indicating a condition that defines whether or not the information regarding the transmission destination and the transmission source in the received data is matched, and the reception only when the condition is met. The level defined by the international standard IEC / ISO 62264 for performing the transfer processing of the received data with reference to the table in which the second information indicating the communication port of the own device is associated with the received data. One or more data transfers that are installed between the level 3 and level 4 levels or within the level 3 level If the path between the transmission source and the transmission source and the transmission destination is unknown, information indicating that data suitable for the condition indicated by the first information should be output to the own device is the second information. When the stored temporary table is set in the data transfer device and the route information indicating the route between the transmission source and the transmission destination is obtained, the temporary table is changed based on the route information. A routing control device that updates the information and the second information to a changed table, and the data transfer device and the routing control device comply with or similar to an open flow specification, and the routing The control device includes a condition list that defines conditions for controlling transfer of data from a transmission source to a transmission destination, and the temporary table set in the data transfer device that conforms to the OpenFlow specification using the condition list. It is characterized in that and a generator capable of generating an access control list for use in a non-compliant transfer device that does not conform to an open flow specification.
According to the present invention, a temporary table storing information indicating that data suitable for a condition should be output to the control device is set in the transfer device, and route information indicating a route between the transmission source and the transmission destination is obtained. In such a case, the temporary table is updated to a table in which the output destination of data that meets the above conditions is changed based on the path information.
In the process control system including the data transfer system of the present invention, the control device first sends the transmission information from the transmission source to the transmission destination after the route information is obtained or after the route information is obtained. The temporary table is updated at a timing when data is transmitted.
In the process control system including the data transfer system of the present invention, the table set in the transfer device has a priority set, and the control device sets the temporary table as the temporary table. It is characterized in that it is updated to a table in which a higher priority than the priorities is set.
The process control system including the data transfer system according to the present invention is characterized in that the table or the temporary table used in the transfer apparatus can set a finite lifetime or an infinite lifetime.
The process control system including the data transfer system according to the present invention is characterized in that the control device performs at least one of setting and deletion of the temporary table with respect to the transfer device according to a predetermined schedule.
Further, in the process control system including the data transfer system of the present invention, the transfer device has a plurality of queues having different bandwidths for each port, and the temporary table is updated for each port when the temporary table is updated. The queue is selectable.
In the process control system for controlling the operation of the plant according to the present invention, the data transfer method for transferring the data transmitted from the transmission source toward the transmission destination is when the path between the transmission source and the transmission destination is unknown. A first information indicating a condition for defining whether or not the information relating to the transmission destination and the transmission source in the received data conforms, and the communication port of the own device for outputting the received data only conforming to the condition A first step in which the routing control device sets the temporary table associated with the second information indicating the received data in one or more data transfer devices that perform the transfer processing of the received data, and the transmission source and the transmission destination After the route information indicating the route between the route information and the route information is obtained, the route control device updates the temporary table to a table in which the first information and the second information are changed based on the route information. The data transfer device includes first information indicating a condition that defines whether or not the information regarding the transmission destination and the transmission source in the received data is matched, and when the condition is met In accordance with the international standard IEC / ISO 62264 for performing a transfer process of received data with reference to a table associated with second information indicating a communication port included in the own device that outputs the received data only It is installed between the level 2 hierarchy and the level 3 hierarchy specified, installed between the level 3 hierarchy and the level 4 hierarchy, or installed within the level 3 hierarchy. It is a feature.
In the data transfer method of the present invention, the second step transmits data from the transmission source to the transmission destination first when the route information is obtained, or after the route information is obtained. It is characterized by being performed at the timing.

  According to the present invention, a temporary table storing information indicating that data suitable for a condition should be output to the control device is set in the transfer device, and route information indicating a route between the transmission source and the transmission destination is obtained. If it is obtained, the temporary table is updated so that the output destination of data that conforms to the above conditions has been changed based on the route information, so the specific configuration of the network may not be known in advance. Alternatively, even if a specific component device is replaced during operation, there is an effect that strict transfer control can be performed in a timely manner.

It is a block diagram which shows the principal part structure of the data transfer system by 1st Embodiment of this invention. It is a figure which shows an example of the temporary flow table used by 1st Embodiment of this invention. It is a figure which shows an example of the flow table used by 1st Embodiment of this invention. It is a timing chart which shows an example of operation | movement of the data transfer system by 1st Embodiment of this invention. It is a figure explaining the process control system to which the data transfer system by 1st Embodiment of this invention is applied. It is a block diagram which shows the principal part structure of the data transfer system by 2nd Embodiment of this invention. It is a block diagram which shows the principal part structure of OFS used with the data transfer system by 3rd Embodiment of this invention. It is a figure which shows the modification of OFS used with the data transfer system by embodiment of this invention.

Hereinafter, a data transfer system and method according to embodiments of the present invention will be described in detail with reference to the drawings.

[First Embodiment]
FIG. 1 is a block diagram showing a main configuration of the data transfer system according to the first embodiment of the present invention. As shown in FIG. 1, the data transfer system 1 of the present embodiment includes OFS (OpenFlow Switch: transfer device) 11, 12 and OFC (OpenFlow Controller: control device) 20, and under the control of the OFC 20, The OFSs 11 and 12 transfer data transmitted from the transmission source toward the transmission destination. In FIG. 1, for ease of understanding, the data transfer system 1 including two OFSs 11 and 12 is illustrated, but the number of OFS provided in the data transfer system 1 is arbitrary.

  In the following, in order to facilitate understanding, it is assumed that the host H1 is a data transmission source and the host H2 is a data transmission destination. The host H1 is a DNS (Domain Name System) client to which an IP (Internet Protocol) address “10.0.0.9” is assigned, and the host H2 is “10.0.0.1”. It is assumed that the DNS server is assigned an IP address. These hosts H1 and H2 are realized by, for example, a notebook computer, a desktop computer, a tablet computer, or other computers.

  The OFSs 11 and 12 include a plurality of physical ports P1 to P12, and perform transfer processing of received data under the control of the OFC 20. Specifically, the OFSs 11 and 12 store flow tables TB1 and TB2 (tables: see FIGS. 2 and 3) collectively managed by the OFC 20 in a memory (not shown), and the flow tables TB1 and TB2 The data is transferred by a transfer unit (not shown) with reference to FIG. Details of the flow tables TB1 and TB2 will be described later.

  As shown in FIG. 1, the host H1 is connected to the physical port P1 of the OFS 11, the host H2 is connected to the physical port P6 of the OFS 12, and the physical port P12 of the OFS 11 and the physical port P7 of the OFS 12 are connected. Has been. Thereby, a network N1 for data transfer is constructed between the host H1 and the host H2. The OFSs 11 and 12 are connected to the OFC 20 via control ports (not shown) different from the physical ports P1 to P12, thereby constructing a network N2 for open flow control. The number of physical ports provided in the OFSs 11 and 12 is arbitrary.

  The OFC 20 controls transfer of data transferred via the network N1 by collectively managing the flow tables TB1 and TB2 used in the OFSs 11 and 12. Specifically, if the path between the hosts H1 and H2 is unknown, the OFC 20 uses the temporary flow table TB0 (temporary table: see FIG. 2) stored in the memory (not shown) as the flow table TB1, TB2 is set in OFS 11 and 12, respectively, and data transfer control is performed by a control unit (not shown). When the path information indicating the path between the hosts H1 and H2 is obtained, the OFC 20 uses the temporary flow table TB0 as the flow tables TB1 and TB2 whose contents are updated based on the path information (FIG. 3). Update the data to (see) and perform data transfer control. The provisional flow table TB0 is set and updated in order to perform whitelist-like strict transfer control in a timely manner without knowing the specific configuration of the network N1 in advance.

  Next, a flow table managed by the OFC 20 will be described. FIG. 2 is a diagram illustrating an example of a temporary flow table used in the first embodiment of the present invention. FIG. 3 is a diagram showing an example of a flow table used in the first embodiment of the present invention. As shown in FIGS. 2 and 3, the temporary flow table TB0 and the flow tables TB1 and TB2 perform transfer control for a field storing a priority (Priority) for each entry specified by an entry number (ID). It is a table provided with a field for storing a condition (match: first information) and a field for storing a process (Action: second information) to be executed when the condition is matched. Note that the above-mentioned priority defines the priority of an entry, and an entry storing a priority having a large value is given priority.

The provisional flow table TB0 illustrated in FIG. 2 includes two entries whose priority is set to “1000”. In the entry whose ID is “1”, the following information is stored as conditions and processes.
[conditions]
-Source address (SADDR) = “any (arbitrary)”
・ Destination address (DADDR) = “10.0.0.1”
Protocol (PROTOCOL) = “UDP (User Datagram Protocol)”
-Source port number (SPORT) = "any"
・ Destination port number (DPORT) = “53 (port number used in DNS)”
[processing]
・ Output
Physical port (Port) = “Ctrl”

Further, the following information is stored in the entry whose ID is “2” as a condition and a process.
[conditions]
-Source address (SADDR) = “10.0.0.1”
・ Destination address (DADDR) = “any”
・ Protocol (PROTOCOL) = "UDP"
-Source port number (SPORT) = “53”
-Destination port number (DPORT) = "any"
[processing]
・ Output
Physical port (Port) = “Ctrl”

  That is, the entry whose ID is “1” stores information “UDP data (datagram) whose transmission destination is the 53rd port of the host H2” as a condition, The information “output in (Ctrl)” is stored. In addition, the entry whose ID is “2” stores information “UDP data (datagram) whose transmission source is the 53rd port of the host H2” as a condition. Is stored. That is, the temporary flow table TB0 stores information indicating that data suitable for the condition should be output to the OFC 20 connected to a control port (not shown) provided in the OFSs 11 and 12.

  In addition, the flow tables TB1 and TB2 illustrated in FIG. 3 are provided with two entries whose priority is set to “1000” and two entries whose priority is set to “2000”, respectively. . Two entries (IDs “1” and “2” with IDs “1” and “2”) in which priority of the flow tables TB1 and TB2 is set to “1000” are included in the two entries (IDs “1”). ”And“ 2 ”) are stored.

The following information is stored as conditions and processes in one of the entries whose priority is set to “2000” (the entry whose ID is “3”) in the flow table TB1.
[conditions]
-Source address (SADDR) = “10.0.0.9”
・ Destination address (DADDR) = “10.0.0.1”
・ Protocol (PROTOCOL) = "UDP"
-Source port number (SPORT) = "any"
・ Destination port number (DPORT) = “53”
[processing]
・ Output
-Physical port (Port) = "12"

In addition, the following information is stored as conditions and processes in the other entry (the entry whose ID is “4”) whose priority is set to “2000” in the flow table TB1.
[conditions]
-Source address (SADDR) = “10.0.0.1”
・ Destination address (DADDR) = “10.0.0.9”
・ Protocol (PROTOCOL) = "UDP"
-Source port number (SPORT) = “53”
-Destination port number (DPORT) = "any"
[processing]
・ Output
-Physical port (Port) = "1"

  That is, an entry whose ID is “3” in the flow table TB1 includes, as a condition, information “UDP data (datagram) whose transmission source is the host H1 and whose transmission destination is the port 53 of the host H2”. The information “output to physical port P12” is stored as processing. In addition, an entry whose ID is “4” in the flow table TB1 includes, as a condition, information “UDP data (datagram) whose transmission source is the port 53 of the host H2 and whose transmission destination is the host H1”. The information “output to the physical port P1” is stored as processing. That is, the flow table TB1 stores information indicating a physical port that should output data in accordance with an actual path between the hosts H1 and H2 among the plurality of physical ports P1 to P12 provided in the OFS 11. Yes.

  Similarly, an entry whose ID is “3” in the flow table TB2 includes information “UDP data (datagram) whose transmission source is the host H1 and transmission destination is the 53rd port of the host H2” as a condition. Is stored, and information “output to physical port P6” is stored as processing. Further, an entry whose ID is “4” in the flow table TB2 includes information “UDP data (datagram) whose transmission source is the port 53 of the host H2 and whose transmission destination is the host H1” as a condition. The information “output to physical port P7” is stored as processing. That is, the flow table TB2 stores information indicating a physical port that should output data according to an actual path between the hosts H1 and H2 among the plurality of physical ports P1 to P12 provided in the OFS 12. Yes.

  Here, in the flow tables TB1 and TB2 illustrated in FIG. 3, the priority is “2000” rather than the two entries (IDs whose IDs are “1” and “2”) whose priority is set to “1000”. Two entries (IDs whose IDs are “3” and “4”) set to “” are prioritized. Therefore, when the flow tables TB1 and TB2 illustrated in FIG. 3 are used, data transfer processing is performed in accordance with the actual path between the hosts H1 and H2.

  Next, the operation of the data transfer system 1 having the above configuration will be described. FIG. 4 is a timing chart showing an example of the operation of the data transfer system according to the first embodiment of the present invention. Note that the processing shown in FIG. 4 is started, for example, when the network N1 is newly constructed, when the network N1 is changed, or when there is an instruction from the administrator of the network N1.

  When the process is started, a message (Flow_Mod message) is first transmitted from the OFC 20 to the OFSs 11 and 12 through the network N2, and a process of registering a white list that is a condition for permitting communication through the network N1 is performed ( Step S10: First step). Specifically, the temporary flow table TB0 (a table storing information indicating that data that meets the conditions should be output to the OFC 20) shown in FIG. 2 is set in the OFSs 11 and 12 as the flow tables TB1 and TB2, respectively. Processing is performed.

  When the above processing is completed, in order to obtain the MAC (Media Access Control) address of the host H2 as the DNS server, an Arp (Address Resolution Protocol) request is broadcast from the host H1 as the DNS client (step S11). The Arp request broadcast by the host H1 is received by the OFS 11 and then output to a control port (Ctrl) (not shown) according to a predetermined rule, and is transmitted to the OFC 20 as a message (Packet_In message) via the network N2. (Step S12).

  Here, the message (Packet_In message) transmitted from the OFS 11 includes information specifying the OFS and port to which the host H1 that broadcasts the Arp request is connected. For this reason, the OFC 20 performs a process of recording information indicating the connection position of the host H1 (information indicating that the host H1 is connected to the physical port P1 of the OFS 11) (step S13).

  In addition, when a message (Packet_In message) is received from the OFS 11, the OFC 20 performs a process of transmitting a message (a Flood message indicating that an Arp request should be broadcast) to the OFSs 11 and 12 via the network N2 (steps). S14). This process is performed because it is unclear to which of the OFSs 11 and 12 the host H2 to which the Arp request is to be transmitted. Thereby, in the OFSs 11 and 12, a process of broadcasting an Arp request from all the physical ports whose connection relation is unknown (physical ports P2 to P11 of the OFS 11 and physical ports P1 to P6 and P8 to P12 of the OFS 12) is performed ( Step S15).

  When the above processing is performed, the Arp request from the host H1 is received by the host H2 connected to the physical port P6 of the OFS 12. As a result, the host H2 transmits an Arp reply as a reply to the Arp request (step S16). The Arp reply transmitted from the host H2 is received by the OFS 12, and then transmitted to the OFC 20 as a message (Packet_In message) via the network N2 (step S17).

  Here, the message (Packet_In message) transmitted from the OFS 12 includes information specifying the OFS and port to which the host H2 that transmitted the Arp reply is connected. Therefore, the OFC 20 performs processing for recording information indicating the connection position of the host H2 (information indicating that the host H2 is connected to the physical port P6 of the OFS 12) (step S18).

  Further, when a message (Packet_In message) is received from the OFS 12, the OFC 20 performs processing for transmitting the message (Packet_Out message) to the OFS 11 via the network N2 (step S19). This processing is performed because it is known in step S13 that the host H1 to which the Arp reply is to be transmitted is connected to the physical port P1 of the OFS 11.

  When a message (Packet_Out message) transmitted from the OFC 20 is received by the OFS 11, an Arp reply is output from the physical port P1 of the OFS 11 (step S20). Thus, the Arp reply from the host H2 is received by the host H1 connected to the physical port P1 of the OFS 11, and the host H1 obtains the MAC address of the host H2 as the DNS server.

  When the above processing is completed, a data packet (DNS query) is transmitted from the host H1 as the DNS client to the host H2 as the DNS server (step S21). This is performed in order for the host H1 to inquire about the IP address of another host (not shown) connected to the network N1, for example.

  When the DNS query from the host H1 is received, the OFS 11 performs transfer processing with reference to the flow table TB1 (temporary flow table TB0 shown in FIG. 2). Here, the DNS query transmitted from the host H1 is “UDP data (datagram) whose transmission destination is the 53rd port of the host H2,” and the ID of the temporary flow table TB0 shown in FIG. 2 is “1”. The condition stored in the entry is. Therefore, in the OFS 11, a DNS query from the host H1 is sent as a message (Packet_In message) as a message (Packet_In message) according to the processing stored in the entry whose ID of the temporary flow table TB0 shown in FIG. 2 is “1”. Processing for outputting to (Ctrl) is performed.

  A message (Packet_In message) output from a control port (not shown) of the OFS 11 is transmitted to the OFC 20 via the network N2 (step S22). When the OFC 11 receives a message (Packet_In message) from the OFS 11, the OFC 20 performs processing for obtaining a route from the host H1 to the host H2. This process is performed because the OFC 20 knows the connection positions of the hosts H1 and H2 by the processes of steps S13 and S18, but does not know the path between the connection positions.

  When a path from the host H1 to the host H2 is obtained, a message (Flow_Mod message) is transmitted from the OFC 20 to the OFSs 11 and 12 via the network N2, and a flow table reflecting the path from the host H1 to the host H2 is registered. Processing is performed (step S23: second step). Specifically, the temporary flow table TB0 (see FIG. 2) set in the OFSs 11 and 12 as the flow tables TB1 and TB2 is added to the flow table TB1 to which the entry with the ID “3” shown in FIG. 3 is added. The process of updating to TB2 is performed.

  Here, the newly added entry (entry whose ID is “3”) in the flow tables TB1 and TB2 shown in FIG. 3 is more than the original entry (entry whose ID is “1”, “2”). A high priority is set. For this reason, after the temporary flow table TB0 is updated, the OFS 11 and 12 give priority to the newly added entry (entry whose ID is “3”) in the flow tables TB1 and TB2. The transfer process is performed.

  Further, when a message (Packet_In message) is received from the OFS 11, the OFC 20 performs processing for transmitting the message (Packet_Out message) to the OFS 11 via the network N2 (step S24). In this process, since the temporary flow table TB0 is updated to the flow tables TB1 and TB2 reflecting the route from the host H1 to the host H2 in the process of step S23, the DNS from the host H1 to the OFS11 is updated. This is done to forward the query towards the host H2.

  When a message (Packet_Out message) is received from the OFC 20, the OFS 11 performs a transfer process referring to the flow table TB1. Here, the DNS query included in the message from the OFC 20 is “UDP data (datagram) where the transmission source is the host H1 and the transmission destination is the port 53 of the host H2,” and the flow shown in FIG. The condition stored in the entry whose ID of the table TB1 is “3” is met. For this reason, the OFS 11 performs a process of outputting a DNS query to the physical port P12 in accordance with the process stored in the entry whose ID of the flow table TB1 shown in FIG. 3 is “3” (step S25).

  The DNS query output from the OFS 11 is input to the physical port P7 of the OFS 12 and received by the OFS 12. When the DNS query from the OFS 11 is received, the OFS 12 performs a transfer process referring to the flow table TB2. Here, the DNS query included in the message from the OFS 12 meets the conditions stored in the entry whose ID of the flow table TB2 shown in FIG. 3 is “3”. Therefore, the OFS 12 performs a process of outputting a DNS query to the physical port P6 in accordance with the process stored in the entry whose ID is “3” in the flow table TB2 shown in FIG. 3 (step S26). Thereby, the DNS query from the host H1 is received by the host H2 connected to the physical port P6 of the OFS 12.

  Through the processing in step S23 described above, the OFSs 11 and 12 are set with the flow tables TB1 and TB2 reflecting the path from the host H1 to the host H2, respectively. For this reason, when a DNS query is subsequently transmitted from the host H1, a message is not transmitted to the OFC 20, and a transfer process referring to the flow tables TB1 and TB2 is performed in each of the OFSs 11 and 12. As a result, the DNS query from the host H1 is transferred to the host H2 via the network N1 (steps S27 to S29).

  Although not shown in FIG. 4, when the host H2 receives a DNS query from the host H1, a DNS response is transmitted from the host H2 to the host H1. When this DNS response is transmitted, processing similar to steps S11 to S26 shown in FIG. 4 is performed. However, it is necessary to replace the hosts H1 and H2 in FIG. 4, replace the OFSs 11 and 12, and replace “DNS Query” in FIG. 4 with “DNS Response”. If the host H2 receives the Arp request from the host H1, the processing corresponding to steps S11 to S20 can be omitted if the MAC address of the host H1 is obtained.

  When a DNS response is transmitted from the host H2, processing corresponding to step S23 shown in FIG. 4 is performed, so that the flow tables TB1 and TB2 set in the OFSs 11 and 12 have the ID shown in FIG. 4 ”is added. As a result, the OFS 12 performs processing for outputting the DNS response from the host H2 to the physical port P7 based on the flow table TB2, and the OFS 11 outputs the DNS response from the OFS 12 to the physical port P1 based on the flow table TB1. Processing is performed. In this way, the DNS response from the host H2 is transferred to the host H1 via the network N1.

  When the hosts H1 and H2 are removed from the network N1, information indicating that is notified from the OFSs 11 and 12 to the OFC 20 via the network N2. When such information is notified, a control signal for deleting information associated with the hosts H1 and H2 removed from the network N1 is transmitted from the OFC 20 to the OFSs 11 and 12 via the network N2. .

  As described above, in this embodiment, when the route between the hosts H1 and H2 is unknown, the temporary flow table TB0 is set in the OFSs 11 and 12, and route information indicating the route between the hosts H1 and H2 is obtained. In this case, the temporary flow table TB0 is updated to the flow tables TB1 and TB2 whose contents are updated based on the path information, and data transfer control is performed. Here, the provisional flow table TB0 is a flow table in which a condition for received data and a process for outputting data that meets the condition to the OFC 20 are defined. Therefore, in this embodiment, it is possible to perform whitelist-like strict transfer control in a timely manner without knowing the specific configuration of the network N1 in advance.

  Here, a method is also conceivable in which the OFSs 11 and 12 inquire the OFC 20 about processing rules for data that does not meet the conditions without using the provisional flow table TB0. However, in such a method, when a malicious person transmits a large amount of data that does not meet the conditions, there is a possibility that the data transfer system 1 may fail. In the present embodiment, the provision of the temporary flow table TB0 in which the conditions for the received data and the process for outputting the data that conforms to the conditions to the OFC 20 is used. Yes, security can be increased.

  In the above embodiment, an example has been described in which the process of updating the temporary flow table TB0 (the process of step S23) is performed at the timing when the DNS query is transmitted from the host H1 to the host H2. However, the timing at which the process of updating the temporary flow table TB0 is performed is the timing at which route information indicating the route between the host H1 and the host H2 (may be a part of the route) is obtained, or the above route information. May be the timing at which some data is first transmitted from the host H1 to the host H2.

  For example, in the example shown in FIG. 4, if the processing of steps S11 to S18 is performed, route information indicating the route between the hosts H1 and H2 can be obtained. For this reason, the OFC 20 obtains route information indicating the route between the hosts H1 and H2 at the timing when the processing of step S18 is completed, and updates the temporary flow table TB0 (processing corresponding to the processing of step S23). You can go. 4 shows an example in which data transmission / reception between the hosts H1 and H2 is performed by unicast, data transmission / reception between the hosts H1 and H2 may be performed by multicast. However, since Arp is not sent, it is necessary to know the connection ports of the hosts H1 and H2 using a message such as IGRP (Interior Gateway Routing Protocol).

  In the above embodiment, after the process of updating the temporary flow table TB0 (the process of step S23) is performed, a message (Packet_Out message) is transmitted from the OFC 20 to the OFS 11 (step S24), and the OFSs 11 and 12 are transferred. The example in which the DNS query from the host H1 is transferred to the host H2 by the processing has been described. However, a message (Packet_Out message) may be transmitted to the OFS 12 instead of the OFS 11, and the DNS query from the host H1 may be transferred to the host H2 by the transfer process of only the OFS 12. By doing so, the transfer process in the OFS 11 can be omitted, and the time required for transfer can be shortened.

  Alternatively, when the OFS 11 has a memory for temporarily storing data from the host H1, when the DNS query from the host H1 is received, the received DNS query is temporarily stored in the memory, and the fact is indicated. The information shown may be transmitted to the OFC 20 in the process of step S22. In such a case, after the process of updating the temporary flow table TB0 (step S23), the DNS query temporarily stored by the OFS 11 with reference to the flow table TB1 based on an instruction from the OFC 20 The transfer process may be performed.

  Next, the example which applied the data transfer system 1 demonstrated above to the process control system constructed | assembled in a plant is demonstrated. The above-mentioned plants include chemical and other industrial plants, plants that manage and control wells such as gas fields and oil fields, and their surroundings, plants that manage and control power generation such as hydropower, thermal power, and nuclear power, solar power, There are plants that manage and control energy generation such as wind power, and plants that manage and control water and sewage and dams.

  FIG. 5 is a diagram for explaining a process control system to which the data transfer system according to the first embodiment of the present invention is applied. FIG. 5 (a) is a diagram for explaining the hierarchical structure of the process control system. FIG. 1 is a diagram illustrating a process control system to which a data transfer system is applied. As shown to Fig.5 (a), the process control system constructed | assembled in a plant is made into the hierarchical structure which consists of a several hierarchy (hierarchy of level 0-4). Such a hierarchical structure is defined by, for example, the international standard IEC / ISO 62264.

  The level 4 hierarchy is used for business operations such as corporate management, sales, etc., and a core business system (ERP: Enterprise Resource Planning), an integrated equipment management system called PAM (Plant Asset Management), etc. are constructed. . On the other hand, the hierarchy below level 3 is a hierarchy called an industrial control system (ICS: Industrial Control System), and is a hierarchy where manufacture of a product etc. is performed. This level 3 or lower layer is required to have high security because control related to the product is performed and dangerous goods may be handled.

  Specifically, in the level 3 hierarchy, a manufacturing execution system (MES), a plant information management system (PIMS), and the like are constructed. Further, in the level 1 and 2 hierarchy, a distributed control system (DCS) including field devices installed in a plant and FCS (Field Control Station) for controlling these field devices is constructed. .

  As described above, since a level 3 or lower layer for controlling the plant requires high security, the network constructed at the level 3 or below is basically separated from the network constructed at the level 4. Further, the network constructed in the level 1 and 2 layers is basically operated separately from the network constructed in the level 3 layer from the viewpoint of protecting the traffic for control communication.

  As shown in FIG. 5B, the data transfer system 1 is applied to a level 3 hierarchy, for example, the OFS 11 is used as a switch SW1 provided between levels 2 and 3, and the OFS 12 is provided between levels 3 and 4. Used as a switch SW2. The OFSs 11 and 12 forming the data transfer system 1 can also be used as a switch SW3 forming a network constructed in a level 3 hierarchy. In the example shown in FIG. 5B, the network constructed in the level 3 hierarchy is logically divided into two communication groups G1 and G2.

  As shown in FIG. 5B, by applying the data transfer system 1 to a process control system, it is possible to perform whitelist-like strict transfer control in a timely manner in a network constructed in a level 3 hierarchy. is there. As a result, not only data exchanged with other levels (levels 2 and 4) can be strictly managed, but data exchanged within the same level 3 hierarchy can be strictly managed. . Such management is performed in advance when the switches SW1 to SW3 are provided by different vendors (or different types), and the specific configuration of the network constructed in the level 3 is preliminarily determined. It is possible even if you do not know.

[Second Embodiment]
FIG. 6 is a block diagram showing a main configuration of a data transfer system according to the second embodiment of the present invention. As shown in FIG. 6, the data transfer system 2 of the present embodiment includes an OFS 31 that conforms to the OpenFlow specification, switches 32 and 33 that do not conform to the OpenFlow specification, and an OFC 40, and is under the control of the OFC 40. The OFS 31 and the switches 32 and 33 transfer data transmitted from the transmission source toward the transmission destination.

  That is, in the data transfer system 2 of the present embodiment, OFS 31 compliant with the OpenFlow specification and switches 32 and 33 not compliant with the OpenFlow specification are mixed in the network, and these OFS 31 and the switches 32 and 33 are connected to the OFC 40. Are controlled collectively. In FIG. 6, for easy understanding, the data transfer system 2 including one OFS 31 that conforms to the OpenFlow specification and two switches 32 and 33 that do not comply with the OpenFlow specification is illustrated. However, the number of OFSs and switches provided in the data transfer system 2 is arbitrary.

  The OFS 31 is the same as the OFS 11 and 12 shown in FIG. 1, and is a data transfer process with reference to a flow table managed by the OFC 40 (a flow table similar to the flow tables TB1 and TB2 shown in FIGS. 2 and 3). I do. The switches 32 and 33 have an access control list (ACL) (not shown), and perform data transfer processing with reference to the contents of the access control list. The switch 32 is compatible with Netconf (Network Configuration Protocol), and sets an access control list by performing communication conforming to Netconf. The switch 33 is compatible with SNMP (Simple Network Management Protocol), and performs communication conforming to SNMP to set an access control list.

  Similar to the OFC 20 shown in FIG. 1, the OFC 40 manages the flow table used in the OFS 31 and transfers data transferred via a network (a network not shown including the OFS 31 and the switches 32 and 33). Take control. However, the OFC 40 is different from the OFC 20 shown in FIG. 1 in that it manages the access control list used by the switches 32 and 33 in addition to the flow table used by the OFS 31.

  As shown in FIG. 6, the OFC 40 includes a converter 41 (generation unit) and communication units 42 to 44, and the OFS 31 is based on a white list WL (condition list) and device list DL stored in a memory (not shown). A flow table to be used (table similar to the temporary flow table TB0 shown in FIG. 2) and an access control list used by the switches 32 and 33 are generated. Then, the generated flow table and access control list are set in the OFS 31 and the switches 32 and 33, respectively.

  The white list WL is a list that defines conditions for data transfer control over the network. In this white list WL, for example, as in the conditions in the flow tables TB1 and TB2 shown in FIGS. Source and destination port numbers). The above device list DL includes, for each device connected to the network, identification information for identifying the device, information indicating whether the device complies with the open flow specification, and information indicating a protocol supported by the device. Etc. are lists that are associated with each other. The white list WL and the device list DL are created by a network administrator, for example.

  The converter 41 reads the white list WL and the device list DL, and generates a flow table suitable for the OFS 31 and an access control list suitable for the switches 32 and 33 according to the contents. Specifically, the converter 41 defines the content of the white list WL as a condition, and when it meets this condition, the provisional flow table TB0 in which information indicating that data should be output to the OFC 40 is defined (see FIG. 2). ) Is generated for OFS31. Further, the converter 41 generates an access control list suitable for communication conforming to Netconf and an access control list suitable for communication conforming to SNMP for the switches 32 and 33, respectively.

  The communication unit 42 corresponds to the OpenFlow protocol, and performs communication with the OFS 31 to set the temporary flow table generated by the converter 41 in the OFS 31. The communication unit 43 is compatible with Netconf, performs communication based on Netconf with the switch 32, and sets the access control list generated by the converter 41 in the switch 32. The communication unit 44 corresponds to SNMP, performs communication based on SNMP with the switch 33, and sets the access control list generated by the converter 41 in the switch 33. In FIG. 6, for easy understanding, the communication units 42 to 44 corresponding to the respective protocols are individually illustrated. However, these communication units 42 to 44 may be combined into one. good.

  In the data transfer system 2 having the above configuration, a white list WL and a device list DL are first created by a network administrator. Next, when there is an instruction from the network administrator, the white list WL and the device list DL are read by the converter 41, and a flow table suitable for the OFS 31 and an access control list suitable for the switches 32 and 33 are generated. . Subsequently, communication is performed with the OFS 31 by the communication unit 42, the flow table generated by the converter 41 is set in the OFS 31, and communication with the switches 32 and 33 is performed by the communication units 43 and 44. The access control lists generated by the converter 41 are set in the switches 32 and 33, respectively.

  As described above, in the present embodiment, the flow table suitable for the OFS 31 and the access control list suitable for the switches 32 and 33 are automatically created based on the white list WL and the device list DL. Thereby, the network administrator manages the white list WL and the device list DL even if the OFS 31 compliant with the OpenFlow specification and the switches 32 and 33 not compliant with the OpenFlow specification are mixed in the network. It will only improve and management will not be complicated.

  The white list WL to be managed by the network administrator defines abstract contents that do not depend on the specific configuration of the network, such as the address of the transmission source and the transmission destination. For this reason, as in the first embodiment, the network administrator can perform whitelist-like strict transfer control in a timely manner without knowing the specific configuration of the network in advance.

[Third Embodiment]
FIG. 7 is a block diagram showing a main configuration of an OFS used in the data transfer system according to the third embodiment of the present invention. The OFS 50 used in the data transfer system of the present embodiment is capable of data transfer processing based on a flow table and data filtering processing based on an access control list (so-called hybrid type). In the data transfer system of the present embodiment, an OFC that can create a flow table and an access control list is used based on the white list WL and the like, similar to the OFC 40 shown in FIG.

  As illustrated in FIG. 7, the OFS 50 includes a filter unit 51, a transfer unit 52, a filter unit 53, a memory 54, a communication unit 55, and a communication unit 56. The filter unit 51 is provided in the preceding stage of the transfer unit 52 and performs a filtering process on data input with reference to an access control list stored in the memory 54. The transfer unit 52 refers to the flow table stored in the memory 54 and performs data transfer processing via the filter unit 51. The filter unit 53 is provided after the transfer unit 52 and performs a filtering process on data output from the transfer unit 52 with reference to an access control list stored in the memory 54. Note that either one of the filter units 51 and 53 may be omitted.

  The memory 54 stores an access control list referred to by the filter units 51 and 53 and a flow table referred to by the transfer unit 52. The access control list stored in the memory 54 is the same as that suitable for the switch 32 of the second embodiment, and the flow table stored in the memory 54 is suitable for the OFS 31 of the second embodiment. (See FIG. 6).

  The communication unit 55 corresponds to the protocol for open flow, communicates with an OFC (not shown), and stores the flow table (temporary flow table TB0 shown in FIG. 2) generated by the OFC in the memory 54. Remember me. The communication unit 56 supports Netconf and SNMP, communicates with an OFC (not shown), and stores an access control list generated by the OFC in the memory 54. Note that the communication units 55 and 56 may be combined into one as in the second embodiment.

  Also in the present embodiment, as in the second embodiment, a white list WL or the like is first created by the network administrator, and if an instruction for an OFC (not shown) is given from the network administrator, the white list WL or the like is generated. The above-described flow table and access control list are generated. Next, communication is performed between the communication units 55 and 56 of the OFS 50 and an OFC (not shown), and a flow table and an access control list generated by the OFC (not shown) are stored in the memory 54 of the OFS 50. The filter units 51 and 53 of the OFS 50 perform data filtering processing with reference to the access control list stored in the memory 54, and the transfer unit 52 of the OFS 50 refers to the flow table stored in the memory 54. Data transfer processing is performed.

  As described above, in this embodiment, the transfer process based on the flow table created based on the white list WL or the like is performed by the transfer unit 52 of the OFS 50, and the access control list created based on the white list WL or the like is added. Based on the filtering process, the filter units 51 and 53 of the OFS 50 perform the filtering process. Thereby, even if the hybrid OFS 50 is connected to the network, the network administrator only has to manage the white list WL and the device list DL, and the management is not complicated. The OFS 50 can perform access control by using any one of the filter unit 51, the transfer unit 52, and the filter unit 53.

  Also in this embodiment, the white list WL to be managed by the network administrator defines abstract contents that do not depend on the specific configuration of the network, such as the source and destination addresses. Therefore, as in the second embodiment, the network administrator can perform whitelist-like strict transfer control in a timely manner without knowing the specific configuration of the network in advance.

[Modification]
<First Modification>
Generally, a flow table that conforms to the OpenFlow specification has a lifetime that is a usable period. For the temporary flow table TB0 and the flow tables TB1 and TB2 used in the first to third embodiments described above, a finite lifetime may be set or an infinite lifetime may be set.

  When a finite lifetime is set, the flow table is automatically deleted when the lifetime comes. For this reason, for example, it is possible to prevent a situation in which a network administrator forgets to delete a flow table whose lifetime has been exceeded, so that security can be improved. On the other hand, when an infinite lifetime is set, the flow table is not deleted without a deletion instruction from the network administrator. For this reason, it is possible to prevent a situation in which the flow table is deleted without the knowledge of the network administrator, so that the flow table can be explicitly managed in accordance with the intention of the network administrator.

<Second modification>
In the first to third embodiments described above, the OFCs 20, 40, etc. are provided with a timer, and the temporary flow table TB0 is set for the OFS 11, 12, 31, 50, etc. (step S10 in FIG. 4) Alternatively, the process of deleting the set temporary flow table TB0 may be automatically performed according to a predetermined schedule. Accordingly, it is possible to operate such that communication via the network is possible only for a specific period, or communication via the network is temporarily enabled, and safety can be improved.

<Third Modification>
FIG. 8 is a diagram showing a modification of the OFS used in the data transfer system according to the embodiment of the present invention. As shown in FIG. 8, the OFS 60 includes a transfer unit 61 and a plurality of physical ports P1 and P2, and performs data transfer processing with reference to a flow table stored in a memory (not shown). The transfer unit 61 is the same as the transfer unit 52 shown in FIG. In FIG. 8, the OFS 60 including two physical ports P1 and P2 is illustrated, but the number of physical ports provided in the OFS 60 is arbitrary.

  Here, the physical ports P1 and P2 of the OFS 60 are provided with a plurality of queues Q1 to Q3, and different bandwidths can be allocated to the queues Q1 to Q3. In order to assign a queue to a specific flow, it is necessary to specify a physical port to which the flow is output and to specify a queue to be assigned among a plurality of queues provided in the specified physical port.

  In the above-described embodiment, as described with reference to FIG. 4, the temporary flow table TB0 (see FIG. 2) in which no physical port is specified is obtained when the path information indicating the network path is obtained. Is updated to the identified flow tables TB1 and TB2 (see FIG. 3). Therefore, in this modification, if the bandwidth for each flow for which bandwidth allocation is to be performed is designated in the OFC whitelist WL or the like, route information indicating the route of the network is obtained and the temporary flow table TB0 is updated. In doing so, a physical port is identified and a queue is selected.

  Here, when a setting that enables the use of a flow or a band is performed, it is desirable to verify whether the setting conforms to a policy for network operation. For example, when the process in step S10 shown in FIG. 4 (the OFC 20 sets the temporary flow table TB0 in the OFSs 11 and 12) is performed, the network administrator uses the temporary flow table TB0. It is desirable to verify whether or not has the usage authority. Therefore, when the process of step S10 shown in FIG. 4 is performed, it is desirable to make an inquiry to a server having an AAA function (Authentication, Authorization, Accounting). As a result, it is possible to authenticate the setter and the device, manage authority, record accounting information, and the like.

  The data transfer system and method according to the embodiment of the present invention have been described above. However, the present invention is not limited to the above embodiment, and can be freely modified within the scope of the present invention. For example, in the first embodiment described above, an example in which the network N1 illustrated in FIG. 1 obtains route information indicating the route between the hosts H1 and H2 using ARP on the assumption that the IPv4 protocol is used is described. did. However, the present invention can also be applied when the network N2 is a network using the IPv6 protocol. In such a network, it is possible to obtain route information indicating a route between the hosts H1 and H2 using a Neighbor Discovery protocol. Moreover, although the said embodiment demonstrated and demonstrated the thing based on an open flow specification as an example, this invention has the restrictions similar to an open flow in the other apparatus which implement | achieves SDN (Software-Defined Network). Cases are also available.

1,2 Data transfer system 11,12 OFS
20 OFC
31 OFS
40 OFC
41 Converter 50 OFS
60 OFS
H1, H2 Host SW1-SW3 Switch TB0 Temporary flow table TB1, TB2 Flow table WL White list

Claims (8)

In a process control system comprising a data transfer system for controlling operation of a plant and transferring data transmitted from a transmission source to a transmission destination,
The data transfer system includes:
First information indicating a condition that defines whether or not the information related to the transmission destination and the transmission source in the received data is matched, and the communication port of the own device that outputs the received data only when the condition is met Between the level 3 hierarchy and the level 4 hierarchy defined in the international standard IEC / ISO 62264 for performing the transfer processing of the received data with reference to the table associated with the second information indicating Or one or more data transfer devices installed in a level 3 hierarchy,
When the route between the transmission source and the transmission destination is unknown, information indicating that data that conforms to the condition indicated by the first information should be output to the own device is stored as the second information. When a temporary table is set in the data transfer device and route information indicating a route between the transmission source and the transmission destination is obtained, the temporary table is converted into the first information and the first information based on the route information. A path control device that updates the second information in the changed table, and
The data transfer device and the path control device are:
Complies with or similar to the OpenFlow specification,
The routing device is
A condition list that defines conditions for controlling the transfer of data from the source to the destination;
Generation capable of generating the temporary table set in the data transfer device compliant with the OpenFlow specification and the access control list used in a noncompliant transfer device not compliant with the OpenFlow specification using the condition list And
A process control system comprising:   The control device updates the temporary table at a timing when the route information is obtained or at a timing when data is first transmitted from the transmission source to the transmission destination after the route information is obtained. The process control system according to claim 1. Priorities are set in the table set in the transfer device,
The process control system according to claim 1, wherein the control device updates the temporary table to a table in which a priority higher than a priority set in the temporary table is set.   The process control system according to any one of claims 1 to 3, wherein the table or the temporary table used in the transfer device can set a finite lifetime or an infinite lifetime.   The process control according to any one of claims 1 to 3, wherein the control device performs at least one of setting and deletion of the temporary table with respect to the transfer device in accordance with a predetermined schedule. system.   2. The transfer device according to claim 1, wherein the transfer device has a plurality of queues having different bandwidths for each port, and the queue can be selected for each port when the temporary table is updated. The process control system according to claim 5. A data transfer method for transferring data transmitted from a transmission source to a transmission destination in a process control system that performs operation control of a plant,
First information indicating a condition that defines whether or not the information related to the transmission destination and the transmission source in the received data when the route between the transmission source and the transmission destination is unknown, and the condition One or a plurality of data transfers in which the routing control device performs a transfer process of the received data based on a temporary table associated with the second information indicating the communication port of the own device that outputs the received data only for conformance A first step to set in the device;
After route information indicating a route between the transmission source and the transmission destination is obtained, the route control device changes the temporary table, and the first information and the second information are changed based on the route information. A second step of updating to the updated table,
The data transfer device is:
Communication provided in its own apparatus that outputs first information indicating a condition that defines whether or not the information regarding the transmission destination and the transmission source in the received data is matched, and the received data only when the conditions are met Referring to the table in which the second information indicating the port is associated, the level 2 hierarchy and the level 3 hierarchy defined by the international standard IEC / ISO 62264 for performing the transfer processing of the received data A data transfer method characterized by being installed between a level 3 hierarchy and a level 4 hierarchy, or installed within a level 3 hierarchy. The second step is performed at a timing at which the route information is obtained, or at a timing at which data is first transmitted from the transmission source to the transmission destination after the route information is obtained. Item 8. The data transfer method according to Item 7 .

Images