JP6314970B2 - COMMUNICATION SYSTEM, CONTROL DEVICE, COMMUNICATION METHOD, AND PROGRAM - Google Patents

Description

(Description of related applications)
The present invention is based on the priority claim of Japanese Patent Application No. 2013-051863 (filed on Mar. 14, 2013), the entire contents of which are incorporated herein by reference. Shall.
The present invention relates to a communication system, a control device, a communication device, a communication method, and a program.

  In recent years, a centralized control type network architecture has been proposed. As an example of a centralized control type network architecture, there is a technique called OpenFlow (see Patent Document 1, Non-Patent Documents 1 and 2, etc.).

<Open Flow>
OpenFlow captures communication as an end-to-end flow, and performs path control, failure recovery, load balancing, and optimization on a per-flow basis. For example, an open flow switch (abbreviated as “OFS”) specified in Non-Patent Document 2 or the like is an open flow controller (abbreviated as “OFC”) corresponding to a control device. It has a secure channel for communication. The OFS includes a flow table in which addition or rewriting is appropriately instructed from the OFC, and operates according to a flow table set for received packets, for example.

<Flow table>
FIG. 7 is a diagram schematically illustrating information of one flow entry 120 in the flow table. In the flow table, for each flow, a matching rule (matching field: Match Field) (header field) for matching with predetermined information in the header of the received packet and a processing content (operation) when matching with the matching rule are defined. A set (entry) of an action (Actions) and flow statistical information (Counters) such as the number of packet transfers and errors is defined for each flow. For example, each flow of layer 1 (L1: physical port, etc.), layer 2 (L2: MAC (Media Access Control)), layer 3 (L3: IP (Internet Protocol)), layer 4 (L4: port number), etc. Identified and specified by any layer address / identifier combination. Flow switching refers to selecting and transferring an optimum route end-to-end according to a rule handling policy (action).

  When the OFS receives the packet, the OFS searches the own flow table for an entry having a matching rule (“Match Field” in FIG. 7) that matches the header information of the received packet. If an entry (flow entry) that matches the received packet is found as a result of the search, the OFS updates the flow statistical information ("Counters" in FIG. 7) and the action of the flow entry for the received packet. Processing contents (for example, packet transmission from a designated port, flooding, discarding, etc.) described in the field ("Actions" in FIG. 7) are performed.

<Packet-In>
On the other hand, if no entry (flow entry) that matches the received packet is found as a result of the search, the OFS transfers the received packet to the OFC via the secure channel (Packet-In message). Requests determination of the packet path based on the transmission source / destination of the received packet. Upon receiving this Packet-In message, the OFC performs route calculation based on the network topology information and generates a flow entry. The OFC transmits a message for updating the flow table (flow modify message) to the OFS on the calculated path. The OFS receives the flow entry information corresponding to the packet path determined by the OFC as a FlowModify message from the OFC, and updates the flow table. In this way, packet transfer processing based on flow entry information in OFS is centrally managed on the OFC side.

International Publication No. 2008/095010

Nick McKeown and seven others, “OpenFlow: Enabling Innovation in Campus Networks,” [online], [October 31, 2012 search], Internet <URL: http: // www. openflowswitch. org // documents / openflow-wp-latest. pdf> “OpenFlow Switch Specification” Version 1.1.0 Implemented (Wire Protocol 0x02) [Search on October 31, 2012], Internet <URL: http: // www. openflowswitch. org / documents / openflow-spec-v1.1.0. pdf>

  Problems of related technologies will be described with reference to FIGS. Referring to FIG. 8, for example, the communication system (prototype example) includes OFC 110, OFS 121, 122, 123, communication terminals 131, 132, servers (Servers) 141, 142, and a router 150. The servers 141 and 142 have a redundant configuration of Active (operation) / Standby (standby). For example, when a failure occurs in the server in the active state and the processing cannot be continued, the server in the standby state is operated to take over the processing performed on the server in which the failure has occurred. In the following description, it is assumed that the server 141 has transitioned to the Active state and the server 142 has transitioned to the Standby state. There are no particular restrictions on the number of communication terminals and OFS.

<Server-server communication>
With reference to FIG. 9, the route control processing at the time of communication between the server 141 and the server 142 and the route control processing at the time of communication of the communication terminal 131 and the communication terminal 132 in the communication system (prototype example) of FIG. . First, a path control process during communication between the server 141 and the server 142 will be described. Note that the numbers in parentheses in the sentence explaining the processing correspond to the sequence numbers schematically shown in FIG.

  The server 141 in the active state transmits a data packet to start access to the server 142 in the standby state (1). The OFS 123 receives a data packet from the server 141. In the OFS 123, the flow of the received data packet is not set (the flow entry corresponding to the data packet is not set in the flow table), and is a new flow. For this reason, the OFS 123 transmits a Packet-In message to the OFC 110 and requests path setting for the received data packet (2).

  When the OFC 110 that has received the Packet-In message from the OFS 123 determines that communication is possible, the OFC 110 calculates a route between the server 141 and the server 142. Then, the OFC 110 transmits a message for updating the flow table (FlowModify message: abbreviated as “FlowMod”) to the OFS 123 (3). The OFS 123 that has received the FlowMod message from the OFC 110 sets a flow entry for realizing communication between the server 141 and the server 142 in the flow table. At that time, communication between servers is important, and in order to manage the communication state in detail, as a matching rule (Match Field of a flow entry that is collated with header information of a received packet), for example, L2 that can be specified by OpenFlow All parameters of L4 are designated.

  The OFC 110 transfers a packet-out message to the OFS 123 (4), and instructs the OFS 123 to transfer the packet. The OFS 123 that has received the Packet-Out message receives from the server 141 in the sequence of number 1, and transfers the data packet stored and held in the OFS 123 to the server 142 (5). The server 142 transfers the data packet to the server 141 via the OFS 123 (6). That is, when a communication path between the server 141 and the server 142 is set, the server 141 and the server 142 start communication via the path.

<Communication between communication terminal and server>
Furthermore, with reference to FIG. 9, the route control process at the time of communication of the communication terminal 131 will be described. The communication terminal 131 transmits a data packet to start access to the server 141 (7).

  The OFS 121 receives the data packet transmitted from the communication terminal 131. In the OFS 121, the flow of the data packet is not set and is a new flow. For this reason, the OFS 121 transmits a Packet-In message to the OFC 110 (8), and requests path setting for the received data packet.

  When the OFC 110 determines that communication is possible, the OFC 110 calculates a route between the communication terminal 131 and the server 141. The OFC 110 transmits a FlowMod message to the OFS on the path (9-1 to 9-3), and sets a flow entry for realizing communication between the communication terminal 131 to the server 141 to the OFS 121 on the communication path. , 122, 123 are set in the respective flow tables. At that time, as a matching rule in communication between the servers 141 and 142, for example, all parameters L2 to L4 that can be specified by OpenFlow are specified. For this reason, also in communication between this communication terminal 131-server 141, the same matching rule (rule which designated all the parameters from L2-L4) is used for OFS 121, 122, 123.

  The OFC 110 transmits a packet-out message to the OFS 121 (10), and instructs packet transfer. The OFS 121 that has received the Packet-Out message transfers the data packet received from the communication terminal 131 and held in the OFS 121 in the sequence of number 7 to the server 141 via the OFS 122 and OFS 123 (11). When a communication path between the communication terminal 131 and the server 141 is set, the communication terminal 131 starts communication (data packet transfer) with the server 141 (12).

<Communication between another communication terminal and server>
Thereafter, when another communication terminal 132 communicates with the server 141, as shown as sequence numbers 12 to 18 in FIG. 9, operations from sequence numbers 7 to 11 during communication between the communication terminals 131 to 141 are The same process is performed. That is, when the OFC 110 receives the Packet-In message from the OFS 121 (14), the OFC 110 calculates a route between the communication terminal 132 and the server 141, and transmits a Flow Mod message to each of the OFSs 121, 122, and 123 on the route. (15-1 to 15-3), flow entries for realizing communication between the communication terminal 132 and the server 141 are set in the respective flow tables of the OFSs 121, 122, and 123 on the communication path. The OFC 110 transmits a packet-out message to the OFS 121 (16) and instructs packet transfer. The OFS 121 that has received the Packet-Out message transfers the data packet received from the communication terminal 132 and held in the OFS 121 in the sequence of number 13 to the server 141 via the OFS 122 and OFS 123 (17). When a communication path between the communication terminal 132 and the server 141 is set, the communication terminal 132 starts communication (data packet transfer) with the server 141 (18).

  The following analysis is given by the present invention.

  In a centralized control network architecture such as OpenFlow, the matching rule is changed depending on the type of communication, such as whether the communication is a server-server communication or a communication terminal-server communication. I can't.

  For this reason, for example, in a communication apparatus such as OFS, there is a problem that the number of flow entries to be set increases excessively.

  From another viewpoint, for the same reason, the processing load of a control device such as an OFC increases excessively. Therefore, it is necessary to be able to change the matching rule depending on the communication type.

  The present invention has been made in view of the above problems, and provides a control device, system, communication method, and program that can change a matching rule set in a flow entry, for example, depending on a communication type.

According to one of several related aspects (viewpoint 1) of the disclosed invention, a control device including a matching rule management unit that determines a matching rule of a flow entry according to a type of communication;
There is provided a communication system including a communication device that processes a received packet based on collation with a flow entry set by the control device.

  According to another aspect (viewpoint 2), a matching rule management unit that determines a matching rule for a flow entry according to the type of communication is provided, and a received packet is processed based on matching with the flow entry. A control device is provided for setting the flow entry for a communication device.

According to another aspect (viewpoint 3), the control device determines a flow entry matching rule according to the type of communication,
There is provided a communication method in which a communication device processes a received packet based on collation with a flow entry set by the control device.

According to another aspect (viewpoint 4), a process for determining a matching rule for a flow entry according to the type of communication,
There is provided a program that causes a computer of a control device to execute a process of setting the flow entry for a communication apparatus that processes a received packet based on collation with a flow entry.

  According to another aspect (viewpoint 5), a non-transitory machine readable medium (semiconductor memory device, magnetic / optical disk) in which the program according to the viewpoint 4 is recorded is provided. .

  According to the present invention, the matching rule set in the flow entry can be changed depending on the communication type.

It is a figure which illustrates the structure of the communication system of Embodiment 1,2. It is a figure which illustrates the structure of the path control function of Embodiment 1,2. It is a figure which illustrates the information table for the matching rule determination of the matching rule management part in Embodiment 1. 6 is a diagram illustrating a path control operation sequence according to Embodiments 1 and 2. FIG. It is a figure which illustrates the information table for the matching rule determination of the matching rule management part in Embodiment 2. It is a figure which illustrates the information table for the matching rule determination of the matching rule management part in Embodiment 2. It is a figure which illustrates the information (flow entry) which the flow table provided in the open flow switch hold | maintains. 1 is a diagram illustrating an example of a configuration of a communication system. It is a figure which illustrates the operation | movement sequence of the communication system of FIG. It is a figure which illustrates the composition of an embodiment.

  An outline of the present invention will be described. The reference numerals used in the following description are merely examples for facilitating understanding, and should not be construed as limiting the present invention to the illustrated embodiments. According to one of several preferred embodiments, referring to FIG. 10, the type of communication (not particularly limited, for example, the type of communication between server functions or communication between communication terminals and server functions) ), A control device (10A) including a matching rule management unit (201) that determines a matching rule (matching rule) of a flow entry (processing rule: also referred to as “packet transfer rule”), and the control device ( And a communication device (20A) that processes a received packet based on the collation with the flow entry (processing rule) set from 10A).

  The said matching rule management part (201) is good also as a structure which determines the flow granularity which is a production | generation rule for producing | generating a matching rule according to the kind of communication.

In the matching rule management unit (201), when determining the granularity of the flow, as a parameter of the granularity of the flow,
An exact indicating an exact match;
A wildcard that matches any pattern,
There is a value (for example, a port number of layer 4 (L4) in the embodiment described later) corresponding to a predetermined list (not particularly limited, but a list of port numbers of the well-known port in FIG. 6, for example). If there is a reference type parameter, it is set as an “exact”, and when it does not exist, it includes at least one of a reference type parameter as a “wildcard”.

  In a preferred embodiment of the present invention, the matching rule management unit (201) may use a default flow granularity when the flow granularity cannot be determined.

  In the control device (10A), a program for executing, on the computer constituting the control device (10A), processing for determining a matching rule for a flow entry and processing for setting a flow entry in the communication device according to the type of communication May be executed. In this case, the above means is realized by reading a program stored in a storage medium (semiconductor memory, magnetic / optical disk, etc.) into a main memory of a computer and executing it.

[First Embodiment]
Referring to FIG. 1, the communication system according to the first embodiment is configured to process a plurality of received packets according to a packet transfer rule in which a matching rule for specifying a flow is associated with a processing content applied to the matching rule. A packet transfer function 21, 22, 23, and a route control function 10 that sets a packet transfer rule in the packet transfer function 21, 22, 23. Server functions 41 and 42 and a router 50 are connected to this communication system. The communication terminals 31 to 32 access the communication system via the router 50. The communication terminals 31 and 32 and the server functions 41 and 42 are assumed to belong to the same subnet (subnet length is 24 bits). Of course, the number of packet transfer functions, communication terminals, server functions, etc. is not limited to the number shown in FIG.

<One configuration example of the path control function>
FIG. 2 is a diagram illustrating the configuration of the path control function 10 of FIG. Referring to FIG. 2, the route control function 10 includes a node communication unit 11 that performs communication with the packet transfer functions 21 to 23 (nodes), a control message processing unit 12, a route / action calculation unit 13, and a packet transfer function. A management unit 14, a topology management unit 15, a communication terminal location management unit 16, a packet transfer rule management unit 17A, and a matching rule management unit 18 are provided. Each part operates as follows.

  The control message processing unit 12 analyzes the control message received from the packet transfer functions 21 to 23 and delivers the control message information to the corresponding processing means in the route control function 10.

  The route / action calculation unit 13 determines the packet on the packet transfer route based on the location information of the communication terminal managed by the communication terminal location management unit 16 and the topology information constructed by the topology management unit 15. Ask for the action to be performed by the transfer function. Further, the path / action calculation unit 13 sets the matching rule to be set in the packet transfer rule when the packet transfer rule is set in the packet transfer function (21/22/23 in FIG. 1). Inquire at 18.

  The packet transfer function management unit 14 manages the capabilities of the packet transfer function controlled by the path control function 10 (for example, the number and type of ports, the types of supported actions, etc.).

  The topology management unit 15 constructs network topology information based on the connection relation of the packet transfer function collected via the node communication unit 11.

  The communication terminal position management unit 16 manages information for specifying the position of the communication terminal (31/32 in FIG. 1) connected to the communication system. In this embodiment, a MAC (Media Access Control) address is used as information for identifying a connection point of the communication terminal to the communication system, and a packet transfer function to which the communication terminal is connected as information for specifying the position of the communication terminal. Information for identifying (21 in FIG. 1) and information of its port are used. However, the information for identifying the connection point of the communication terminal to the communication system is not limited to the MAC address, and other information may be used.

  The packet transfer rule management unit 17A manages what packet transfer function (21/22/23 in FIG. 1) is set with which packet transfer rule. Specifically, the packet transfer rule management unit 17A registers the result calculated by the route / action calculation unit 13 in the packet transfer rule database (DB) 17B as a packet transfer rule, and the packet transfer function (21 in FIG. 1). / 22/23), a packet transfer rule is set. The packet transfer rule management unit 17A is set to the packet transfer function (21/22/23 in FIG. 1) by a packet transfer rule deletion notification from the packet transfer function (21/22/23 in FIG. 1). When it is notified that a change has occurred in a packet transfer rule, information (packet transfer rule) registered in the packet transfer rule DB 17B is updated in response to the change.

<Information table for matching rule management: exact / wildcard>
The matching rule management unit 18 determines a matching rule to be set in the packet transfer rule. With reference to FIG. 3, the management information of the matching rule management part 18 is demonstrated. FIG. 3 is a diagram illustrating an example of an information table for determining matching rules managed by the matching rule management unit 18. This information table includes a search rule and a flow granularity for each entry identified by an entry ID (entry # 1, entry # 2,...). Similar to the matching rule (Match Field in FIG. 7) included in the packet transfer rule, the search rule is used to search which entry in the table of FIG. 3 is hit by the communication for which the packet transfer rule is set. Information to be used. The flow granularity is a generation rule for generating a matching rule.

  In each entry in FIG. 3, the input port is L1 (physical layer), the source MAC address, the destination MAC address, the Ether Type (Ethernet (registered trademark) Type), the VLAN (Virtual Local Area Network) ID, and the VLAN PCP (Priority). Up to Code Point (flow priority), L2, TOS (Type of Service), IP protocol, source IP address, destination IP address correspond to L3, destination MAC address is L2 (MAC) switching, destination IP address is L3 (IP) Used for routing transfer control. The transmission source port number (transmission source L4 port number) and the destination port number (destination L4 port number) are L4 port numbers (for example, TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) port numbers).

  In the example of FIG. 3, entry ID: entry # 1 is an entry for communication between server functions such as communication between server function 41 to server function 42 of FIG. Entry IDs: entry # 2 and entry # 3 are entries used for communication between the communication terminal and the server function, such as between the communication terminal 31 and the server function 41 in FIG.

In the search rule of entry ID: entry # 1,
Ether Type is hexadecimal (0x represents hexadecimal) 0800 (= IPv4),
The source IP address and the destination IP address are subnets of the server function (for example, 41 and 42 in FIG. 1),
-All other fields are "wildcard". On the other hand, the flow granularity of the entry ID: entry # 1 is set to “exact” in any field. For the IP address, the subnet of the server function specified by the source IP address and the destination IP address is the upper 32 bits (/ 32) of the IP address, and one server (host) per subnet.

In the search rule of entry ID: entry # 2, entry # 3,
-Ether Type is hexadecimal 0800 (= IPv4),
The source IP address and the destination IP address are the subnets of the communication terminal and the server function (for example, 31 and 41 in FIG. 1), respectively.
-The field other than the above is “wildcard”. The flow granularity of entry IDs: entry # 2 and entry # 3 is
・ Input port,
-Source MAC address,
-Destination MAC address,
・ Ether Type,
-Both IP protocols are set to “exact”. As for the IP address, in the entry ID: entry # 2, the subnet of the communication terminal specified by the transmission source IP address is 24 specified by the prefix, that is, the upper 24 bits of the IP address (32 bits), The subnet of the server function designated by the destination IP address is the upper 32 bits (/ 32) of the IP address, and there is one server (host) in one subnet. On the other hand, in entry ID: entry # 3, the subnet of the server function specified by the source IP address is the upper 32 bits of the IP address, and the subnet of the communication terminal specified by the destination IP address is the upper 24 bits of the IP address. The

  In the configuration described above, the packet transfer rule DB 17B can be omitted when the route control function 10 does not need to hold the packet transfer rule. Further, the packet transfer rule DB 17B may be separately provided in an external server or the like.

  The route control function 10 as described above may be realized by adding the matching rule management unit 18 based on the OFC of Non-Patent Document 1, for example. Each of the packet transfer functions 21 to 23 may be implemented in the OFS.

  When each of the packet transfer functions 21 to 23 receives a packet, each of the packet transfer functions 21 to 23 has a matching key matching the received packet from a packet transfer rule table (packet transfer functions 21 to 23 respectively) that stores packet transfer rules. A forwarding rule is found and an operation (for example, forwarding to a specific port, flooding, discarding, etc.) defined in an action (Actions in FIG. 7) associated with the packet forwarding rule is performed.

<Operation During Communication Between Server Function 41 to Server Function 42>
Next, the overall operation of this embodiment will be described in detail with reference to FIG. Below, the path control process at the time of communication between the server function 41-the server function 42 and the path control process at the time of communication of the communication terminal 31 and the communication terminal 32 are demonstrated. In the following description, the numbers in parentheses in the sentence explaining the processing correspond to the sequence numbers schematically shown in FIG. First, route control processing during communication between the server function 41 to the server function 42 will be described. The server function 41 transmits a data packet to start access to the server function 42 (1).

  The packet transfer function 23 receives a data packet from the server function 41. In the packet transfer function 23, the flow of the received data packet is not set and is a new flow. For this reason, the packet transfer function 23 transmits a new flow occurrence notification message to the route control function 10 (2) and requests route setting for the received data packet.

  When the path control function 10 that has received the new flow occurrence notification message determines that communication is possible, the path control function 10 calculates a path between the server function 41 to the server function 42 and transmits a path setting change instruction message to the packet transfer function 23 (3) Then, an entry for realizing communication between the server function 41 to the server function 42 is set in the packet transfer rule table of the packet transfer function 23 on the communication path. At that time, the matching rule management unit 18 of the route control function 10 searches the information table shown in FIG. 3 and searches for an entry for determining the corresponding matching rule. In the matching rule management unit 18, the entry ID: entry # 1 in FIG. Therefore, the route control function 10 designates all parameters L2 to L4 that can be designated as matching rules.

  In response to receiving the route setting change instruction message, the packet transfer function 23 transfers the data packet received in the sequence of number 1 to the server function 42 according to the set packet transfer rule table (4).

  When a communication path between the server function 41 to the server function 42 is set, the server function 41 starts communication with the server function 42 (5).

<Operations during communication between the communication terminal 31 and the server function 41>
Subsequently, a route control process during communication of the communication terminal 31 will be described. The communication terminal 31 transmits a data packet to start access to the server function 41 (6).

  The packet transfer function 21 receives a data packet transmitted from the communication terminal 31. In the packet transfer function 21, the flow of the received data packet is not set and is a new flow. Therefore, the packet transfer function 21 transmits a new flow occurrence notification message to the route control function 10 (7), and requests route setting for the received data packet. When the path control function 10 that has received the new flow occurrence notification message determines that communication is possible, the path control function 10 calculates a path between the communication terminal 31 and the server function 41. The route control function 10 transmits a route setting change instruction message to the packet transfer functions 21, 22, and 23 (8-1 to 8-3), and an entry for realizing communication between the communication terminal 31 and the server function 41. Is set in the packet transfer rule table of the packet transfer functions 21, 22, and 23 on the communication path. At that time, the matching rule management unit 18 searches the information table shown in FIG. 3 and searches for an entry for determining a matching rule. In the matching rule management unit 18, for the current communication, the entry ID: entry # 2 is hit in the direction of the communication terminal 31 → the server function 41, and the entry ID: entry # 3 is hit.

Therefore, the path control function 10 uses a matching rule in which the number of designated wildcards is larger than that of the server-server communication entry. For example, in the flow granularity of entry IDs: entry # 2 and entry # 3 in FIG.
・ VLAN ID,
・ VLAN PCP,
・ ToS,
-Source L4 port number,
Each field of the destination L4 port number is set to “wildcard”, and the matching condition is relaxed compared to the communication between the server function 41 to the server function 42 such as the prefix 24 (IP address upper 24 bits) of the subnet mask of the communication terminal. Yes.

  In response to the reception of the route setting change instruction message, the packet transfer function 21 receives the data packet received and stored in the sequence of number 6 through the packet transfer functions 22 and 23 in accordance with the set packet transfer rule table. Then, the data is transferred to the server function 41 (9).

  When a communication path between the communication terminal 31 and the server function 41 is set, the communication terminal 31 starts communication with the server function 41 (10).

<Operation During Communication Between Communication Terminal 32 and Server Function 41>
Thereafter, when the communication terminal 32 communicates with the server function 41, a necessary packet transfer rule (flow table) is already set at the time of communication between the communication terminal 31 and the server function 41. This eliminates the need for a new packet transfer rule setting process for the packet transfer functions 21, 22, and 23.

<Contrast with comparative example>
On the other hand, in the prototype example described with reference to FIGS. 8 and 9, when the communication terminal 32 communicates with the server function 41, a new setting process of the packet transfer rule is required. That is, as described with reference to FIG. 9, in the communication between the communication terminals 131 to 141, the OFS 121, 122, 123 has the same matching rule as the communication between the server 141 to the server 142 (for example, L2 to L4). Rules for specifying all parameters) are used, and for the communication between the communication terminal 132 and the server 141, setting processing of new flow entries to the OFS 121 to 123 is performed (sequence number 15-1 in FIG. 9). -15-3 FlowMod). For this reason, the number of flow entries held by OFS increases.

  When a flow is handled with fine granularity in the flow entry matching rule, the number of flow entries to be held by the packet transfer function or the like becomes enormous, but according to this embodiment, the flow entry of the flow entry with the flow granularity corresponding to the type of communication is used. Matching rules can be set. As a result, according to the present embodiment, it is possible to avoid an excessive increase in the number of flow entries held in the packet transfer function. Further, in a control device such as a path control function, it is possible to suppress an excessive increase in processing load.

  In the present embodiment, when the route control function 10 searches the information table of FIG. 3, the entry is hit in all searches, but it is not necessarily required to be hit (the information table search results in reception). Finding a search rule (entry) that matches predetermined information in the packet header is called “hit”). In that case, a default flow granularity may be determined in advance, and if no hit occurs, the default flow granularity may be used.

[Second Embodiment]
In the first embodiment, two types of “exact” and “wildcard” are used as parameters indicating whether or not each parameter of the flow granularity is designated by the matching rule. In this embodiment, in addition to “exact” and “wildcard”, a new “list reference type parameter” is used, so that the matching rule can be determined more flexibly. The configuration of the communication system of the present embodiment is the same as that of the first embodiment shown in FIG. Hereinafter, the present embodiment will be described with respect to differences from the first embodiment, and description of the same parts will be omitted.

  The basic configuration of the route control function 10 of this embodiment is the same as that of the first embodiment shown in FIG. 2, but the information table managed by the matching rule management unit 18 is the information table of the first embodiment (FIG. 3). ) Is different.

<Information table for matching management: well-known>
5 and 6 show examples of information tables managed by the matching rule management unit 18 in the route control function 10 of the present embodiment. FIG. 5 is an information table for specifying a rule for determining a matching rule set in the packet transfer rule. As shown in FIG. 5, the information table has a search rule and a flow granularity for each entry. The difference from the first embodiment is that a parameter “well-known” is added to the flow granularity (in the example of FIG. 5, entry IDs: entry # 2 and entry # 3 with the source L4 port number). Used in each field of the destination L4 port number).

  FIG. 6 is a diagram exemplifying a table for managing the service name, the L4 type (TCP, UDP, etc.) to be specified in FIG. 5 and the port number in FIG. FIG. 6 shows an example of a well-known port number. ftp (file transfer protocol) -data (file transfer (data body)) is port number 20, ftp (file transfer (control)) is port number 21, and shsh (shell (secure shell): TCP, UDP) is port number 22. , Telnet is port number 23, and http (hypertext transfer protocol) is 80 (other than that, the port number of smtp (simple mail transfer protocol) for mail transmission / reception is 25, and other well-known ports are omitted) ).

  In the information table of FIG. 5 that manages the matching rule, when the flow granularity of a certain field is designated “well-known” (in the example of FIG. 5, the transmission source L4 port of entry IDs: entry # 2, # 3) When the L4 port number is a port number registered in the table of FIG. 6, the flow granularity of the L4 port number field such as the number and the destination L4 port number is specified as “well-known”). The search rule parameter of the corresponding field is designated as “exact”. On the other hand, if it is not registered in the table of FIG. 6, the search rule parameter of the corresponding field is set to “wildcard”. Although not particularly limited, in the route control function 10, the L4 port number and the like may be acquired from, for example, a packet included in Packet-In.

  According to this embodiment, only one of the L4 port numbers such as http and ftp is fixed, and the other uses a random number for each transaction, while setting the flow granularity for each communication such as the application type. 5 can be accommodated without excessively increasing the number of entries in the information table of FIG.

  In this embodiment, only the L4 port number has been described as an example of a field using a list reference type parameter. However, the present invention is not limited to such a configuration. For example, other types such as Ether Type and IP protocol are used. It may be used in the field.

  While the embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments, and further modifications, replacements, and adjustments can be added.

  Note that an Expire Rule (revocation rule) or the like may be further provided in the flow entry of FIG.

  Each disclosure of the above-mentioned patent document and non-patent document is incorporated herein by reference. Within the scope of the entire disclosure (including claims) of the present invention, the embodiment can be changed and adjusted based on the basic technical concept. Various combinations and selections of various disclosed elements are possible within the scope of the claims of the present invention. That is, the present invention of course includes various variations and modifications that can be made by those skilled in the art according to the entire disclosure including the claims and the technical idea.

10 route control function 10A control device 11 node communication unit 12 control message processing unit 13 route / action calculation unit 14 packet transfer function management unit 15 topology management unit 16 communication terminal location management unit 17A packet transfer rule management unit 17B packet transfer rule database ( DB)
18 Matching Rule Management Unit 20A Communication Device 21-23 Packet Transfer Function 31-32 Communication Terminal 41-42 Server Function 50 Router 101 Matching Rule Determining Unit 110 OpenFlow Controller (OFC)
120 Flow entries 121-123 OpenFlow Switch (OFS)
131-132 Communication terminals 141-142 Server 150 Router 201 Matching rule management unit

Claims (8)

A flow that is a generation rule for generating a flow entry matching rule according to the type of communication, including whether the communication is between a terminal and a server function or communication between server functions as the type of communication A control device having a matching rule management unit for determining the granularity of
A communication device that processes a received packet based on matching with the flow entry set by the control device;
A communication system comprising: In the matching rule management unit, as a flow granularity parameter,
An exact indicating an exact match;
A wildcard that matches any pattern,
If there is a value in the given list, it is an exact, otherwise it is a wildcard reference type parameter,
The communication system according to claim 1 , comprising at least one of the following. The communication system according to claim 1 or 2 , wherein the matching rule management unit uses a default flow granularity when the granularity of the flow cannot be determined. A flow that is a generation rule for generating a flow entry matching rule according to the type of communication, including whether the communication is between a terminal and a server function or communication between server functions as the type of communication A control apparatus comprising: a matching rule management unit that determines the granularity of the packet; and setting the flow entry for a communication apparatus that processes a received packet based on collation with the flow entry. As a parameter of the flow granularity in the matching rule management unit,
An exact indicating an exact match;
A wildcard that matches any pattern,
If there is a value in the given list, it is an exact, otherwise it is a wildcard reference type parameter,
The control device according to claim 4 , comprising at least one of the following. The control device according to claim 4 or 5 , wherein the matching rule management unit uses a default flow granularity when the granularity of the flow cannot be determined. Whether the communication between the terminal and the server function or the communication between the server functions is included as a communication type, and a flow rule that is a generation rule for generating a matching rule for a flow entry according to the communication type The particle size is determined by the control device,
A communication method, wherein a communication device processes a received packet based on collation with a flow entry set by the control device. Whether the communication between the terminal and the server function or the communication between the server functions is included as a communication type, and a flow rule that is a generation rule for generating a matching rule for a flow entry according to the communication type Processing to determine the granularity ;
Processing for setting the flow entry for a communication device that processes a received packet based on matching with the flow entry;
That causes the computer of the control device to execute the program.

Images