JP5573909B2 - COMMUNICATION SYSTEM, NODE, CONTROL DEVICE, COMMUNICATION METHOD, AND PROGRAM - Google Patents

Description

  The present invention relates to a communication system, a node, a control device, a communication method, and a program, and more particularly, to a communication system, a node, a control device, a communication method, and a program that realizes communication by transferring a packet by a node arranged in a network.

  An active network is known as a technique for causing a node such as a router or a switch arranged in a network to execute a program (see Non-Patent Document 1). Patent Document 1 discloses an active network including a signaling control unit that arranges an active code in a node of the network by prior signaling.

  Patent Document 2 discloses an optical communication system in which a consistent service class can be applied in different packet rings to packet flows passing through different packet rings. The node device of this optical communication system extracts information on an inter-ring service class included in inter-ring header information added to a packet arriving from another packet ring, and packet based on the extracted inter-ring service class information Determine the intra-ring service class that should be set for the packet that arrived by referring to the table that records the correspondence between the inter-ring service class and intra-ring service class that are set between the rings. In-ring header information including the information is added to the arrived packet.

  A method called source routing is known as a method for performing path control in an IP network or the like. As specified in Non-Patent Document 2, source routing is realized by designating the IP address of a router to be relayed.

  As shown in Non-Patent Document 3, a technique called OpenFlow has been proposed in recent years. OpenFlow captures communication as an end-to-end flow and performs path control, failure recovery, load balancing, and optimization on a per-flow basis. The OpenFlow switch that functions as a forwarding node includes a secure channel for communication with the OpenFlow controller, and operates according to a flow table that is appropriately added or rewritten from the OpenFlow controller. In the flow table, for each flow, a set of a rule (FlowKey) that matches the packet header, an action (Action) that defines the processing contents, and flow statistical information (Stats) is defined (see FIG. 6).

  FIG. 29 illustrates action names and action contents defined in Non-Patent Document 4. OUTPUT is an action to be output to a designated port (interface). SET_VLAN_VID to SET_TP_DST are actions for modifying the field of the packet header.

  For example, when the OpenFlow switch receives the first packet (first packet), the OpenFlow switch searches the flow table for an entry having a rule (FlowKey) that matches the header information of the received packet. When an entry that matches the received packet is found as a result of the search, the OpenFlow switch performs the processing content described in the action field of the entry on the received packet. On the other hand, if no entry matching the received packet is found as a result of the search, the OpenFlow switch forwards the received packet to the OpenFlow controller via the secure channel, and the source / destination of the received packet. To request the determination of the route of the packet based on the above, receive the flow entry that realizes this, and update the flow table.

JP-T-2006-513671 JP 2008-236652 A

David L. Tennenhouse and 4 others, “A Survey of Active Network Research”, IEEE Communications Magazine, Vol.35, No.1, pp.80-86, January 1997 IETF, RFC791 “INTERNET PROTOCOL” Nick McKeown and 7 others, “OpenFlow: Enabling Innovation in Campus Networks”, [online], [searched August 27, 2009], Internet <URL: http://www.openflowswitch.org//documents/openflow- wp-latest.pdf> "OpenFlow Switch Specification" Version 0.9.0. (Wire Protocol 0x98) [Search August 27, 2009], Internet <URL: http://www.openflowswitch.org/documents/openflow-spec-v0.9.0. pdf>

  The entire disclosures of Patent Documents 1 and 2 and Non-Patent Documents 1 to 4 are incorporated herein by reference.

  The following is an analysis of the related art according to the present invention.

  According to the technique called OpenFlow (Non-Patent Document 3), it is necessary to arrange a flow table for selecting and executing processing contents (actions) according to the flow characteristics in each switch, and to rewrite them appropriately. When fine path control or quality assurance is executed, an entry equal to the number of the matching rules is required in this flow table, which may increase the load on the switch and the management burden on the controller side.

  According to the active net method of Non-Patent Document 1 and Patent Document 1, a specific process can be executed by a desired node without using the table as described above. When applied to a switch that performs the above, it is necessary to provide each switch with a program library or to include the program itself in a packet. In this case, the features of Non-Patent Document 3 that can simplify the control function of the forwarding node as much as possible and concentrate on the controller may be lost.

  The present invention has been made in view of the above-described circumstances, and the object of the present invention is to satisfy each request for a received packet while satisfying the request to simplify the control function of the nodes arranged in the network. It is an object of the present invention to provide a configuration and a method capable of reducing the number of entries or the table itself to be referred to when performing the processing.

According to the first aspect of the present invention, the packet processing list includes a plurality of nodes constituting at least a part of a packet transfer path, and the at least one node of the plurality of nodes is a packet processing list possessed by each of the plurality of nodes. A first means capable of receiving packets to which a plurality of pieces of identification information for specifying packet processing to be executed by each node is received, and the node of the plurality of pieces of identification information from the list of the node. There is provided a communication system including second means capable of executing packet processing specified based on corresponding identification information .

According to the second aspect of the present invention, the first means capable of determining packet processing executed in each of a plurality of nodes constituting at least a part of a packet transfer path, and at least one of the plurality of nodes. In order to identify packet processing to be executed by each node from the packet processing list of each of the plurality of nodes for one node, a plurality of identification information corresponding to each node is transferred to the packet transferred to the transfer path. And a second means capable of instructing to provide the control device .

According to the third aspect of the present invention, each of the plurality of nodes is a node that forwards the packet and that is executed by each of the plurality of nodes from a packet processing list that each of the plurality of nodes that constitute at least a part of the packet forwarding path A first means capable of receiving a packet provided with a plurality of identification information for specifying packet processing to be performed, and based on identification information corresponding to the node among the plurality of identification information from the packet processing list. And a second means capable of executing the specified packet processing . A node is provided.

According to the fourth aspect of the present invention, packet processing to be executed in each of a plurality of nodes constituting at least a part of a packet transfer path is determined, and for at least one node in the plurality of nodes, Instructing that a plurality of identification information corresponding to each node be added to a packet transferred to the transfer path in order to identify a packet process to be executed by each node from a packet processing list of each of the plurality of nodes. A communication method is provided.

  According to the fifth aspect of the present invention, there is provided a program to be executed by a computer constituting the above-described node and control device. This program can be recorded on a computer-readable storage medium. That is, the present invention can be embodied as a computer program product.

  According to the present invention, various processes can be performed with a configuration in which the number of entries is reduced or the table itself provided in each node while satisfying the demand for simplifying the control function of the nodes arranged in the network. It becomes possible. The reason is that a header including a processing sequence configured by arranging the processes to be executed by the individual nodes on the transfer path of the data transfer network is added to the input packet, and is sent to the individual nodes on the transfer path of the data transfer network. In the configuration, the processing to be executed by the device itself is executed in accordance with the processing sequence in the header added to the input packet.

It is a figure for explaining the outline of the present invention. It is a figure showing the structure of the 1st Embodiment of this invention. It is a figure showing the detailed structure of the node of the 1st Embodiment of this invention. It is a figure showing the detailed structure of the control server of the 1st Embodiment of this invention. It is a figure showing the structure of the flow entry database of the control server of the 1st Embodiment of this invention. It is a figure for demonstrating the flow key (FlowKey; matching key) of FIG. It is a flowchart showing operation | movement of the node of the 1st Embodiment of this invention. It is a figure for demonstrating the one aspect | mode of addition of an action header (action sequence). It is a figure for demonstrating the specific aspect of an action header (action row | line | column). It is a flowchart showing operation | movement of the control server of the 1st Embodiment of this invention. It is a figure showing the operation | movement sequence (at the time of new flow reception) of the node and control server of the 1st Embodiment of this invention. It is a figure showing another operation sequence (at the time of new flow reception) of a node and a control server of a 1st embodiment of the present invention. It is a flowchart showing another operation example (at the time of new flow reception) of the node according to the first exemplary embodiment of the present invention. It is a figure showing another operation sequence (at the time of new flow reception) of a node and a control server of a 1st embodiment of the present invention. It is a figure for demonstrating the whole operation | movement of the 1st Embodiment of this invention. FIG. 15 is a continuation diagram of FIG. 14. FIG. 16 is a continuation diagram of FIG. 15. It is a figure for demonstrating the breathing operation performed in the node of the 1st Embodiment of this invention. It is a figure for demonstrating another example of the breathing operation performed in the node of the 1st Embodiment of this invention. It is a figure showing the structure of the 2nd Embodiment of this invention. It is a figure showing the structure of the flow entry database of the control server of the 2nd Embodiment of this invention. It is a figure for demonstrating another example of the breathing operation performed in the node of the 2nd Embodiment of this invention. It is a figure for demonstrating the one aspect | mode of addition (embedding) of the action header (action sequence) of the 3rd Embodiment of this invention. It is an example of a frame format in which an action header (action sequence) is embedded. It is a figure for demonstrating the whole operation | movement of the 3rd Embodiment of this invention. It is a figure for demonstrating the 4th Embodiment of this invention. It is a figure for demonstrating the whole operation | movement of the 5th Embodiment of this invention. It is a figure for demonstrating the whole operation | movement of the 6th Embodiment of this invention. It is the figure which illustrated the action name and the content of the action.

  First, the outline of the present invention will be described. The node of the communication system of the present invention has a function of specifying and executing a process to be executed by the own apparatus from an action sequence (process sequence) in an action header added to the received packet.

  Here, the action header is a list of processes to be executed by individual nodes on the transfer path of the data transfer network. For example, (1) change the destination / source IP address, destination / source MAC address (header), and VLAN Tag value in the header to specified values, and (2) drop (discard) the packet. (3) Output packets from a plurality of designated ports (interfaces) (Output), and the like (see FIG. 29 and Non-Patent Document 4, page 4-6, “3.3 Actions”, (See "Table 5"). In the example of FIG. 1, the received packet is transmitted in the order of port # 5 of the node with ID = 1, port # 2 of the node with ID = 2, and port # 3 of the node with ID = 3.

  In this way, by outputting the packet with the action header added, it becomes possible to cause the nodes on the designated path to perform processing one after another. Accordingly, it is not necessary to transmit an active code to each node as in the active net described at the beginning, and it is not necessary to add an entry to the flow table in the node on the route.

  The addition of the action header may be performed by the node that first received the packet. The action sequence (processing sequence) in the action header may be acquired by inquiring an external control server or the like, or an action sequence (processing sequence) stored in advance in the node may be embedded. Moreover, what is necessary is just to let the node used as the termination | terminus of the said path | route delete the action header.

[First Embodiment]
Next, a first embodiment of the present invention will be described in detail with reference to the drawings. FIG. 2 is a diagram showing a communication system according to the first embodiment of the present invention. Referring to FIG. 2, three nodes 10, a control server 20, and a communication node 30 that communicates via the node 10 are shown. In the example of FIG. 2, three nodes 10, the control server 20, and two communication nodes 30 are illustrated, but the number of each is merely an example, and any number can be used.

  FIG. 3 is a diagram showing a detailed configuration of the node 10. Referring to FIG. 3, the node 10 includes a server communication unit 11 that communicates with the control server 30, a flow table management unit 12 that manages the flow table 13, and a transfer processing unit 14.

  Further, the transfer processing unit 14 extracts an action to be executed by the own device from the action header added to the packet received as the user traffic, and outputs the action to the action execution unit 18. When the action header is not added, the flow table 13 is searched, and the result is output to the action string setting unit 16, and the entry other than the own node of the entry searched by the table search unit 15 An action sequence setting unit 16 that adds an action sequence to be executed at the node of the node to the received packet as an action header, and an action (action to be executed by the own device) output from the action extraction unit 17 is executed on the received packet. And an action execution unit 18. The action sequence setting unit 16 inquires about an action sequence to be added to the control server 20 when there is no corresponding entry as a result of the search of the flow table 13 by the table search unit 15.

  The node 10 of the present invention can also be realized by a configuration in which the action extraction unit 17 and the action sequence setting unit 16 are added to the OpenFlow switch.

  FIG. 4 is a diagram showing a detailed configuration of the control server 20. Referring to FIG. 4, the control server 20 constructs network topology information based on the connection relationship between the flow entry database (flow entry DB) 21 storing the flow entry and the node 10 collected via the node communication unit 25. A topology management unit 22, a route / action calculation unit 23 for obtaining a packet transfer route and an action sequence to be executed by the node 10 on the transfer route based on network topology information constructed by the topology management unit 22, and a route A node that registers the result calculated by the action calculation unit 23 in the flow entry DB 21 as a flow entry and communicates with the flow entry management unit 24 responding to the flow entry addition or update request from the node 10 and the node 10 And a communication unit 25. Note that the flow entry database (flow entry DB) 21 can be omitted when there is no need to hold a flow entry instructed to be added or updated to the node 10. A configuration in which a flow entry database (flow entry DB) 21 is separately provided in an external server or the like can also be employed.

  FIG. 5 is an example of a flow entry stored in the flow entry DB 21. Referring to FIG. 5, each entry includes a DPID (data path ID), a FlowKey (flow key; matching key), and an Actions (action sequence). In the example of FIG. 5, “Output to Port # 9 by DPID 1 / Output to Port # 6 by DPID 2 / Output to Port # 1 by DPID 3” is added to the packet that matches the FlowKey (flow key; matching key) A. The action sequence is given.

  FIG. 6 is a diagram showing a field configuration of FlowKey (matching key). For example, it is possible to cause the node 10 that has received a packet whose destination address (IP DA) is a specific server to execute an action defined in the Actions field (variable length). Similarly, for example, an action defined in the Actions field (variable length) can be executed for a packet input from a specific port (In Port).

  The control server 20 can also be realized by changing the configuration of the flow entry DB 21 of the OpenFlow controller or the contents of the flow entry instructing the node 10 to add or change.

  Next, operations of the node 10 and the control server 30 described above will be described. FIG. 7 is a flowchart showing the operation of the node 10. Referring to FIG. 7, when the node 10 receives a packet from the communication node 30 or another node 10 (step S001), the node 10 extracts an action to be executed by the own device from the action header of the received packet (step S002).

  If the action can be extracted as a result of the extraction of the action (No in step S003), the node 10 executes the action to be executed by the own device (step S009).

  On the other hand, when the action cannot be extracted as a result of the extraction of the action (Yes in step S003), the node 10 searches the flow table 13 for a flow entry that matches the received packet (step S103). S004).

  When a flow entry matching the received packet is found as a result of the search of the flow table 13 (Yes in step S005), the node 10 extracts the action to be executed by itself (step S008) and finds it. The action sequence of the flow entry is added to the received packet header as an action header (step S009). For example, when a received packet is a subsequent packet of a packet already registered in the flow entry DB 21, extraction of an action to be executed by itself and an action using the search result from the flow table 13 as described above Header creation / addition is performed.

  On the other hand, if no flow entry matching the received packet is found as a result of searching the flow table 13 (No in step S005), the node 10 transmits the received packet or a part of the received packet to the control server 20. The creation of an action sequence is requested (step S006).

  When the action sequence is received from the control server 20, the node 10 registers the received flow entry in the flow table 13 (step S007). Thereafter, the node 10 receives a packet output instruction from the control server 20 (step S011). When the packet output instruction is accompanied by a flow table search instruction (Yes in step S012), the node 10 searches again whether there is a flow entry that matches the packet (step S004-2) and is executed by itself. Extraction of an action to be performed (step S008) and processing for adding the obtained action sequence as an action header to the received packet header are performed (step S009). Similarly, when the packet output instruction is not a flow table search instruction but involves an action to be performed on the packet (ie, addition of an action sequence and output from a designated port), Extraction of an action to be executed (step S008) and processing for adding the obtained action sequence to the received packet header as an action header are performed (step S009).

  Finally, the node 10 executes an action to be executed by the own device (step S010).

  Here, an action sequence adding method in step S009 will be described. In this embodiment, as shown in FIG. 8, it is assumed that an action header is added by adding (encapsulating) an action header to the head of the received packet. In addition, a method of embedding the action sequence in the header of the received packet can be adopted, which will be described as a third embodiment.

  The action sequence is not particularly limited as long as each node 10 can identify an action to be executed. For example, as shown in FIG. 9A, each node 10 can take a configuration in which actions are extracted in order from the top based on an appropriate delimiter, a separately provided Length field, or the like. For example, as shown in FIG. 9B, it is possible to adopt a configuration in which each node 10 executes an action while incrementing the leading pointer bit (adding only 1). In both cases (a) and (b) of FIG. 9, the node # 2 transfers the packet from the port # 2 to the next hop node # 3, and the node # 3 transfers the packet from the port # 9 to the next hop. Will do.

  Further, as shown in FIG. 9C, an action sequence in which the ID of each node and the action to be executed are paired can be used. In the case of FIG. 9C, the node # 2 having ID: B extracts “B2” with the ID: B of its own device in the action header, and moves from the port # 2 to the node # 3 of the next hop. The node # 3 having the ID: C transfers the packet, extracts “C9” with the ID: C of its own device in the action header, and transfers the packet from the port # 9 to the next hop. Become. In the case of such an action sequence, the action description order does not have to match the order of the nodes on the transfer route, and each node 10 specifies an action to be executed by the own device without rewriting the action header each time. It becomes possible to do.

  Furthermore, as shown in FIG. 9 (d), it is possible to adopt a method of determining an area from which an action in each action header should be extracted for each node 10. In the case of (d) of FIG. 9, node # 2, which is determined to extract an action from bits 0-3 of the action header, extracts “2” and transfers the packet from port # 2 to node # 3 of the next hop. Then, the node # 3 that is determined to extract the action from bits 4-9 of the action header extracts “9” and transfers the packet from the port # 9 to the next hop. Even in the case of such an action sequence, the order of actions does not have to match the order of nodes on the transfer route, and each node 10 specifies an action to be executed on its own device without rewriting the action header each time. It becomes possible to do.

  FIG. 10 is a flowchart showing the operation of the control server 20. Referring to FIG. 10, when the control server 20 receives an action sequence creation request from the node 10 (step S101), as in step S006 of FIG. 7, the network management information constructed by the topology management unit 22 is received. Obtaining and calculating the packet transfer path (step S102).

  As a result of the calculation of the packet transfer route, the control server 20 does not calculate the route except when the route cannot be created or the node on the route cannot be transferred (No in step S103). An action corresponding to the transfer path is calculated (step S104), and an action sequence is generated (step S105). For example, when a path from the node 10 of DPID # 1 to the node 10 of DPID # 2 and the node 10 of DPID # 3 is requested, “Output to Port # 9 by DPID 1 / Output to Port # 6 by DPID 2” / Output to Port # 1 by DPID 3 "is generated.

  Next, when the generation of the action sequence is completed, the control server 20 generates a FlowKey (matching key) for determining matching of the subsequent packet, and sets the calculated action sequence in the received packet. A flow entry in which two pieces of information including an action to be executed by the node that has received the received packet is defined is generated (step S106). Finally, the control server 20 transmits a flow entry to the request source node 10 of the action sequence (step S107), and if the node 10 does not buffer the packet (No in step S108), instructs the packet output instruction. This is performed (step S109). This packet output instruction indicates a packet to be output (received packet) and an action to be performed on the packet (adding an action header and output processing from a specified port), or a packet to be output (Received packet) and flow table search are instructed. When the node 10 is buffering the packet (Yes in step S108), packet transmission is omitted as will be described later with reference to FIGS.

  FIG. 11 is a sequence diagram showing a flow until a new flow entry is registered based on a packet (received packet) sent from the communication node A and the packet (received packet) is transferred to the next hop. is there.

  As described above, when the node 10 determines that the action header is not added to the received packet, the node 10 searches the flow table 13 for whether or not the flow entry has already been created (same as step S004 in FIG. 7). . At this point, since the corresponding entry is not registered in the flow table 13, the node 10 requests the control server 20 to create an action sequence (same as step S006 in FIG. 7).

  The control server 20 that has received the action sequence creation request calculates the transfer path and action sequence of the received packet as described above, and sets the calculated action sequence in the received packet and the reception thereof. A flow entry having two pieces of information including an action to be executed by the node that has received the packet is generated (same as steps S102 to S106 in FIG. 10).

  As described above, the node 10 that has received the flow entry registers the flow entry in the flow table 13 (same as step S007 in FIG. 7).

  Thereafter, when receiving a packet output instruction from the control server 20, the node 10 extracts an action to be executed by itself (same as step S008 in FIG. 7), and further adds an action header to the received packet (see FIG. 7 is the same as step S009 of FIG. 7), and is output from the designated port (same as step S010 of FIG. 7).

  FIG. 12 is a modification of the operation sequence of FIG. 11 differs from the operation sequence of FIG. 11 in that the control server 20 instructs the packet output to be output (received packet) and the search of the flow table as an action in the packet output instruction in step S109 of FIG. 10 after transmitting the flow entry. It is a point to do.

  Upon receiving the instruction, the node 10 executes the flow table search again using the received packet as a key (step S004-2 in FIG. 12). Since the flow entry is registered in the previous step S007, the flow entry corresponding to the received packet is searched. The node 10 extracts an action to be executed by itself from the flow entry (same as step S008 in FIG. 7), adds an action header (same as step S009 in FIG. 7) to the received packet, and starts from the designated port. (Same as step S010 in FIG. 7).

  Further, when the node 10 has a packet buffer function, the flowchart of FIG. 7 is replaced with the flowchart of FIG. 13, and the operation sequence of FIG. 11 is replaced with the sequence of FIG. 13. The difference between the flowchart of FIG. 7 and the operation sequence of FIG. 11 and the flowchart of FIG. 13 and the operation sequence of FIG. 14 is that a packet storage process (step S021) and a packet extraction process (step S022) are added. The packet output instruction from 20 is omitted. In the example of FIGS. 13 and 14, the buffer ID storing the received packet is attached to the action sequence creation request from the node 10 to the control server 20, and when the flow entry is transmitted from the control server 20 to the node 10, By attaching the received buffer ID, the node 10 extracts the received packet from the designated buffer ID (step S022) after registering the flow entry (step S007), and extracts the action to be executed by itself and the action header. Addition is performed (steps S008 to S009) and output from the designated port (step S010).

  With reference to FIGS. 15 to 17, the series of operations described so far will be described in an organized manner. When the communication node A sends a packet having a header X to the communication node B ((1) in FIG. 15), the node # 1 that has received the packet searches its own flow table, but the corresponding entry is Therefore, the control server 20 is requested to generate an action sequence corresponding to the packet ((2) Packet-In in FIG. 15).

  The control server 20 generates a flow entry in which an action sequence (Acts) corresponding to the packet transmitted from the node # 1 and an appropriate matching key (X) is set, and returns it to the node # 1 ((4 in FIG. 15). ) FlowMod (Add)).

  FIG. 16 shows a state in which the node # 1 registers the flow entry in the flow table. In this state, when the control server 20 issues a packet output instruction to the node # 1 ((5) Packet-Out in FIG. 16), the node # 1 adds an action header (Acts) to the received packet and adds the node # 1. 2 ((6) of FIG. 16).

  The node # 2 reads the action to be executed by itself included in the action header (Acts), and outputs the received packet from the port # 5. The packet output from node # 2 is input to node # 3.

  Node # 3 reads the action to be executed by itself contained in the action header (Acts), deletes the action header (Acts), and outputs the received packet from port # 9. The packet output from the node # 3 is input to the communication node B ((7) in FIG. 16).

  Thereafter, as shown in FIG. 17, when the communication node A transmits a subsequent packet to the communication node B ((8) in FIG. 17), the node # 1 that has received the packet makes an inquiry to the control server 20. Instead, it searches the flow table of its own device, generates an action header from the action sequence of the corresponding entry, and transmits it to the node # 2 ((9) in FIG. 17). Thereafter, the packets are transferred in the order of the node # 2 and the node # 3, and finally reach the communication node B ((10) in FIG. 17).

  When the route is long or when the length of the action header is limited, it may be necessary for a node in the route to acquire an action header (this operation is referred to as “breathing process”). In this case, as shown in FIG. 18, an intermediate node is requested to generate an action sequence ((1) Packet-In in FIG. 18), an action sequence to be executed by the subsequent node is acquired, and an action header is obtained. Can be added.

  The control server 20 can obtain a node that requires the breathing process when calculating a route and an action sequence. The breathing process can be realized not only when the necessity arises but also by transmitting a flow entry to the corresponding node in advance.

  For example, as shown in FIG. 19, when the control server 20 receives an action sequence generation request ((1) Packet-In in FIG. 19), not only the node # 1 ((2) FlowMod in FIG. 19). The flow entry can also be transmitted to the node # n−1 ((3) FlowMod in FIG. 19).

[Second Embodiment]
Next, a second embodiment of the present invention will be described in detail with reference to the drawings. FIG. 20 is a diagram showing a communication system according to the second embodiment of the present invention. The difference from the first embodiment shown in FIG. 2 is that each node 10a includes an action table, and an action can be specified by indicating a pointer of the action table.

  FIG. 21 is an example of a flow entry stored in the flow entry DB of the control server 20a according to the second embodiment of this invention. Referring to FIG. 21, each entry includes a DPID (data path ID), a flow key (flow key; matching key), a node on which an action is to be executed, and a pointer to the action table.

  According to the present embodiment, the size of the action header or the number of actions accommodated in the action header can be increased. Of course, also in this embodiment, as shown in FIG. 22, it is possible to cause the node 10a in the middle of the route to perform the breathing process. For example, when it is known that the breathing process is necessary at the node # n-1 in FIG. First, in the action table of the node # n−1, an action indicating that an action header that describes an action sequence to be executed by the subsequent node #n and below is added to the received packet and transmitted. Then, an action header containing a pointer that causes node # n-1 to execute the action may be input.

[Third Embodiment]
Next, a third embodiment of the present invention will be described in detail with reference to the drawings. In the first and second embodiments, the action header is described as being added in the form of being added to the head of the received packet (see FIG. 8), but as shown in FIG. 23, a part of the header of the received packet It is also possible to adopt a mode of rewriting.

  FIG. 24 is a diagram showing a frame format when an action sequence is stored in a part of the MAC DA field of the received packet. Consider a case where 46 bits excluding the 7th and 8th bits (or the lower 2 bits of the 1st octet) from the head of the MAC DA field are used as a storage area for the action sequence. If the maximum number of output ports of each node is 64, the port can be uniquely specified with 6 bits. Therefore, as shown in FIG. 9A, a maximum of seven actions can be accommodated if only the ports are arranged. Also, as shown in FIG. 9C, when adding the ID of each node, for example, if the length of the ID of each node is 8 bits, it is possible to accommodate a maximum of three actions. Become. In the example of FIG. 24, the MAC DA field is used, but a MAC SA field and other fields may be used. Further, the MAC DA field and the MAC SA field may be used in succession. In this case, the number of actions that can be accommodated increases.

  When the action sequence is embedded using the MAC DA field as described above, it is necessary to restore the MAC DA field at the last hop. Hereinafter, the operation of this embodiment will be described with reference to FIG. When the communication node A sends a packet having a header X to the communication node B ((1) in FIG. 25), the node # 1 that receives the packet searches its own flow table, but the corresponding entry is Therefore, the control server 20b is requested to generate an action sequence corresponding to the packet ((2) Packet-In in FIG. 25).

  The control server 20b generates a flow entry in which an action for replacing the matching key (X) and the header of the packet transmitted from the node # 1 with an action sequence header (X ′) is set, and returns it to the node # 1 (see FIG. 25 (4) FlowMod (Add)). In addition, the control server 20b generates a flow entry in which an action to be output to a predetermined port after restoring the action sequence header (X ′) to the original header (X) is generated, and the node # that becomes the final hop of the route 3 ((5) FlowMod (Add) in FIG. 25).

  Thereafter, when the control server 20b instructs the node # 1 to output a packet having a header with an action sequence header (X ′) ((6) Packet-Out in FIG. 25), the node # 1 The received packet is transferred to the node # 2 ((7) in FIG. 25).

  The node # 2 reads out the action to be executed by itself contained in the header (X ′) with an action sequence, and outputs the received packet from the port # 5. The packet output from node # 2 is input to node # 3.

  The node # 3 takes out the flow entry corresponding to the header with action sequence (X ′), restores the header with action sequence (X ′) to the original header (X), and then performs the restoration from the port # 9. Packet is output. The packet output from node # 3 is input to communication node B.

  Thereafter, as shown in FIG. 25, when the communication node A transmits a subsequent packet to the communication node B ((9) in FIG. 25), the node # 1 that has received the packet makes an inquiry to the control server 20b. Instead, it searches the flow table of its own device, and transmits a packet with an action sequence header (X ′) added to node # 2 according to the contents of the corresponding entry ((10) in FIG. 25). Thereafter, the packets are transferred in the order of the node # 2 and the node # 3, and finally reach the communication node B ((11) in FIG. 25).

  According to the present embodiment as described above, it is possible to reduce overhead by an amount equivalent to the action header as compared with the first embodiment.

  Also, this embodiment and the second embodiment can be combined. For example, as shown in FIG. 25, if a pointer indicating an action on the action table of each node is used, one header is used. It becomes possible to accommodate more actions. To restore the header at the last hop in this case, an action for returning the header (X ′) to the header (X) is stored in the action table of the node # 3, and a pointer (00x5) indicating the action is stored in the node # 3. Just tell me.

  The header restoration process can be realized by various methods. For example, as shown in FIG. 27, a flow entry for executing the next action can be added to the flow table of node # 3 of the last hop. First, (12) IP DA (Internet Protocol Destination Address) is acquired from X ′, (13) ARP (Address Resolution Protocol) Request is transmitted to a port other than In Port, and (14) MAC DA corresponding to IP DA To get. (15) After restoring the header using the acquired MAC DA, (16) transmit the packet to the MAC DA receiving port.

  Further, for example, when the MAC SA field is not used for storing the action sequence, the contents of the MAC DA field (00: 00: 00: 00: 00: 01) are stored in the MAC SA field as shown in FIG. It is also possible to use a method in which an action sequence is stored in the MAC DA field after evacuation, and the action is performed by writing back the MAC DA field to the last hop node # 3 using the contents of the MAC SA field. In the example of FIG. 28, an address (00: 00: 00: 00: 00: 02) is entered in the MAC SA field, but this value may be an appropriate value.

  The accommodation destination of the action string is not limited to the example of FIG. 24, and other fields such as a MAC SA field, VAN_ID (VID), and Type can also be used. In addition, it is also possible to adopt a mode in which the action sequence is accommodated at a predetermined position such as a header or data area of the upper layer.

  The preferred embodiments of the present invention have been described above. However, the present invention is not limited to the above-described embodiments, and further modifications, replacements, and replacements may be made without departing from the basic technical idea of the present invention. Adjustments can be made. The control servers 20 and 20a to 20f according to the above-described embodiment can be realized as dedicated servers. The nodes 10 and 10a to 10f include routers in the IP network, MPLS (Multi-Protocol), in addition to the OpenFlow switch. It can be realized by an MPLS switch in a network (Label Switching). In addition, the present invention can be applied to any network where the server centrally manages nodes in the network.

  Further, as apparent from the operation of the present invention, the action sequence setting unit 16 that sets the action sequence and the entry node (for example, node # 1 in FIG. 18) that is the starting point of the route and the node that performs the breathing process ( For example, it suffices to be at node # n-1) in FIG. Therefore, when it is known which node in the network corresponds to the entry node and the node that performs the breathing process, the action sequence setting unit 16 can be omitted.

  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 embodiments and examples can be changed and adjusted based on the basic technical concept. Further, various combinations or selections of various disclosed elements (including each element of each claim, each element of each embodiment or example, each element of each drawing, etc.) within the scope of the claims of the present invention. Is possible. That is, the present invention of course includes various variations and modifications that could be made by those skilled in the art according to the entire disclosure including the claims and the technical idea. In particular, with respect to the numerical ranges described in this document, any numerical value or small range included in the range should be construed as being specifically described even if there is no specific description.

  In a commercial network such as a data center, it is necessary to strictly control a packet transfer path according to various conditions such as a destination address, a source address, and a protocol used for QoS (Quality of Service) and load distribution. According to the present invention, a flow table of a node that does not require at least an intermediate breathing process becomes unnecessary, and the number of entries can be reduced even in a node that requires a flow table. Therefore, the present invention can be suitably applied to a commercial network such as a data center.

10, 10a to 10f Communication node 11 Server communication unit 12 Flow table management unit 13 Flow table 14 Transfer processing unit 15 Table search unit 16 Action column setting unit 17 Action extraction unit 18 Action execution unit 20, 20a to 20f Control server 21 Flow entry Database (flow entry DB)
22 topology management unit 23 route / action calculation unit 24 flow entry management unit 25 node communication unit 30 communication node

Claims (27)

A plurality of nodes constituting at least a part of a packet transfer path;
At least one node of the plurality of nodes is
First means capable of receiving a packet to which a plurality of pieces of identification information for specifying packet processing to be executed by each node is received from a packet processing list possessed by each of the plurality of nodes;
Second means capable of executing packet processing specified from the list of the node based on the identification information corresponding to the node among the plurality of identification information;
A communication system comprising: The at least one node is
The communication system according to claim 1, further comprising: a third unit that makes an inquiry about the packet processing to a control device that controls the plurality of nodes. The at least one node is
Communication system according to claim 1 or 2 in accordance with the control apparatus, characterized by comprising a fourth means for processing the received packet for controlling said plurality of nodes. The at least one node is
The communication according to any one of claims 1 to 3, further comprising: fifth means for setting the plurality of identification information corresponding to packet processing related to the received packet for the received packet. system. The fifth means includes
5. The plurality of pieces of identification information corresponding to packet processing related to the received packet are set for a received packet according to a processing rule set by a control device that controls the plurality of nodes. The communication system according to 1. The fifth means includes
6. The plurality of pieces of identification information corresponding to packet processing executed by the plurality of nodes on a transfer path of the received packet are set for the received packet. Communications system. The first means receives the packet provided with the plurality of identification information corresponding to each of the plurality of nodes according to the order of the plurality of nodes in the transfer path,
The second means executes packet processing specified based on the identification information corresponding to the order of the nodes in the transfer path.
The communication system according to any one of claims 1 to 6.   First means capable of determining packet processing to be executed in each of a plurality of nodes constituting at least a part of a packet transfer path;
In order to identify the packet processing executed by each node from the packet processing list of each of the plurality of nodes for at least one node in the plurality of nodes, a plurality of identification information corresponding to each of the nodes is A second means capable of giving an instruction to attach to a packet transferred to the transfer path;
The control apparatus characterized by including. The control device according to claim 8 , further comprising third means for receiving an inquiry about the packet processing from the at least one node . The second means instructs the at least one node to add the plurality of identification information to the packet.
10. The control device according to claim 8 or 9, wherein The second means instructs a node that is a starting point of the transfer path to add the plurality of identification information to the packet.
The control device according to claim 8, wherein the control device is a control device. The second means sends the plurality of identification information corresponding to each of the plurality of nodes to at least one node in the plurality of nodes according to the order of the plurality of nodes in the transfer path. Instruct to attach to packet
The control device according to claim 8, wherein the control device is a control device. The second means transmits an instruction including a condition for identifying a packet flow and the plurality of identification information added to a packet corresponding to the condition to at least one node in the plurality of nodes. Do
  The control device according to claim 8, wherein the control device is a control device. A node that forwards packets,
Receiving a packet with a plurality of identification information for identifying packet processing executed by each of the plurality of nodes from a packet processing list of each of the plurality of nodes constituting at least a part of the packet transfer path First means,
Second means capable of executing packet processing specified based on identification information corresponding to the node among the plurality of identification information from the packet processing list;
A node characterized by containing Third means for inquiring about the packet processing to the control device that controls the plurality of nodes
The node of claim 14, comprising: Fourth means for processing received packets in accordance with the control device for controlling the plurality of nodes
  The node according to claim 14 or 15, characterized by comprising: The at least one node is
  Fifth means for setting the plurality of identification information corresponding to packet processing related to the received packet for the received packet
  The node according to any one of claims 14 to 16, characterized by comprising: The fifth means includes
  In accordance with a processing rule set by a control device that controls the plurality of nodes, the plurality of pieces of identification information corresponding to packet processing related to the received packet are set for the received packet.
  The node according to claim 17. The fifth means includes
  For the received packet, the plurality of identification information corresponding to packet processing executed by the plurality of nodes on the transfer path of the received packet is set.
  The node according to claim 17 or 18, characterized in that: The second means specifies a packet process associated with the node based on the plurality of identification information given to the packet according to the order of the plurality of nodes in the transfer path.
20. A node as claimed in any one of claims 14 to 19 characterized in that The first means receives the packet provided with the plurality of identification information corresponding to each of the plurality of nodes according to the order of the plurality of nodes in the transfer path,
  The second means executes packet processing specified based on the identification information corresponding to the order of the nodes in the transfer path.
  20. A node as claimed in any one of claims 14 to 19 characterized in that A node that forwards packets,
A first means capable of receiving a packet;
In accordance with an instruction from a control device capable of controlling a packet transfer path, each packet is specified by each node from a packet processing list included in each of a plurality of nodes constituting at least a part of the transfer path. A second means capable of giving a plurality of identification information corresponding to nodes to the packet;
A node characterized by containing The second means assigns the pointer to the packet according to an instruction including a condition for identifying a packet flow and the plurality of identification information to be given to the packet corresponding to the condition.
23. The node of claim 22, wherein:   Determining packet processing to be executed in each of a plurality of nodes constituting at least a part of a packet transfer path;
In order to identify the packet processing executed by each node from the packet processing list of each of the plurality of nodes for at least one node in the plurality of nodes, a plurality of identification information corresponding to each of the nodes is Instructs the packet to be transferred to the transfer path.
A communication method characterized by the above. To a control device that can control multiple nodes,
A process for determining a packet process to be executed in each of a plurality of nodes constituting at least a part of a packet transfer path;
In order to identify the packet processing executed by each node from the packet processing list of each of the plurality of nodes for at least one node in the plurality of nodes, a plurality of identification information corresponding to each of the nodes is A program for executing a process for instructing a packet to be transferred to a transfer path . A communication method in a node that forwards packets,
Receiving a packet to which a plurality of identification information for specifying packet processing to be executed by each of the plurality of nodes is received from a packet processing list possessed by each of the plurality of nodes constituting at least a part of the packet transfer path; ,
The packet processing specified from the packet processing list based on the identification information corresponding to the node among the plurality of identification information is executed.
A communication method characterized by the above. A communication method in a node that forwards packets,
Receive the packet,
In accordance with an instruction from a control device capable of controlling a packet transfer path, each packet is specified by each node from a packet processing list included in each of a plurality of nodes constituting at least a part of the transfer path. A plurality of identification information corresponding to the node is added to the packet.
A communication method characterized by the above.

Images