JP2015046936A - Communication system, control device, processing rule setting method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To achieve both integration of processing rules and facilitation of identifying a flow that makes abnormal traffic occur.SOLUTION: A control device comprises: first means capable of communicating with a plurality of nodes constituting part of a network; and second means for instructing an edge node receiving a packet from a transmission source terminal of the packet to rewrite a first destination address included in the packet to a second destination address including a plurality of destination addresses including the first destination address.

Description

  The present invention relates to a communication system, a control device, a node, a processing rule setting method, and a program, and in particular, a communication system, a node, a control device, a communication method, and a communication method for realizing communication by transferring a packet by a node arranged in a network. Regarding the program.

  As shown in Patent Document 1 and Non-Patent Documents 1 and 2, in recent years, a technique called OpenFlow has been proposed. 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 collation rule (matching rule) that collates with a packet header, an action (Actions) that defines processing contents, and flow statistical information (Stats) is defined (see FIG. 13). ).

  FIG. 13 illustrates action names and action contents defined in Non-Patent Document 2. OUTPUT is an action for outputting a packet 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 matching rule (matching rule) 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.

  Patent Document 2 discloses a layer 2 switch having a MAC learning table, which converts a VWAN-ID added to a frame to a degenerate VWAN-ID, and a degenerate VWAN-ID added to the frame. A layer 2 switch including a restoration unit that restores the original VWAN-ID, and at the time of registration of the VWAN-ID, one of the degenerate VWAN-IDs corresponding to this VWAN-ID is determined, and the conversion unit and the restoration unit are And a layer 2 switch control device to be set. According to the publication, the degenerate VWAN-ID is made up of a smaller number of values than the VWAN-ID can take, and this layer 2 switch uses the MAC learning function to perform an MAC learning on an entry including the degenerate VWAN-ID. It is supposed to be registered in the table.

International Publication No. 2008/095010 International Publication No. 2006/106588

Nick McKeown and seven others, "OpenFlow: Enabling Innovation in Campus Networks", [online], [searched September 21, 2010], Internet <URL: http://www.openflowswitch.org//documents/openflow- wp-latest.pdf> "OpenFlow Switch Specification" Version 1.0.0. (Wire Protocol 0x01) [searched on September 21, 2010], Internet <URL: http://www.openflowswitch.org/documents/openflow-spec-v1.0.0. pdf>

  In the above OpenFlow, a wild card can be used in the processing rule. For example, even if the flows have different transmission sources, flows having the same destination can be aggregated into a processing rule having a matching rule that matches only the destination (see FIGS. 8 and 9). By consolidating the processing rules in this manner, the load on the node (hereinafter referred to as “node” including the case of the above-mentioned OpenFlow switch) and the control device (hereinafter referred to as the above-mentioned OpenFlow controller) on the packet transfer path. It is possible to reduce the management burden of “control device” including some cases.

  However, when the above flows are aggregated, the granularity of the flow statistical information (Stats) that is factored at the node on the packet transfer path is also the aggregated flow unit, and when abnormal traffic occurs, the abnormal traffic is There is a problem that it is difficult to specify the generated flow.

  On the other hand, in order to identify abnormal traffic, strict matching such as the source / destination IP address of layer 3 (data link layer) and the L4 port number of layer 4 (transport layer) in the OSI reference model is performed without performing the above aggregation. When trying to acquire flow statistics information (Stats), the number of processing rule entries to be held by the node on the packet transfer path increases, and the performance degradation of the node and the path change at the time of failure become complicated. is there.

  The present invention has been made in view of the above-described circumstances, and the object of the present invention is to provide a configuration capable of achieving both aggregation of processing rules and easy identification of a flow that generates abnormal traffic. It is to provide.

  According to the first aspect of the present invention, a first means capable of communicating with a plurality of nodes constituting a network and an edge node that receives the packet from a packet transmission source terminal are included in the packet. There is provided a communication system comprising: second means for instructing rewriting of one destination address to a second destination address including a plurality of destination addresses including the first destination address.

  According to the second aspect of the present invention, the first means communicable with a plurality of nodes constituting the network and the edge node that receives the packet from the packet transmission source terminal are included in the packet. And a second means for instructing rewriting of one destination address to a second destination address including a plurality of destination addresses including the first destination address.

  According to the third aspect of the present invention, the first destination address included in the packet is communicated to a plurality of nodes constituting the network, and the edge node receiving the packet from the packet transmission source terminal, A control method is provided for instructing rewriting to a second destination address including a plurality of destination addresses including the first destination address. This method is linked to a specific machine called a control device that sets processing rules for the core node and the edge node.

  According to a fourth aspect of the present invention, there is provided a program that causes a computer to execute processing executed in the control device described above. 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, it is possible to achieve both the aggregation of processing rules and the facilitation of specifying the flow causing abnormal traffic. The reason is that, at the node located at the start point of the aggregateable section of the packet transfer path, the processing packet statistical information can be collected at the processing rule unit, and at the node located in the aggregateable section, the processing rule This is because a configuration for aggregation is adopted.

It is a figure for demonstrating the outline | summary of this invention. It is a figure showing the structure of the 1st Embodiment of this invention. It is a block diagram showing the structure of the control apparatus of the 1st Embodiment of this invention. It is an example of the path | route information hold | maintained at the 1st Embodiment of this invention. It is a figure for demonstrating the conversion content of the MAC address which the control apparatus of the 1st Embodiment of this invention performs. It is a figure for demonstrating operation | movement of the control apparatus of the 1st Embodiment of this invention. It is the table | surface which put together the process rule set to each node by the control apparatus of the 1st Embodiment of this invention. It is the table | surface which put together the process rule which the control apparatus of the 1st Embodiment of this invention sets to each node in non-aggregation mode. This is an example in the case where flows having the same destination are aggregated in the processing rules of FIG. It is a figure showing the difference with the non-aggregation mode of the flow entry set in Ingress OFS. It is a figure showing the difference with the non-aggregation mode of the flow entry set in Core OFS. It is a figure showing the difference with the non-aggregation mode of the flow entry set in Egress OFS. It is a figure showing the structure of the flow entry of a nonpatent literature 2. FIG.

  First, the outline of the present invention will be described. As shown in FIG. 1, the present invention processes a received packet according to a processing rule that associates a process applied to a packet with a matching rule for specifying a packet to which the process is applied, and This can be realized by the nodes 10-1 to 10-n that record the statistical information of the processing packets and the control device 20 that sets the processing rules for these nodes 10-1 to 10-n. Note that the reference numerals of the drawings attached to this summary are attached to the respective elements for convenience as an example for facilitating understanding, and are not intended to limit the present invention to the illustrated embodiment.

  For example, it is assumed that packet transfer paths of node 10-1, node 10-2,..., Node 10-n have been calculated as transfer paths for packets addressed to terminal C (30c) from terminal A (30a). . Similarly, packet transfer paths of node 10-1, node 10-2,..., Node 10-n are calculated as transfer paths for packets addressed to terminal C (30c) from terminal B (30b). To do. Therefore, the two packet transfer paths have overlapping sections (aggregatable sections) of node 10-1, node 10-2,..., Node 10-n.

  At this time, the control device 20 transmits the individual flows (terminal A-terminal C, terminal B-terminal C, and the like) transferred to the node 10-1 located at the start point of the aggregation-capable section through the two or more packet transfer paths. ) For a packet belonging to), a flow identifier (eg, F1, F2) for identifying a flow and a path identifier (eg, E1) used for packet transfer in the aggregatable section are compared with the matching rule of the packet. A processing rule for each flow for outputting a packet is set after performing processing for writing to the area to be processed.

  Further, the control device 20 transfers a packet that matches the route identifier (eg, E1) to the nodes 10-2,..., 10 (n−1) located in the middle of the aggregation possible section. A processing rule common to the flows to be transferred according to the route is set.

  In addition, the control device 20 rewrites the content of the node 10-n positioned at the end point of the aggregatable section in the node positioned at the start point of the aggregatable section based on the flow identifier (eg, F1, F2). A processing rule for outputting a packet is set after processing for restoring the packet.

  As described above, packets sent from the terminal A (30a) and the terminal B (30b) to the terminal C (30c) are sent to the node 10-1, the flow identifier (eg, F1, F2) and the path identifier (example). : E1) and the packet is transferred to the aggregatable section. Then, the packet sent from the terminal A (30a) and the terminal B (30b) to the terminal C (30c) at the node 10-n at the end point of the aggregable section is restored to the original content.

  Therefore, nodes located in the middle of the aggregable section can be aggregated into a processing rule having a path identifier (eg, E1) as a matching rule. On the other hand, a processing rule for writing the flow identifier (eg, F1, F2) and the path identifier (eg, E1) to a packet belonging to each flow is set in the node located at the start point of the aggregateable section. Since the statistical information of the processing packet is recorded for each processing rule unit, it is easy to identify abnormal traffic.

[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 the configuration of the first exemplary embodiment of the present invention. Referring to FIG. 2, a plurality of OpenFlowSwitches (hereinafter referred to as “OFS” unless otherwise distinguished from each OFS) 10 a to 10 e for transferring packets exchanged between the terminals A and B and the terminals C and D. The control device 20 is connected to the OFSs 10a to 10e through a secure channel and sets processing rules (flow entries) and collects statistical information.

  When receiving the packet, the OFS 10a to 10e searches the flow entry table (flow table) held therein for a flow entry that matches the packet, and executes the processing content defined in the searched flow entry. .

  In FIG. 2, the symbols (# 1 to # 24) written in the vicinity of the link ends between the OFSs or between the OFS 10a to 10e and the terminals A to D represent the port numbers of the OFS. For example, when the OFS_B 10b wants to output a packet addressed from the terminal A to the terminal C to the OFS_C 10c side, a process that outputs a packet that matches the matching rule (matching rule) from the port # 12 (OUT_PORT: 12) Set the flow entry that defines.

  When the OFS 10a to 10e receives a packet that does not match any flow entry stored in the flow entry table (flow table), the OFS 10a to 10e notifies the control device 20 of the packet information using a Packet-in message. To do.

  The control device 20 that has received the Packet-in message selects a route for transferring the packet and a subsequent packet belonging to the same flow from the source and destination information of the packet, and flows to the OFS on the packet transfer route. Set the entry.

  FIG. 3 is a block diagram showing a detailed configuration of the control device 20. Referring to FIG. 3, the configuration includes an OpenFlow protocol processing unit 21, a switch information management unit 22, a flow entry creation unit 23, a route information management unit 24, a topology management unit 25, and a route calculation unit 26. It is shown.

  The OpenFlow protocol processing unit 21 receives a flow entry setting request from the OFS 10a to 10e using the open flow protocol defined in Non-Patent Document 2, and sets the flow entry or sends a packet to the OFS 10a to 10e. Then, processing for instructing transfer of the recorded flow statistical information is performed.

  The switch information management unit 22 collects and manages the identification information and physical port information of the OFSs 10 a to 10 e and provides them to the flow entry creation unit 23. As a method of collecting the identification information and physical port information of the OFS 10a to 10e, a Switch function inquiry message (Features Request) defined in Non-Patent Document 2 is transmitted to the OFS 10a to 10e, and the Switch function is transmitted from the OFS 10a to 10e. A method of receiving a response message (Features Replay) can be used (see “5.3 Controller-to-Switch Messages” below in Non-Patent Document 2).

  The topology management unit 25 holds the topology information of the OpenFlow network. The topology information can be constructed by using a method of collection by a function such as one constructed in advance or LLDP (Link Layer Discovery Protocol).

  The route calculation unit 26 refers to the topology information held in the topology management unit 25 and creates a packet transfer route between arbitrary OFS.

  The route information management unit 24 manages the packet transfer route calculated by the route calculation unit 26, and in response to a request from the flow entry creation unit 23, as shown in FIG. provide. Here, from the topology information that defines the connection relationship of the OFSs 10a to 10e shown in FIG. 2, the packet transfer path E1 (OFS_A-OFS_B-OFS_C-OFS_E) and the packet transfer path E2 (OFS_A) are between OFS_A-OFS_E in FIG. -OFS_B-OFS_D-OFS_E) is created.

  The flow entry creation unit 23 selects a packet transfer route held in the route information management unit 24 based on the packet information passed from the OpenFlow protocol processing unit 21, and the OFS located in the middle on the packet transfer route The flow entries to be set in the OFS located at the start point, end point, and middle of the route are created so that the flow entries are aggregated.

  For example, when the packet transfer route E1 is selected for the flow from the terminal A to the terminal C, the flow entry creation unit 23 adds the OFS_A 10a located at the start point of the selected packet transfer route E1 to the header of the original packet. A processing rule for outputting the packet to the next hop (OFS_B) is set after converting the source MAC address to a flow ID and the destination MAC address to a path ID.

  Further, the control device 20 sets a processing rule for transferring a packet conforming to the route ID (for example, E1) to the OFS_B 10b and OFS_C 10c located in the middle of the packet transfer route E1 according to the packet transfer route E1.

  In addition, the control device 20 sets the source MAC address and destination MAC address of the packet matching the flow ID and path ID converted by OFS_A 10a to the OFS_E10e located at the end point of the packet transfer path E1. A processing rule for outputting a packet is set after processing to return to the MAC address and destination MAC address.

  FIG. 5 is a diagram showing the correspondence between the MAC addresses converted by the flow entry creation unit 23 described above.

  Note that the control device 20 described above can also be realized by mounting a flow entry aggregation function described later on the OpenFlow controller described in Non-Patent Documents 1 and 2. Further, each unit (processing means) of the control device 20 shown in FIG. 3 can also be realized by a computer program that causes a computer constituting the control device 20 to execute the above-described processes using its hardware.

  Next, the operation of this embodiment will be described in detail with reference to the drawings. In the following description, the flow ID: 1 flowing through the terminal A-terminal C, the flow ID: 2, flowing through the terminal A-terminal D: 2, the flow ID: 3, flowing through the terminal B-terminal C, which are represented by bold lines in FIG. It is assumed that flow entry setting requests are made in the order of flow ID: 4 flowing through terminal B-terminal D.

  First, when the OFS_A 10a requests the creation of a flow entry for the flow from the terminal A to the terminal C, the control device 20 selects the packet transfer path E1 from the packet transfer path shown in FIG. 4 and connects the port to the OFS_A 10a. For a packet in which the source MAC address entered from # 1 is the MAC address of terminal A and the destination MAC address is the MAC address of terminal C, the source MAC address in the header is set to flow ID: 1, and the destination MAC address Is converted to the route ID: E1, and then a flow entry for outputting a packet from the connection port # 10 to the next hop (OFS_B) is created and set.

  At this point, a flow entry is created and set as shown in the column “OFS_A” and flow ID = 1 in FIG. In FIG. 7, “MATCH” represents a flow entry matching rule, that is, a matching rule. In FIG. 7, “ACTION” represents a flow entry action field, that is, a processing content applied to the packet. . In addition, “IN_PORT”, “DL_SRC”, and “DL_DST” correspond to “In Port”, “Ether SA”, and “Ether DA” in the flow entry of FIG. “SET_XXX_XXX” indicates an action for rewriting the header XX_XXX, and “OUT_PORT ##” indicates a packet output from the ## port.

  Further, the control device 20 causes the OFS_B 10b located in the middle of the packet transfer path E1 to output a packet whose destination MAC address that has entered from the port # 11 is the path ID: E1 from the port # 12 to which the OFS_C 10c is connected. A flow entry is created and set (see the column “OFS_B”, flow ID = 1 in FIG. 7). Similarly, the control device 20 creates and sets a flow entry that causes the OFS_C 10c to output, from the port # 14 to which the OFS_E 10e is connected, the packet whose destination MAC address that has entered from the port # 13 is the route ID: E1. (Refer to the column “OFS_C”, flow ID = 1 in FIG. 7).

  In addition, the control device 20 sets a header for the packet whose source MAC address is flow ID: 1 and whose destination MAC address is route ID: E1 that has entered from OF ## 15 in OFS_E10e located at the end point of the packet transfer route E1. The source MAC address is restored to the MAC address of the terminal A and the destination MAC address is restored to the MAC address of the terminal C, and then a flow entry to be output from the port # 3 to which the terminal C is connected is created and set (see FIG. 7 “OFS_E”, refer to the column of flow ID = 1).

  Next, consider a case where the control apparatus 20 is requested by the OFS_A 10a to create a flow entry for a flow from the terminal A to the terminal D. Since the terminal D is connected to the OFS_E 10e, any of the packet transfer paths E1 and E2 in FIG. 4 can be adopted as a packet transfer path of the flow from the terminal A to the terminal D. Here, it is assumed that the control device 20 selects the packet transfer path E1 in the same way as the previous flow ID: 1 in order to aggregate the flow entries.

  In this case, the control device 20 sends the source of the header in the OFS_A 10a for a packet whose source MAC address that has entered from port # 1 is the MAC address of the terminal A and whose destination MAC address is the MAC address of the terminal D. After the MAC address is converted to flow ID: 2 and the destination MAC address is converted to route ID: E1, a flow entry is generated and set to output a packet from the connection port # 10 to the next hop (OFS_B) (FIG. 7). (See the column “OFS_A”, flow ID = 2).

  In addition, the control device 20 sets a header for a packet whose source MAC address is flow ID: 2 and whose destination MAC address is route ID: E1 that has entered from OF # _15 in OFS_E10e located at the end point of the packet transfer path E1. The source MAC address is restored to the MAC address of the terminal A and the destination MAC address is restored to the MAC address of the terminal D, and then a flow entry to be output from the port # 4 to which the terminal D is connected is created and set (see FIG. 7 “OFS_E”, refer to the column of flow ID = 2).

  On the other hand, the OFS_B 10b and OFS_C 10c located in the middle of the packet transfer path E1 already have a flow entry for transferring a packet whose destination MAC address is the path ID: E1 to the next hop.・ Setting is not required.

  Similarly, when the OFS_A 10a requests to create a flow entry for the flow from the terminal B to the terminal C, the control device 20 similarly creates a flow entry that involves rewriting / restoring the header only for the OFS_A 10a and OFS_E 10e. (Refer to the line of flow ID = 3 in FIG. 7).

  It is also possible to cause the control device 20 to select a different packet transfer path in consideration of the load of each OFS, the service attribute of each flow, and the like. For example, in the example of FIG. 7, when the OFS_A 10 a requests the creation of a flow entry for the flow from the terminal B to the terminal D, the control device 20 selects the packet transfer path E2 and flows to each of the OFSs 10 a to 10 e. An entry is created and set (see the line of flow ID = 4 in FIG. 7).

  Although the operation of the present embodiment has been described above, the above-described control device 20 can select a plurality of operation modes, and the above-described aggregation mode that aggregates flow entries and the non-aggregation mode that does not perform aggregation. May be selected.

  FIG. 8 is a diagram showing flow entries set in the OFSs 10a to 10e when the above-described aggregation is not performed. As is clear from comparison between FIG. 7 and FIG. 8, in this embodiment, the number of flow entries in OFS_B 10b and OFS_C 10c has been successfully reduced from 4 to 2. The number of flow entries that can be reduced can be estimated as “the number of aggregated flows × (the number of nodes on the packet transfer path−2)”. At the same time, since the OFS_A 10a performs matching with the input packet for each flow, it is possible to easily identify which flow among the flow IDs 1-4 has generated abnormal traffic.

  In addition, when a route change occurs due to the occurrence of a route failure, in the non-aggregation mode as shown in FIG. 8, it is necessary to set / delete all affected flow entries, but aggregation is performed as shown in FIG. If there is, the number of flow entries that need to be set / deleted is reduced, so that the switching processing time is shortened and the fault tolerance performance is improved.

  In this embodiment, the number of flow entries of OFS_A 10a and OFS_E 10e increases compared to the case where flows having the same destination are aggregated as shown in FIG. 9, but as shown in FIG. Flows 1 and 3 and flows 2 and 4 are mixed, and it is no longer difficult to determine which one has generated abnormal traffic.

  10 to 12 summarize the differences between the flow entry set in the aggregation mode described in the present embodiment in each OFS and the flow entry set in the non-aggregation mode as shown in FIG. In the following description, OFS located at the start point of the packet transfer path and connected to the external node is Ingress OFS, and the OFS located at the end point of the packet transfer path and connected to the external node is Egress OFS, and OFS between Ingress and Egress Is referred to as Core OFS.

  FIG. 10 is a diagram showing a difference from the non-aggregation mode of the flow entry set in the Ingress OFS. As shown in the figure, the Ingress OFS is different in that the conversion of the source MAC address and the destination MAC address is added as an action, and as a result, the aggregation of flow entries in the Core OFS Packet restoration in Egress OFS is realized.

  FIG. 11 is a diagram showing a difference from the non-aggregation mode of the flow entry set in the Core OFS. In the Core OFS shown in the figure, a flow entry is set that uses a route ID converted in the Ingress OFS instead of the original destination MAC address as a matching rule.

  FIG. 12 is a diagram showing a difference from the non-aggregation mode of the flow entry set in Egress OFS. As shown in the figure, in the Egress OFS, in addition to the In_Port field, an action for restoring the source MAC address and the destination MAC address is added using the flow ID and path ID converted in the Ingress OFS as matching keys. Is different.

  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.

  For example, since the flow ID set in the OFS located in the middle of the packet transfer path described above uses the path ID as a matching rule, it can be set in advance without waiting for a flow entry setting request from the OFS. . In this case, the control device 20 may set a flow entry for executing header rewriting / restoration to the matching rule set in advance in the OFS located at the start point and end point of the packet transfer path. The load on the device 20 is reduced.

  In the above-described embodiment, the path ID is used as a matching rule. However, the MAC address of Egress OFS and other transfer section identifiers can be used as the path ID.

  In the above-described embodiment, the source / destination MAC address is rewritten. However, among the fields illustrated in FIG. 13, the above-described flow ID is assigned to a field that is not used for transfer in each node (OFS). It is also possible to adopt a configuration in which identifiers corresponding to the route IDs are written, these are rewritten from the original ones, and deleted or restored at the end points.

  In the above-described embodiment, the OFS (edge node) connected to the external node (terminals A to D) has been described as performing packet header conversion and restoration. However, any Core OFS ( The packet header may be converted and restored at the core node). For example, restoration may be performed by the OFS_C 10c and OFS_D 10d of FIG. 2, and a flow entry for performing packet processing may be set in the OFS_E 10e based on the original packet. Further, for example, in the OFS_A 10a in FIG. 2, a flow entry for performing packet processing is set based on the original packet, the packet header is converted in the OFS_B 10b in FIG. 2, and the flow entries of the OFS_C 10c and OFS_D 10d Variations such as aggregation are possible.

  In the above-described embodiment, the control device 20 includes the topology management unit 25 and the route calculation unit 26 and calculates the route by itself. However, the calculated route information is separately provided to the control device 20. A configuration in which a device is provided can also be employed.

Finally, a preferred form of the invention is summarized.
[First embodiment]
(Refer to the communication system according to the first viewpoint)
[Second form]
In the first form,
A processing rule for transferring a packet matching the path identifier to a node located in the middle of the aggregable section according to a packet transfer path calculated in advance is set.
A communication system for allocating a transfer path of the previously calculated packet when a processing rule setting request is newly received.
[Third embodiment]
In the first or second form,
A communication system for writing the flow identifier in a source MAC address field of a packet header.
[Fourth form]
In any one of the first to third forms,
A communication system for writing the path identifier in a destination MAC address field of a packet header.
[Fifth embodiment]
In any one of the first to fourth embodiments,
The nodes located at the start point and end point of the aggregateable section are edge nodes arranged at the boundary with the external node,
The node located in the middle of the aggregation possible section is a communication system that is a core node arranged between the edge nodes.
[Sixth embodiment]
The said control apparatus is a communication system provided with the path | route calculation part which calculates a packet transfer path | route further according to the request | requirement from the said node.
[Seventh form]
(Refer to the control device according to the second viewpoint)
[Eighth form]
In the seventh form,
A processing rule for transferring a packet matching the path identifier to a node located in the middle of the aggregable section according to a packet transfer path calculated in advance is set.
A control device for assigning a transfer path of the previously calculated packet when a new processing rule setting request is received.
[Ninth Embodiment]
In the seventh or eighth embodiment,
Write the flow identifier in the source MAC address field of the packet header,
A control device that writes the path identifier in a destination MAC address field.
[Tenth embodiment]
In any one of the seventh to ninth embodiments,
Furthermore, a control device comprising a route calculation unit for calculating a packet transfer route in response to a request from the node.
[Eleventh form]
(Refer to the processing rule setting method from the third viewpoint above.)
[Twelfth embodiment]
(Refer to the program from the fourth viewpoint above.)

10-1 to 10-n nodes 10a to 10e OFS (Open Flow Switch)
DESCRIPTION OF SYMBOLS 20 Control apparatus 21 OpenFlow protocol processing part 22 Switch information management part 23 Flow entry creation part 24 Path | route information management part 25 Topology management part 26 Path | route calculation part 30a-30d Terminal

Claims (9)

First means capable of communicating with a plurality of nodes constituting a network;
For the edge node that receives the packet from the packet source terminal, the first destination address included in the packet is rewritten to a second destination address including a plurality of destination addresses including the first destination address. A second means for instructing
A control device comprising: The control device according to claim 1, wherein the second means instructs a relay node included in the network to transfer the packet based on the second destination address. The second means instructs an edge node that receives the packet forwarded from the relay node to rewrite the second destination address to the first destination address. The control device according to 1 or 2. First means capable of communicating with a plurality of nodes constituting a network;
For the edge node that receives the packet from the packet source terminal, the first destination address included in the packet is rewritten to a second destination address including a plurality of destination addresses including the first destination address. A second means for instructing
A communication system comprising: The communication system according to claim 4, wherein the second means instructs a relay node included in the network to transfer the packet based on the second destination address. The second means instructs an edge node that receives the packet forwarded from the relay node to rewrite the second destination address to the first destination address. The communication system according to 4 or 5. Communicate with multiple nodes that make up the network,
For the edge node that receives the packet from the packet source terminal, the first destination address included in the packet is rewritten to a second destination address including a plurality of destination addresses including the first destination address. The control method characterized by instructing. The control method according to claim 7, wherein the relay node included in the network is instructed to transfer the packet based on the second destination address. The control according to claim 7 or 8, wherein an instruction is given to an edge node that receives the packet transferred from the relay node to rewrite the second destination address to the first destination address. Method.

Images