Patent Grant
9197494
The present Application claims priority rights based upon JP Patent Application No. 2010-232792 filed in Japan on Oct. 5, 2010. The total of the contents disclosed in the Application of the senior filing date is to be incorporated by reference into the present Application. This disclosure relates to a communication system, a control device, a node, a processing rule setting method and a program. More particularly, it relates to a communication system that implements communication by forwarding a packet(s) using a node(s) arranged in a network. It also relates to a node, a control device, a communication method and to a program.
Recently, a technique termed Open-Flow has been proposed (see Non Patent Literatures 1 and 2). The OpenFlow comprehends communication as an end-to-end flow and exercises path control, recovery from malfunctions, load distribution and optimization on the flow-by-flow basis. The OpenFlow switch, operating as a forwarding node, includes a secure channel for communication with an OpenFlow controller. The OpenFlow switch is operated in accordance with a flow table, addition in or rewriting of which is commanded from time to time by the OpenFlow controller. In a flow table, a set of a matching rule (header field) for matching to a packet header, an action defining the contents of processing and the flow statistics information (Stats), is defined on the flow-by-flow basis (see
For instance, upon receiving a first packet, the OpenFlow switch retrieves the flow table in search for an entry having a matching rule that matches to the packet's header information (FlowKey). If, as a result of the retrieval, the entry that matches to the incoming packet has been found, the OpenFlow switch applies to the incoming packet the contents of processing stated in an entry's action field. If, as a result of the above mentioned retrieval, no entry that matches to the incoming packet has been found, the OpenFlow switch forwards the incoming packet to the OpenFlow controller, over the secure channel, with a request to the controller to decide a path for the incoming packet based upon its source as well as destination. The OpenFlow switch then receives the implementing flow entry to update the flow table.
Non Patent Literature 3 shows a design statement of a protocol for separating a forwarding element and a control element (ForCES). In 4.3.1.2.2, Transaction Protocol of the Non Patent Literature 3, it is stated that two-phase commit control is to be used for transactional management of a plurality of messages within one forwarding element or across a plurality of forwarding elements.
It is now supposed that an OpenFlow controller, requested to decide the above mentioned forwarding path for the received packet, is to forward the received packet and succeeding packets belonging to the same flow. The OpenFlow controller, inclusive of the OpenFlow controllers of the Non Patent Literatures 2 and 3, are referred to below as the ‘control device’. In this case, it is necessary to set integrated flow entries in the total of the OpenFlow switches that are present on the forwarding path. The OpenFlow switches, inclusive of the OpenFlow controllers of the Non Patent Literatures 2 and 3, are referred to below as ‘nodes’, and the flow entries, inclusive of the flow entries stored in the flow tables of the OpenFlow switches of the Non Patent Literatures 2 and 3, are referred to below as ‘processing rules’ or ‘packet handling operations’. It is noted that, in case proper processing rules failed to be set in a part of the nodes on the forwarding path, it is likely that not only packets are dropped, but also an occurrence may happen where the packets are forwarded in a loop fashion. It is thus necessary to detect such failure to take prompt measures.
It may also be feared that, after setting the processing rules, part of the processing rules is erased due to node failures. In such case, there is a possibility that integrity of the flow entry is lost.
However, with the OpenFlow design specification of Non Patent Literature 2, even if there is a node(s) where the above mentioned proper processing rule failed to be set, such node requests the control device to set the processing rule(s) again when the node has received a succeeding packet, thereby restoring the integrity. Viz., the OpenFlow design specification of Non Patent Literature 2 lacks in a scheme where the lack in integrity of the processing rules is promptly detected to take proper measures.
In view of the above depicted status of the art, the present disclosure has been achieved. It is an object of the present disclosure to provide a communication system in which it is possible to set and hold integrated processing rules in a node or nodes. It is also intended by the present disclosure to provide a control device, a node, a processing rule setting method and a program.
In a first aspect of the present disclosure, a communication system includes a plurality of nodes, and a control device. Each of the nodes includes a packet processor that processes a packet in accordance with a processing rule(s) when the packet is received. The processing rule(s) correlates the processing to be applied to the packet with a matching rule that identifies the packet to which the processing is to be applied. The control device calculates a packet forwarding path in response to a request to set the processing rule(s) from any (arbitrary) one of nodes. The control device sets a plurality of the processing rules that implement the packet forwarding path for the node(s) present on the packet forwarding path, and records the processing rules in correlation with one another. The control device inquires at the node(s) present on the packet forwarding path about setting states of the processing rule(s). In case a failure is detected in the processing rule(s) set in at least one of the nodes on the packet forwarding path, the control device carries out a rollback operation of the correlated processing rule(s) set in other node(s) on the packet forwarding path.
In a second aspect of the present disclosure, a control device is connected to a plurality of nodes each having a packet processor that processes a packet in accordance with a processing rule(s) when the packet is received. The processing rule(s) correlates the processing to be applied to the packet with a matching rule that identifies the packet to which the processing is to be applied. The control device calculates a packet forwarding path in response to a request for setting a processing rule(s) from any one of nodes, while setting the processing rules that implement the packet forwarding path and recording the processing rules in a state correlated with one another. The control device inquires at the node(s) on the packet forwarding path about the processing rule setting states. When a failure is detected in the processing rule(s) set in at least one of the nodes, the control device performs a rollback operation of the correlated processing rules set in other node(s).
In a third aspect of the present disclosure, a node comprises a packet processor that processes a packet in accordance with a processing rule(s) when the packet is received. The processing rule(s) correlates the processing to be applied to the packet with a matching rule that identifies the packet to which the processing is to be applied. In response to an inquiry from any one of the control device(s) according to the second aspect aforementioned, the node returns a flow identifier accorded to the processing rule(s) and a transaction identifier accorded common to the processing rule(s) and the processing rule(s) correlated with the processing rule(s).
In a fourth aspect of the present disclosure, a method for setting a processing rule(s) includes a step in which a control device, connected to a plurality of nodes, calculates a packet forwarding path in response to a processing rule(s) setting request from the node(s). Each node has a packet processor that processes a packet, when the packet is received, in accordance with a processing rule(s) correlating a processing to be applied to the packet with a matching rule that identifies the packet the processing is to be applied to. In the above step, the control device sets a plurality of processing rules that implement the packet forwarding path for the nodes present on the packet forwarding path, while recording the processing rules as they are correlated with one another. The method also includes a step in which control device inquires at the node(s) on the packet forwarding path about a state of setting of the processing rules, and a step in which the control device carries out, in case a failure is detected in the processing rule(s) set in at least one node, a rollback operation for the correlated processing rule(s) set in other node(s). The present method is bound up with specified mechanisms, viz., nodes and the control device controlling these nodes.
In a fifth aspect of the present disclosure, a program may be run on a computer composing the above mentioned control device or node(s). The program may be recorded on a computer-readable recording medium which may be non-transient. Viz., the present invention may be implemented as a computer program product.
The meritorious effects of the present invention are summarized as follows.
According to the present invention, integrated processing rules may be set and maintained in the node(s).
Initially, the gist and outline of an exemplary embodiment of the exemplary embodiment of present invention will be explained. Referring to
It is assumed that the control device 20 has calculated a packet forwarding path via two nodes #1 and #2 of
After setting the above mentioned processing rules, the control device 20 inquires at the nodes #1 and #2 about the setting state of the above mentioned processing rules. In an inquiring method, a Barrier message (Request/Reply) or a statistics information request message (Stats Request/Reply), disclosed in Non Patent Literature 2, may be used.
If, as a result of the above inquiry, there is noticed a failure in the processing rule as set in a node, for example, node #2 of
For example, if, in case the packet sent from the host (A) is forwarded via the node #1 to the node #2, no processing rule having the matching rule matched to the packet has been set, a request is made to the control device for setting the processing rule. However, if there is a matching rule in the node #2 which belongs to another flow but which also matches to the packet in question, the packet is processed in accordance with the processing rule set in the node #2. Viz., the packet in question may be forwarded to another node, not shown, or may have its header re-written.
According to the present disclosure, since the rollback operation is carried out using the setting hysteresis as described above, it is possible to prevent packet processing from being carried out in a non-intended manner.
In the case of
An exemplary embodiment 1 of the present disclosure will now be described with reference to the drawings.
The processing rule setting devices of the first cluster 20a, 20b (the processing rule setting devices of the second cluster 20c, 20d) set processing rules in nodes that are placed under their management. It is assumed that, in the case of
A path control device 30 calculates a packet forwarding path and prepares corresponding processing rules, based upon requests for preparing the processing rules forwarded from the processing rule setting devices that are in the active states. These are the processing rule setting device of the first cluster 20a and the processing rule setting device of the second cluster 20e among the processing rule setting devices 20a to 20d. The path control device commands the processing rule setting devices in the active states to set the processing rules prepared as described above. The path control device 30 also makes inquiries at the processing rule setting devices in the active states as to whether or not the processing rules have been correctly set. The path control device records the results in a transaction log it holds, while performing rollback as necessary.
The system management device 40 checks the operating states of the processing rule setting devices 20a to 20d and, based upon the so checked results, switches between the currently operating running system and the spare system.
The various devices that make up the above mentioned communication system will now be described in detail with reference to the drawings.
(Node)
Under instructions from the processing rule setting devices 20a to 20d, the flow table setting unit 12 sets or adds a processing rule to the flow table 15, changes or rewrites the processing rule registered in the flow table, or deletes the so registered processing rule.
The event buffer 13 is a buffer that stores pointers in accordance with a FIFO (First In First Out) system, as shown in
In response to inquiries from the processing rule setting devices 20a to 20d about the processing rule setting states, the journal transmitting unit 14 reads out a processing rule at a position indicated by the event buffer 13, and transmits journal data. These journal data include the transaction ID and the flow ID of the processing rule in question. It is noted that, if the above inquiries from the processing rule setting devices 20a to 20d use a Barrier message (Barrier Request), a Barrier message (Barrier Reply) of the Non Patent Literature 2 may be used as a response. By the Barrier message is meant a message that instructs returning, as a response, the processing contents executed by the node in question before the node received the Barrier message (Barrier Request). Stats Request/Reply, making an inquiry into the statistic information regarding the processing rule (Stats), may also be used to check to see whether or not an entry has been correctly set in each node.
The flow table 15 has, as one entry, a matching rule (Rule), contents of processing (Actions), statistic information (Stats), a flow ID (FlowID) and a transaction ID (Transaction IDs), as shown in
The packet processor 16 retrieves the flow table 15 in search for a processing rule having a matching rule matched to the packet received by the packet receiving unit 18 to execute the contents of processing (Actions) stated in the processing rule. In addition, if the matching rule matched to the packet received by the packet receiving unit 18 has not been found in the flow table 15, the packet processor 16 sends the packet (unknown packet) to the processing rule setting devices 20a to 20d to ask them to set the processing rule.
In case the contents of processing stated in the processing rule (Actions) are for packet forwarding (Output), the packet transmitting unit 17 outputs the packet to the next hop via the port specified by the contents of processing (Actions).
The above node 10 may also be implemented by a configuration composed essentially of the OpenFlow switch of Non Patent Literature 2 added by the event buffer 13 and the journal transmitting unit 14.
(Processing Rule Setting Device)
The request accepting unit 22 accepts a variety of requests from the path control device 30 or the system management device 40 to forward a packet to other processing units in response to contents of the requests.
The cluster management unit 23 performs communication for status synchronization with the processing rule setting devices belonging to the same cluster. In more concrete terms, if the processing rule setting device 20a is operating in an active system, the cluster management unit 23 sends the processing rule, the cluster management unit requested the processing rule setting unit 24 to set in the node 10, to the processing rule setting device of the standby system, such as the processing rule setting device 20b, for backup recording. On the other hand, if the processing rule setting device 20a is operating in a stand-by system, the cluster management unit 23 performs the processing of recording the processing rule, received from the processing rule setting device of the active system, for example, the processing rule setting device 20b, in the processing rule setting log memory 27 of the setting device of the stand-by system.
The processing rule setting unit 24 forwards a request for setting a processing rule or a rollback command, received from the path control device 30, to the relevant node 10, while registering the contents of the request or the command in the processing rule setting log memory 27.
The journal acquisition unit 26 inquires at the node 10 about the processing rule setting state, and acquires journal data, including the flow ID and the transaction ID, included in turn in the processing rule at a location indicated by a pointer of the event buffer 13 of the node 10.
The journal confirmation unit 25 matches journal data, including the flow ID and the transaction ID, acquired by the journal acquisition unit 26, to the setting hysteresis of the processing rules stored in the processing rule setting log memory 27. The journal confirmation unit thus confirms whether or not the processing rule set by the processing rule setting unit 24 has been correctly set in the node 10. The journal confirmation unit 25 also sends the results of the confirmation to the path control device 30.
In case the processing rule setting device 20a is operating as the active system, the processing rules, as set by the processing rule setting unit 24, are sequentially registered in the processing rule setting log memory 27. In case the processing rule setting device 20a is operating in the stand-by system, the processing rules, received via cluster management unit 23 from the other processing rule setting device 20b, are so registered. Viz., the contents of the processing rule setting log memories 27 of the processing rule setting device of the active system 20a and the processing rule setting device of the stand-by system 20b are maintained synchronized in such a manner that the contents registered in the flow tables 15 of the respective nodes are in an accumulated, summarized state.
(Path Control Device)
The main processor 31 references the network topology, and calculates, from a request for setting a processing rule, a packet forwarding path along which to forward the packet received. The main processor also prepares a processing rule to be set in each node on the packet forwarding path.
The processing rule setting unit 32 requests the processing rule setting devices, associated with the nodes on the packet forwarding path, to set the processing rules prepared by the main processor 31.
The transaction confirmation unit 33 updates transaction logs, based upon the results of confirmation from the respective processing rule setting devices indicating whether or not the processing rules as set by the respective processing rule setting devices have been correctly set in the nodes 10. If, as a result of the update, failed setting of the processing rule having a certain transaction ID is noticed, the transaction confirmation unit 33 instructs the processing rule setting device, supervising the node where the processing rule having the transaction ID has been set, to carry out rollback via the main processor 31.
It is noted that a computer program that allows the respective components (processing means) of the processing rule setting devices 20a to 20d and the path control device 30, shown in
The operation of the present exemplary embodiment will now be explained in detail with reference to the drawings.
Referring first to
On receiving the request for setting a processing rule, the processing rule setting devices 20a and 20c, operating in the active state, request the processing rule setting devices 20b and 20d, waiting in the stand-by state, to record the processing rules ((2) of
On receiving a notification of the end (completion) of recording of the processing rules ((3) of
In response to an inquiry into the state of processing rule setting from the processing rule setting devices 20a and 20c, the node 10, in which the processing rule has been set, returns the flow ID and the transaction ID as the processing rule setting state ((5) of
Given that a failure has occurred in the processing rule setting device 20a and has been detected by the system management device 40, a regular flow ID and a regular transaction ID are returned from the processing rule setting device 20c as a response ((7) of
Since no response is returned from the processing rule setting device 20a (timing-out), the path control device 30 concludes that setting of a series of processing rules, having the relevant transaction ID concerned, ended up with a failure, and commands the processing rule setting device 20c to carry out rollback by designating the transaction ID concerned ((8) of
On receiving a processing rule rollback command, the processing rule setting device 20c requests the processing rule setting device 20d, waiting in the standby system, to record the rollback contents ((9) of
On receiving a notification concerning the end of recording of the rollback contents from the processing rule setting device 20d, so far waiting in the standby system ((10) of
In response to an inquiry from the processing rule setting device 20c about the rollback processing state, the node 10, which received the command for rollback, returns the flow ID and the transaction ID, by way of a notification concerning the rollback end ((12) of
If, with the notification concerning the rollback end, the processing rule setting device 20c has confirmed that the rollback has been carried out correctly, it sends a notification concerning the rollback end to the path control device 30 ((13) of
At this time point, the processing rules on the second cluster side, the integrity of which is not guaranteed, are deleted.
Subsequently, the system management device 40 activates the processing rule setting device 20b in place of activating the processing rule setting device 20a ((14) of
On receiving the journal data send request, the node 10 returns the journal data including the flow ID and the transaction ID, by way of a notification of the flow table setting state ((16) of
On receiving the request for confirming whether or not rollback is to be carried out, the path control device 30 references the transaction log 34 to confirm whether or not the rollback is to be performed from the perspective of the entire transaction. Since here the rollback was already commanded to the processing rule setting device 20c, as explained at (8) and (11) in
On receiving the rollback command, the processing rule setting device 20b commands rollback to the node 10 specified ((19) of
In response to the inquiry into the rollback processing state from the processing rule setting device 20b, the node 10, which has received the rollback command, returns the flow ID and the transaction ID, by way of notification of the rollback end ((20) of
With the notification of the rollback end, the processing rule setting device 20b is able to confirm that the rollback has correctly been carried out. The processing rule setting device 20b then transmits a notification of the rollback end to the path control device 30 ((21) of
At a stage where the above mentioned sequence of processing operations has come to a close, the processing rule setting device 20b notifies the system management device 40 of the end of activation ((22) of
With the above mentioned processing stage, the processing rules on the first cluster side, whose integrity is not guaranteed, has also been deleted. The path control device 30 may again request the processing rule setting devices 20b, 20c to set the processing rules, thereby enabling setting of an as-intended processing rule in an as-intended node.
Moreover, in the configuration of the present exemplary embodiment, not only may the integrity be maintained in setting the processing rules, but also the control device is functionally distributed into a processing rule setting device portion and a path control device portion. In addition, the individual processing rule setting devices are formulated in a plurality of clusters, and the processing rule setting devices of each cluster are formed redundantly, viz., there are provided a plurality of redundant processing rule setting devices for each cluster. This results in distribution of the load of the individual processing rule setting devices. Furthermore, if a given processing rule setting device has failed, the operation may be shifted to a standby system device to continue rendering of services, thereby assuring a high degree of usability.
In the above described exemplary embodiment 1, explanation has been given on the case where the rollback is carried out by referencing the processing rule setting log memory 27 arranged on the processing rule setting device side. Also there is a possible configuration, however, in which a processing rule setting log is owned by the node 10, such that rollback may be carried out on the node side.
An exemplary embodiment 2 of the present disclosure, in which the rollback is carried out on the node side, will now be explained. It is noted that, in the following explanation, the description on the matter common to the exemplary embodiment 1 is dispensed with and mainly the point of difference from the exemplary embodiment 1 will be explained.
The operation of the present exemplary embodiment will now be explained in detail with reference to the drawings.
The processing rule setting device 20b, activated at (14) of
The node 10A, which received the request to send journal data, returns journal data including the flow ID and the transaction ID as a response ((16) of
On receiving the processing rule setting log 27 from the processing rule setting device 20c ((18A) of
Here, the journal data of the node 10A, received at (16) of
The node 10A carries out the rollback, using the above mentioned processing rule setting log. Then, in response to an inquiry by the processing rule setting device 20b about the rollback processing state, the node 10A returns the flow ID and the transaction ID by way of a notification of the rollback end ((20A) of
When the processing rule setting device 20b has confirmed, by the notification concerning the rollback end, that rollback has completed correctly, the processing rule setting device 20b transmits a notification concerning the completion of activation (activation end) to the system management device 40 ((21A) of
With the above mentioned stage, deletion of processing rules on the first cluster side, whose consistency is not guaranteed, has been completed in the present exemplary embodiment. The path control device 30 again requests the processing rule setting devices 20b, 20c to set processing rules, as necessary, thereby enabling setting of an as-intended processing rule in an as-intended node.
With the node 10A now owning the processing rule setting log, as in the present exemplary embodiment, it is possible to properly carry out rollback, even with a configuration in which the node side holds setting contents of past processing rules.
An exemplary embodiment 3, in which a commit request/commit response is carried out between the path control device 30 and the processing rule setting devices 20a to 20d, will now be explained. Since the present exemplary embodiment 3 of the present disclosure may be implemented with a configuration equivalent to that of the exemplary embodiment 1 or 2, the operation of the exemplary embodiment 3 will be explained in detail with reference to the sequence block diagrams of
(1. Regular Ending)
Initially, the sequence of operations in case processing rules have been correctly set in the nodes 10 of the first and second clusters will be explained with reference to
In case an unknown packet is forwarded from the node 10 (step S000 of
On receiving the request for setting the processing rules, the processing rule setting devices 20a, 20c respectively request the processing rule setting devices 20b, 20d in the standby system (SBY) to record processing rules (step S002 of
On receiving the notifications of the recording end of the processing rules from the processing rule setting devices 20b, 20d (step S003 of
The processing rule setting devices 20a, 20c inquire at the nodes, specified by the path control device 30, about the processing rule setting states, and receive the corresponding results (step S005 of
The processing rule setting devices 20a, 20c then transmit the processing rule setting states to the path control device 30 (step S006 of
On receiving a commit OK from the processing rule setting devices 20a, 20c, the path control device 30 deems that the sequence of processing rules has correctly been set. Hence, the transaction is brought to an end.
(2. Rollback Operation Due to Node Failure)
Referring to
In the case of
On receiving the processing rule setting states, the processing rule setting device 20c sends the flow ID and the transaction ID, received from the node 10 of the second cluster, to the path control device 30, as the processing rule setting states (S106 of
The path control device 30 receives the correct flow ID and the correct transaction ID from the processing rule setting device 20a (S005 of
Thereafter, as at the time of setting the processing rules, rollback is commanded to each node 10 (S110 of
In the present exemplary embodiment, described above, rollback processing may be carried out correctly, even in case of occurrence of failure in processing rule setting in the node 10, based on contents delivered from the processing rule setting device 20a of the other cluster.
(3-1. Switching of Processing Rule Setting Devices Following the End of a Transaction)
Given that, after a sequence of correct processing operations is finished as shown in
The system management device 40 then activates the processing rule setting device 20b so far waiting in the standby system (S201 of
On receiving the journal data from the node 10 (S203 of
The path control device 30 references the transaction log 34 to make sure that the transaction as confirmed by the result of the matching has completed successfully. The path control device then returns an acknowledgement response (matching to the transaction log OK) to the processing rule setting device 20b (S205 of
On receiving the acknowledgement response (matching to the transaction log OK), the processing rule setting device 20b notifies the system management device 40 of the fact of the end of activation (S206 of
(3-2. Switching of the Processing Rule Setting Devices Due to Node Failure Following the Rollback End)
Given that, after the rollback end brought about by failed processing rule setting states from the node 10, the system management device 40 activated the processing rule setting devices of the standby system, the sequence of succeeding operations is as follows. It is noted that the operation of the steps S000 up to S112 of
The next following operations are like those of the steps S201 to S205. However, rollback has completed in the processing rule setting device 20c, as confirmed by referencing the transaction log 34. Hence, the path control device 30 commands rollback to the processing rule setting device 20b as well (S207 of
At a stage a notification of the rollback end is received from the processing rule setting device 20b (S208 of
The processing rule setting device in the activated state confirms whether or not the processing rules as set in the node is synchronized with the processing rule comprehended by the setting device itself. In addition, the processing rule setting device carries out matching to the transaction log, as described above. Thus, even in case the processing rule setting devices are switched by the system management device 40, integrity of the processing rules set in the respective nodes is not lost.
(4. Failure in the Processing Rule Setting Device Before the End of the Setting of Processing Rules or Before the End of Rollback)
The operation in the case of failure of a processing rule setting device of the active system that occurred at some time as from the time of a request for processing rule setting until commit OK (end of rollback), will now be explained for each of a plurality of different timings of failure occurrence.
It is seen from above that, no matter at which timing a processing rule setting device should have failed, the so failed device is changed over to another processing rule setting device of the standby system. Then, by performing matching to the node's journal data, it is determined whether or not rollback is necessary. Hence, a consistent processing rule setting state may be maintained.
Although the description has been made of preferred exemplary embodiments of the present invention, these are given only by way of illustration and are not intended to limit the scope of the invention. That is, further modifications, substitutions or adjustments may be made without departing from the basic technical concept of the present invention. For example, it has been explained in the exemplary embodiment 3 that a commit is executed on the processing rule setting device operating in the active system. It is however also possible to execute a commit also on the processing rule setting device waiting in the standby system (exemplary embodiment 4), as shown in
The configuration of the exemplary embodiments, described above, includes a single path control device, two clusters and two processing rule setting devices for each of the two clusters. Such configuration is only for simplifying the illustration of the exemplary embodiments of the invention. It is of course possible to change the number of the path control devices or the processing rule setting devices as desired depending on design parameters required of the communication system according to the present disclosure. The disclosures of the aforementioned Non Patent Literatures are incorporated herein by reference thereto. The particular exemplary embodiments or examples may be modified or adjusted within the gamut of the entire disclosure of the present invention, inclusive of claims, based on the fundamental technical concept of the invention. Further, a variety of combinations or selection of elements disclosed herein may be made within the scope of the claims.
Preferred forms of the present disclosure will now be summarized as follows.
(Mode 1)
(See Communication System According to the Above Mentioned First Aspect)
(Mode 2)
The communication system according to mode 1, wherein, the control device concludes whether or not an individual processing rule is set and whether or not the processing rules correlated with one another are set based on whether or not a flow identifier accorded to the processing rule set in the node be included in a response from the node; on whether or not a transaction identifier accorded common to the correlated processing rules be included in a response from the node.
(Mode 3)
The communication system according to mode 1 or 2, wherein, the control device is preset in a redundant (multiple) fashion; the processing rule(s) as set is stored for backup in the redundant control device waiting in a standby system.
(Mode 4)
The communication system according to mode 3, wherein, when changed over to an active state, the redundant control device, waiting in the standby system, continues setting the processing rule(s) in the node, or executes a rollback operation, based on a setting state(s) of the processing rule(s) received from the node and the processing rule(s) stored for backup.
(Mode 5)
The communication system according to any one of modes 1 to 4, wherein, the control device includes a path control device that, in response to a request for setting a processing rule from any (arbitrary) one of the nodes, calculates a packet forwarding path to prepare a processing rule(s) that implements the packet forwarding path; and a plurality of processing rules setting devices each of which sets the processing rule(s) for the node(s) on the packet forwarding path belonging to a cluster the processing rule setting device in question belongs to.
(Mode 6)
The communication system according to mode 5, wherein, the node holds, in a manner correlated with one another, a pre-update processing rule(s) for the node and a transaction identifier accorded common to the processing rules correlated with one another and to the pre-update processing rule(s) for the node;
the processing rule setting device receiving, in case of detection of a failure in the processing rule as set in at least one node, an as-set processing(s) rule from the processing rule setting device belonging to another cluster to carry out rollback based on a transaction identifier included in the as-set processing rule(s).
(Mode 7)
The communication system according to mode 5 or 6, wherein,
in case the path control device succeeded in setting the processing rules, correlated with one another, the path control device requests a commit to each processing rule setting device; the path control device carrying out a rollback operation in case commit responses from the processing rule setting devices are not in harmony.
(Mode 8)
(See the Control Device According to the Second Aspect)
(Mode 9)
The control device according to mode 8, wherein, the control device concludes whether or not an individual processing rule is set and whether or not the processing rules correlated with one another are set based on whether or not a flow identifier accorded to the processing rule set in the node be included in a response from the node; and on whether or not a transaction identifier accorded common to the correlated processing rules be included in a response from the node.
(Mode 10)
The control device according to mode 8 or 9, wherein, the control device is connected to a redundant control device waiting as a standby system, the redundant control device storing the as-set processing rule for backup.
(Mode 11)
The control device according to mode 10, wherein, when changed over to an active state, the redundant, waiting as the standby system, continues setting the processing rule(s) in the node, or executes a rollback operation, based on a setting state(s) of the processing rule(s) received from the node and the processing rule(s) stored for backup.
(Mode 12)
The control device according to any one of modes 8 to 11, wherein, the control device includes a path control device that, in response to a request for setting a processing rule(s) from any (arbitrary) one of the nodes, calculates a packet forwarding path to prepare a processing rule(s) that implements the packet forwarding path; and a plurality of processing rule(s) setting devices each of which sets the processing rule(s) for the node(s) on the packet forwarding path belonging to a cluster the processing rule setting device in question belongs to.
(Mode 13)
The control device according to mode 12, wherein, the node holds, in a manner correlated with one another, a pre-update processing rule(s) for the node and a transaction identifier accorded common to the processing rules correlated with one another and to the pre-update processing rule(s) for the node; the processing rule(s) setting device receiving, in case of detection of a failure in the processing rule(s) as set in at least one node, an as-set processing rule from the processing rule setting device belonging to another cluster, to carry out rollback based on the transaction identifier included in the as-set processing rule(s).
(Mode 14)
The control device according to mode 12 or 13, wherein, in case the control device succeeded in setting the processing rules, correlated with one another, the control device requests a commit to each processing rule setting device; the path control device carrying out a rollback operation in case commit responses from the processing rule setting devices are not in harmony.
(Mode 15)
(See the Node According to the Above Mentioned Third Aspect)
(Mode 16)
The node according to mode 15, wherein, the node further holds, in a manner correlated with one another, a pre-update processing rule for the node and a transaction identifier accorded common to the processing rules correlated with one another and to the pre-update processing rule(s) for the node; the node carrying out a rollback operation based on the transaction identifier.
(Mode 17)
(See the Method for Setting a Processing Rule According to the Above Mentioned Fourth Aspect)
(Mode 18)
(See the Program for the Control Device According to the Above Mentioned Fifth Aspect)
(Mode 19)
(See the Program for the Node According to the Above Mentioned Fifth Aspect)
| Number | Date | Country | Kind |
|---|---|---|---|
| 2010-232792 | Oct 2010 | JP | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/JP2011/005012 | 9/7/2011 | WO | 00 | 4/1/2013 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2012/049807 | 4/19/2012 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 20030185226 | Tang et al. | Oct 2003 | A1 |
| 20070076606 | Olesinski et al. | Apr 2007 | A1 |
| 20080189769 | Casado et al. | Aug 2008 | A1 |
| 20080222275 | Yumoto | Sep 2008 | A1 |
| 20110173490 | Narayanaswamy et al. | Jul 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 1961536 | May 2007 | CN |
| Entry |
|---|
| International Search Report in PCT/JP2011/005012 dated Oct. 4, 2011. |
| A. Doria, et al. “RFC5810—Forwarding and Control Element Separation (ForCES) Protocol Separation” [retrieved on Sep. 21, 2010] Internet <URL: http://www.faqs.org/rfcs5810.html>. |
| “OpenFlow Switch Specification” Version 1.1.0. (Wire Protocol 0x01) [retrieved on Sep. 21, 2010] Dec. 31, 2009 Internet <URL: http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf>. |
| Nick McKeown et al, “OpenFlow: Enabling Innovation in Campus Networks”, [retrieved on Sep. 21, 2010] Mar. 14, 2008, Internet <URL: http://www.openflowswitch.org//documents/openflow-wp-latest.pdf>. |
| Masashi Hayashi, et al. “Flow Entry Control using Transaction Management”, Proceedings of the 2010 IEICE General Conference, Mar. 2, 2010. |
| Chinese Office Action dated Jul. 29, 2015 with an English translation thereof. |
| Number | Date | Country | |
|---|---|---|---|
| 20130201821 A1 | Aug 2013 | US |
