WO2011149003A1 - 通信システム、ノード、制御装置、通信方法およびプログラム - Google Patents

通信システム、ノード、制御装置、通信方法およびプログラム Download PDF

Info

Publication number
WO2011149003A1
WO2011149003A1 PCT/JP2011/062046 JP2011062046W WO2011149003A1 WO 2011149003 A1 WO2011149003 A1 WO 2011149003A1 JP 2011062046 W JP2011062046 W JP 2011062046W WO 2011149003 A1 WO2011149003 A1 WO 2011149003A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
received packet
rule
processing
packet
Prior art date
Application number
PCT/JP2011/062046
Other languages
English (en)
French (fr)
Inventor
靖伸 千葉
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to KR1020127031930A priority Critical patent/KR20130032314A/ko
Priority to CN201180022831.3A priority patent/CN102884769B/zh
Priority to BR112012030135A priority patent/BR112012030135A2/pt
Priority to RU2012157742/08A priority patent/RU2556457C2/ru
Priority to AU2011259267A priority patent/AU2011259267B2/en
Priority to EP11786702.8A priority patent/EP2579510B1/en
Priority to JP2012517305A priority patent/JP5370588B2/ja
Publication of WO2011149003A1 publication Critical patent/WO2011149003A1/ja
Priority to US13/333,827 priority patent/US9426061B2/en
Priority to HK13108288.9A priority patent/HK1181928A1/xx

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0873—Checking configuration conflicts between network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/342—Signalling channels for network management communication between virtual entities, e.g. orchestrators, SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/60—Router architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • 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.
  • 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.
  • a set of a collation rule (FlowKey / matching key) that collates with the packet header, an action (Action) that defines the processing content, and flow statistical information (Stats) is defined (FIG. 30).
  • FIG. 31 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.
  • the OpenFlow switch when it receives the first packet (first packet), it searches the flow table for an entry having a matching 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.
  • FlowKey matching rule
  • the OpenFlow controller that has received the request for determining the path of the received packet (see s2 Packet-In in FIG. 33) determines the transfer path of the received packet.
  • flow entries are set in all open flow switches (node # 1 and node # 2 in FIG. 33) on the transfer path.
  • the OpenFlow controller may change an action for a flow entry that has been set based on an instruction or the like of a network administrator. At that time, it is necessary to change or delete the flow entry.
  • Non-Patent Document 2 When the above flow entry is set / changed / deleted using the OpenFlow protocol (see “4.6 Flow Table Modification Messages” in Non-Patent Document 2), there will be a delay in communication between the OpenFlow controller and the OpenFlow switch. In some OpenFlow switches, setting / changing / deleting the flow entry is not in time, and in the OpenFlow switch on the route, the packet matches an unintended flow entry on the flow table and an unintended action is executed. There is a problem that.
  • FIG. 32 shows a case where the OpenFlow switch (node # 1) that has received a packet addressed to the host (B) from the host (A) makes a flow entry creation request to the controller, and the relay switch (node # 2)
  • the node # 2 conflicts with the matching key X of the flow entry to be set (the OpenFlow protocol allows partial matching of an arbitrary header field as a matching key and conflicts between the flow entries.
  • the OpenFlow protocol allows partial matching of an arbitrary header field as a matching key and conflicts between the flow entries.
  • There is a flow entry with a matching key B the avoidance is controlled by the search order of flow entries).
  • the packet transmitted from the host (A) is transferred to the port # 1 instead of the port # 2 that should be output until the setting of the flow entry is completed (FIG. 32). ST8).
  • unintended packet transfer execution of action
  • the (open flow) controller sends a flow entry to the nodes # 1 and # 2 (see FlowMod (Add) of s3 and s6 in FIG. 33) and is opened. It is conceivable to transmit a Barrier Request defined in the flow protocol (see “5.3.7 Barrier Message” of Non-Patent Document 2 for s4 Barrier Request; Barrier Request / Reply in FIG. 33). The node that has received the Barrier Request completes the execution of the process received before the Barrier Request is received, and responds as “Barrier Reply” (s5 in FIG. 33). As a result, the (OpenFlow) controller can confirm that the flow entry is set correctly.
  • Another method is to check whether each node has a corresponding entry by using Stats Request / Reply instead of Barrier Request / Reply.
  • the Barrier Request / Reply is also used.
  • the present invention has been made in view of the above-described circumstances, and the object of the present invention is that, as described above, an inappropriate processing rule (flow entry) is hit in a node and an unintended process is executed. It is an object to provide a communication system, a node, a control device, a communication method, and a program that can suppress the above.
  • a control device sets a node that processes a received packet, a matching rule, and a processing rule that defines processing of a packet that conforms to the matching rule in the node.
  • the node holds the identifier in association with the processing rule, and determines whether or not the received packet can be executed by the processing rule corresponding to the matching rule that matches the received packet.
  • the matching rule that matches the identifier of the received packet and the received packet.
  • a communication system that determines whether or not an identifier associated with a processing rule corresponding to is associated.
  • a processing rule that defines a matching rule and processing of a packet that conforms to the matching rule is held in association with the identifier, and matches the identifier of the received packet and the received packet.
  • an identifier for generating a processing rule that defines a matching rule and processing of a packet that conforms to the matching rule, and is associated with the processing rule, the received packet is transmitted to the node.
  • a control device for setting is provided.
  • a processing rule that defines a matching rule and processing of a packet that matches the matching rule is held in association with the identifier, and matches the identifier of the received packet and the received packet.
  • a communication method for processing is provided. The method is tied to a specific machine, a node that processes received packets.
  • an identifier for generating a processing rule defining a matching rule and processing of a packet conforming to the matching rule, and an identifier associated with the processing rule, the received packet Generating an identifier for determining whether or not the processing of the received packet can be executed according to the processing rule corresponding to the matching rule, and the processing rule and the identifier are arranged in a node arranged in the communication system and processing the received packet.
  • a communication method for setting is provided. This method is linked to a specific machine called a control device that sets the processing rule in a node that processes a received packet.
  • a process for storing a processing rule specifying a matching rule and a packet processing conforming to the matching rule in association with an identifier in a node that processes the received packet in the communication system And whether the processing of the received packet by the processing rule corresponding to the matching rule that matches the received packet corresponds to the identifier of the received packet and the identifier associated with the processing rule corresponding to the matching rule that matches the received packet and a process for determining whether or not to perform the program.
  • This program can be recorded on a computer-readable storage medium. That is, the present invention can be embodied as a computer program product.
  • a control rule that controls a node that processes a received packet generates a processing rule that defines a matching rule and processing of a packet that matches the matching rule.
  • Processing and an identifier associated with the processing rule the node generating an identifier for determining whether or not the processing of the received packet by the processing rule corresponding to the matching rule matching the received packet can be executed,
  • a program for executing a process rule and a process of setting the identifier in the node is provided. This program can be recorded on a computer-readable storage medium. That is, the present invention can be embodied as a computer program product.
  • FIG. 5 is a diagram for explaining information held in a flow entry DB of the control device (controller) in FIG. 4. It is a figure for demonstrating the information hold
  • a node 10 (see node # 2 in FIG. 1) of the communication system of the present invention receives a packet, a collation rule (matching key) in a processing rule held by the own device. ) To extract a processing rule that matches the received packet (step 1). Next, the node 10 (see node # 2 in FIG. 1) confirms that the identifier associated with the extracted processing rule matches the identifier included in the received packet (step 2).
  • the present invention is not limited to this.
  • the case where the node 10 confirms that the identifier associated with the processing rule and the identifier included in the received packet are in a correspondence relationship is also included.
  • the node 10 executes the processing according to the processing rule. (Step 3).
  • the identifier described above is information generated by the control device (controller) 20 in association with the processing rule, and is generated and assigned so that at least processing rules that can be matched with the received packet can be identified. Therefore, even if the processing rule is extracted by the search using the matching rule (matching key), if the identifiers do not match, the action of the processing rule is not executed.
  • various forms such as a form added to the user packet as shown in FIGS. 1 and 2 and a form embedded in a specific area of the user packet (see FIG. 19) are adopted. be able to.
  • the identifier associated with the extracted processing rule matches the identifier of the received packet.
  • the collation rule (matching key) of the extracted processing rule is the value of the received packet. It is also possible to adopt a method of confirming that the contents (header information to be collated with the collation rule (matching key)) match.
  • FIG. 3 is a diagram showing a configuration of a communication system according to the first embodiment of the present invention.
  • a control device controller
  • hosts A and (B) that communicate via the node 10
  • three nodes 10, a control device (controller) 20, and two hosts (Host (A) and Host (B)) are shown. There can be any number.
  • FIG. 4 is a diagram showing a detailed configuration of the control device (controller) 20.
  • the control device (controller) 20 includes a flow entry database (flow entry DB) 21 storing a processing rule (flow entry) and verification information associated with the processing rule, and a node communication unit 26.
  • flow entry DB flow entry database
  • a topology management unit 22 that constructs network topology information based on the connection relationship of the nodes 10 collected in this way, a packet forwarding path based on the network topology information constructed by the topology management unit 22, and nodes on the forwarding route
  • the route / action calculation unit 23 for obtaining an action to be executed by the network 10 and the processing rule (flow entry) and verification information calculated by the route / action calculation unit 23 and the verification information generation unit 28 are associated with each other and registered in the flow entry DB 21.
  • Processing rules (flow entry) from node 10 A flow entry management unit 24 that responds to a request for addition, updates a processing rule (flow entry) and verification information, a control message processing unit 25, a node communication unit 26 that communicates with the node 10, and a flow entry management A verification information generation unit 28 that generates verification information to be included in the processing rule in response to a request from the unit 24 or extracts the verification information from the verification information database (verification information DB) 27.
  • the verification information indicates information corresponding to the identifier used for verifying a matching result between the received packet and the processing rule based on the matching rule.
  • control message processing unit 25 includes a message analysis / processing unit 251 that analyzes a control message received from the node 10 and performs necessary processing, and a message generation unit 252 that generates a message to be transmitted to the node 10. Configured.
  • FIG. 5 is a diagram schematically showing information (flow entry and verification information) held in the flow entry DB 21.
  • the first to third entries from the top of FIG. 5 are the processing rules (flow entries) set in the nodes whose DPID (identifier of node 10; Datapath Identifier) is 1 to 3, respectively, and the verifications associated with the processing rules. Information is shown (the same applies to the fourth to sixth entries from the top).
  • a node whose DPID is 1 receives a packet matching the matching key “A” as shown in the first entry from above, its action field (Actions) Then, after adding a header including verification information “CA”, a process of outputting from the ninth port is executed.
  • a node having a DPID of 2 receives a packet matching the matching key “A” from a node having a DPID of 1 (for example, node # 1 in FIG. 3). Then, processing to output from the 6th port is executed. Then, when a node having a DPID of 3 (for example, node # 3 in FIG.
  • FIG. 6 is a diagram schematically showing information (verification information) held in the verification information DB 27.
  • the verification information DB 27 includes the matching keys “A”, “B”,..., “X” and verification information “CA”, “CB”,. "Is held.
  • the verification information generation unit 28 generates verification information corresponding to the processing rule (flow entry) requested from the flow entry management unit 24 and registers it in the verification information DB 27.
  • Such verification information includes, for example, a plurality of rules that match at least a received packet by using a collation rule (hereinafter referred to as a “matching key”) and a predetermined function (such as a hash function) with other information as an argument.
  • a collation rule hereinafter referred to as a “matching key”
  • a predetermined function such as a hash function
  • a plurality of processing rules corresponding to each of the collation rules can be generated so that they are unique, that is, at least the same verification information is not given to these processing rules. It is also possible to generate statistically unique verification information using random numbers (a specific example will be described in detail later).
  • the verification information DB 27 is for the purpose of preventing duplication of verification information among a plurality of processing rules (flow entries) that may conflict with each other, and does not necessarily have the format shown in FIG. It is also possible to omit the verification information DB 27 by avoiding duplication of verification information in terms of probability and statistics.
  • the flow entry DB 21 can be omitted when there is no need to hold the processing rule (flow entry) instructed to be added or updated to the node 10 and the verification information associated with the processing rule. Similarly, when it is not necessary to hold the verification information generated in association with the processing rule, the verification information DB 27 can be omitted.
  • a configuration in which the flow entry DB 21 and the verification information DB 27 are separately provided in an external server or the like can also be employed.
  • the control device (controller) 20 as described above can associate the OpenFlow controller of Non-Patent Documents 1 and 2 with at least the verification information generation unit 28 and the node 10 with a processing rule (flow entry) and the processing rule. This can be realized by adding a function for setting verification information.
  • FIG. 7 is a diagram showing a detailed configuration of the node 10.
  • the node 10 includes a control device communication unit 11 that communicates with the control device (controller) 20, a flow table management unit 12 that manages the flow table 13, a packet buffer 14, and a transfer processing unit 15. It is prepared for. Note that the node 10 does not necessarily include the packet buffer 14.
  • the transfer processing unit 15 includes a table search unit 153 and an action execution unit 154.
  • the table search unit 153 includes a verification information collating unit 152 that collates verification information associated with a certain processing rule (flow entry) and verification information added to the received packet and determines whether they match.
  • the processing content (action) of the processing rule (flow entry) having the matching key that matches the received packet and that has the matching verification information is output from the flow table 13 to the action execution unit 154.
  • the action execution unit 154 executes the processing content (action) output from the table search unit 153.
  • the node 10 as described above has a configuration in which the verification information matching unit 152 is added to the OpenFlow switch, and the flow table 13 is configured to hold verification information in association with a processing rule (flow entry). It can also be realized.
  • the table search unit 153 including the verification information matching unit 152 of the node 10 as described above can also be realized by a program executed by a computer that configures the node 10.
  • FIG. 8 is a diagram schematically showing information (flow entry and verification information) held in the flow table 13 of the node having the DPID of 2 in FIG. 5 (node # 2 in FIG. 3).
  • a flow entry and verification information having the same contents as the corresponding DPID entry in the flow entry DB 21 of FIG. 5 are set.
  • the flow entries and verification information corresponding to the respective DPIDs are set in the nodes having the DPIDs 1 and 3 in FIG. 5 (nodes # 1 and # 3 in FIG. 3).
  • the packet 32 with verification information has a configuration in which an additional header 33 with verification information including verification information is added to the head of the user packet 31.
  • FIG. 10 is a diagram showing a configuration example of the additional header 33 with verification information.
  • the additional header 33 with verification information includes the MAC destination address (MAC DA), the MAC transmission source address (MAC SA), the upper protocol type (Ether Type), and the total header length (Total Length). Is added.
  • the value (f (matching key, rand)) calculated by a predetermined function (hash function or the like) having a matching key and a random number as arguments is used as verification information.
  • FIG. 11 is a flowchart showing the operation of the control device (controller) 20.
  • the control device (controller) 20 upon receiving an inquiry (processing rule creation request; see step S111 in FIG. 12) from the node 10 (step S001; Packet-In), the control device (controller) 20 sends a packet to the inquiry. It is confirmed whether or not verification information is included (step S002).
  • the control device (controller) 20 transmits the processing rule from the flow entry DB 21.
  • the processing rule corresponding to the packet and the verification information associated with the processing rule are extracted (step S012), and the process proceeds to step S008.
  • control device (controller) 20 acquires the network topology information constructed by the topology management unit 22, and transfers the packet transfer route. Is calculated (step S003).
  • the control device (controller) 20 except when it is determined that transfer cannot be performed due to a reason that a route cannot be created or a node on the route is faulty (No in step S004). Calculates an action corresponding to the calculated transfer path (step S005). Subsequently, verification information associated with a processing rule (flow entry) applied to each node 10 on the route is generated (step S006). Furthermore, the control device (controller) 20 generates a processing rule (flow entry) to be applied to each node 10 on the route including the matching key for specifying the flow to which the packet related to the inquiry belongs and the action ( Step S007).
  • control device (controller) 20 When the acquisition or generation of the processing rule (flow entry) and verification information is completed, the control device (controller) 20 generates the generated processing rule (flow entry) and verification information setting instruction (Flow Mod (Add)). (Step S008), a processing rule (flow entry) and verification information setting instruction (Flow Mod (Add)) are transmitted to the node 10 on the packet transfer path realized by the processing rule (flow entry) ( Step S009).
  • Step S011 When the node 10 does not buffer the packet (No in Step S010), the control device (controller) 20 issues a packet output instruction (Packet-Out) (Step S011).
  • This packet output instruction indicates a packet to be output (packet received by Packet-In in step S001) and an action to be performed on the packet (attachment of verification information and output from a designated port). Alternatively, it is performed by instructing a packet to be output (packet received by Packet-In in step S001) and an action to be performed on the packet (search for a flow table). If the node 10 is buffering the packet (Yes in step S010), as will be described later, the node 10 can cause the packet to be output, so the processing on the control device (controller) 20 side is as follows. Omitted.
  • FIG. 12 is a flowchart showing the operation of the node 10.
  • the node 10 when receiving a packet from the host or another node 10 (step S101), the node 10 searches the flow table 13 for a processing rule (flow entry) having a matching key matching the received packet (Ste S102).
  • step S104 the node 10 checks whether or not the verification information is included in the received packet. In the present embodiment, whether or not the verification information is included can be determined based on whether or not an additional header is added to the received packet.
  • the node 10 executes the action described in the extracted processing rule (flow entry) (step S107).
  • step S104 when it is determined in step S104 that the verification information is included in the received packet, the node 10 is associated with the verification information included in the received packet and the extracted processing rule (flow entry). The verification information is collated (step S105).
  • the node 10 executes the action described in the extracted processing rule (flow entry) (step S107).
  • a verification associated with the processing rule (flow entry) is performed. It is necessary that the information matches that of the received packet.
  • step S103 determines that the extracted processing rule (flow Without executing the action described in (entry)
  • the process proceeds to step S111, and the control device (controller) 20 is inquired (processing rule (flow entry) and verification information creation and transmission request corresponding to received packet).
  • step S111 the node 10 stores the received packet in the packet buffer 14 and transmits the received packet to the control device (controller) 20 to request creation of processing rules and verification information. Thereafter, the control device (controller) 20 performs response processing including processing rules and verification information in accordance with the procedure shown in FIG.
  • the node 10 Upon receiving the processing rule (flow entry) and the verification information setting instruction (Flow Mod (Add)) from the control device (controller) 20, the node 10 stores the processing rule in its flow table 13 according to the Flow Mod (Add). (Flow entry) and verification information associated with the processing rule are set (step S112).
  • the node 10 checks whether or not the received packet is stored in the packet buffer 14 (step S113), and if stored (Yes in step S113), reads the received packet (step S114).
  • the processing content action; giving verification information and outputting the received packet from the designated port) defined in the set processing rule (flow entry) is executed (step S107). As a result, the received packet is transferred to the next-hop node.
  • the packet output instruction (Packet-Out) from the control device (controller) 20 is received. Received (step S116).
  • the node 10 checks whether or not the packet is stored in the packet buffer 14 (step S117). If the packet is read (Yes in step S117), the packet is read (step S118), and the processing content (action; here, the verification information of the received packet and the output from the designated port are received together with the packet output instruction (Packet-Out). Alternatively, a flow table search) is executed (step S107). If the packet is not stored (No in step S117), the node 10 receives the processing content (action; received) together with the packet output instruction (Packet-Out) for the packet received together with the packet output instruction (Packet-Out). Here, the packet verification information is attached and output from the designated port, or the flow table is searched (step S107). As a result, the received packet is transferred to the next-hop node.
  • FIGS. 13 and 14 show that node # 1 that has received a packet addressed to host (B) from host (A) makes an inquiry (processing rule and verification information creation request) to control device (controller) 20.
  • FIG. 5 is a reference diagram and a sequence diagram for explaining a series of flow until a packet is delivered to a host (B).
  • the node # 1 As shown in FIGS. 13 and 14, when the host (A) transmits a user packet addressed to the host (B) to the node # 1 (ST1 in FIG. 13 and FIG. 14; User Packet), the node # 1 As a result of the search of the flow table 13, it is determined that the packet is an unknown packet having no processing rule (flow entry) that matches the received packet (No in step S103 in FIG. 12), and an inquiry is made to the control device (controller) 20. (Processing rule (flow entry) and verification information creation request) are performed (ST2 in FIG. 13 and FIG. 14; Packet-In).
  • control device 20 Upon receiving the inquiry (processing rule (flow entry) and verification information creation request), the control device (controller) 20 should set the nodes # 1 to # 3 on the transfer path of the packet according to the flowchart of FIG. Processing rules (flow entry) and verification information (CA) are created and transmitted to nodes # 1 to # 3 (ST3-1 to ST5-1 in FIGS. 13 and 14; Flow Mod (Add) w / CA).
  • the nodes # 1 to # 3 add the processing rule (flow entry) and the verification information (CA) transmitted from the control device (controller) 20 to the flow table 13 of the own device, and the buffer ID is added Then, the action for the packet is executed (ST3-2 to ST5-2 in FIGS. 13 and 14).
  • the processing rule (flow entry) and verification information (CA) transmitted in ST4-1 in FIGS. 13 and 14 do not reach the node # 2 for some reason, and the flow of the node # 2 It is assumed that no processing rule (flow entry) and verification information (CA) are added to the table 13.
  • CA verification information
  • the node # 2 When a user packet to which an additional header including verification information (CA) is added is received, the node # 2 has no processing rule (flow entry) that matches the received packet as a result of the search of the flow table 13, or It is determined that there is a processing rule (flow entry) that matches the received packet but the verification information does not match (No in step S103 in FIG. 12 or No in step 106), and an inquiry is made to the control device (controller) 20 (processing rule). (Flow entry) and verification information creation request) (ST8 in FIGS. 13 and 14; Packet-In).
  • CA verification information
  • control device (controller) 20 Upon receiving the inquiry (processing rule (flow entry) and verification information creation request), the control device (controller) 20 follows the flowchart of FIG. 11 to set the processing rule (node) to be set in the node # 2 on the transfer path of the packet.
  • Flow entry) and verification information (CA) are acquired (step S012 in FIG. 11) and transmitted to the node # 2 (ST9 in FIG. 13 and FIG. 14; Flow Mod (Add) w / CA).
  • the node # 2 adds the processing rule (flow entry) and verification information transmitted from the control device (controller) 20 to the flow table 13 of the own device, and executes an action when a buffer ID is added. (ST10 in FIGS. 13 and 14).
  • a process of outputting the user packet to which the added header is included from the designated port (port connected to the node # 3) is executed (ST11 in FIGS. 13 and 14).
  • the node # 3 is a processing rule (flow entry) that matches the received packet as a result of the search of the flow table 13, and the verification information Are also matched (Yes in step S103 in FIG. 12 and Yes in step 106), and the action defined in the processing rule (flow entry) extracted and confirmed is executed (ST12 in FIGS. 13 and 14).
  • the matching key of the processing rule (flow entry) matches the header information of the received packet, but also the verification information generated separately by the control device (controller) 20 Since the action is executed on condition that they match, the situation where the action of the unintended processing rule (flow entry) described at the beginning can be avoided.
  • step S104 when the verification information is not included in the received packet, the action is executed without performing verification information verification. However, if the verification information is not included in the received packet, the execution of the action may be suppressed without exception.
  • the verification information is added to the packet by the additional header including the verification information.
  • the verification information can be included in the packet without using the additional header.
  • a second embodiment in which verification information is included in a packet without using an additional header will be described. Note that the basic configuration of the node 10 and the control device (controller) 20 of the second embodiment is the same as that of the first embodiment, and therefore the following description will focus on the differences.
  • FIG. 15 is a diagram schematically showing information (flow entry) held in the flow entry DB 21 of the control device (controller) 20 of the present embodiment.
  • the flow entry DB 21 does not have an independent verification information field, and the matching key field of the flow entry stores a matching key including verification information (CA).
  • CA verification information
  • a process for writing (returning) verification information to the MAC DA field is defined.
  • the value of the original MAC DA field is “Dn”
  • the value after being converted to include the verification information (CA) is “Dn ′”.
  • a node whose DPID is 1 in FIG. 15 receives a packet that matches the matching key “A”
  • the MAC of the packet is determined according to its action field (Actions).
  • a value D1 ′ including verification information (CA) is set in the DA field
  • a process of outputting from the 9th port is executed.
  • a node whose DPID is 2 is a packet in which verification information (CA) is set in the MAC DA field from a node whose DPID is 1 (for example, node # 1 in FIG.
  • FIG. 16 is a diagram schematically showing information (verification information) held in the verification information DB 27 of the control device (controller) 20 of the present embodiment.
  • the difference from the first embodiment is the contents of the Original MAC DA field for writing back the MAC DA field to the same contents as the MAC DA of the original received packet (corresponding to D1, D2, and DX in FIG. 15).
  • the node number of the last hop for executing this write-back process is added.
  • FIG. 17 is a diagram showing a detailed configuration of the node 10a of the present embodiment.
  • the difference from FIG. 7 showing the configuration of the node 10 of the first embodiment is that the verification operation of the verification information verification unit 152a is different due to the difference in the verification information (detailed later).
  • 152a, table search unit 153a, and transfer processing unit 15a are each replaced.
  • FIG. 18 is a diagram schematically showing information (flow entry) held in the flow table 13 of the node having the DPID of 2 in FIG. 15 (node # 2 in FIG. 3).
  • the flow entry of the corresponding DPID is set from the flow entry DB 21 of FIG.
  • the flow entries corresponding to the respective DPIDs are set in the nodes having the DPIDs 1 and 3 in FIG. 15 (nodes # 1 and # 3 in FIG. 3).
  • the packet 32a with verification information has a configuration in which 48-bit information shown in the lower part of FIG. 19 is written in the MAC DA field of the user packet 31.
  • 8-bit fixed data indicating that verification information is included, function f 1 (DPID of the last hop node, original MAC DA), and function f 2 (matching key, random number) are written.
  • this is merely an example, and the fields used for storing the verification information, the contents of the verification information, the function for degenerating the original data, and the like can be changed as appropriate.
  • FIG. 20 is a flowchart showing the operation of the control device (controller) of the second embodiment of the present invention.
  • the difference from FIG. 11 showing the operation of the control device (controller) of the first embodiment is that it is added in step S002a when confirming whether or not verification information is included in the inquired packet. It is a point to check whether or not the above-mentioned fixed data (see FIG. 19) is written in the MAC DA, not the header. Others are the same as those in the first embodiment, and a description thereof will be omitted.
  • FIG. 21 is a flowchart showing the operation of the node 10a according to the second embodiment of this invention.
  • the difference from FIG. 12 showing the operation of the node 10 of the first embodiment is that, in step S104a, when checking whether or not verification information is included in the received packet, not the additional header but the MAC DA. Check whether or not the above-mentioned fixed data (see FIG. 19) is written to the node, and the final hop node does not delete the additional header, but restores the original MAC DA field according to the action before transferring the packet. It is a point to do. Others are the same as those in the first embodiment, and a description thereof will be omitted.
  • the present invention can also be realized by including verification information in a specific field of an existing packet.
  • each node is described as storing the same verification information in association with the flow entry of the flow table, but there is also a configuration in which each node performs verification with different verification information. It can be adopted.
  • a third embodiment in which each node performs verification using different verification information will be described. Note that the basic configuration of the node 10 and the control device (controller) 20 of the third embodiment is the same as that of the first embodiment, and therefore the following description will focus on the differences.
  • FIG. 22 is a diagram schematically showing information (flow entry and verification information) held in the flow entry DB 21 of the control device (controller) 20 of the present embodiment.
  • the difference from the first embodiment is that the verification information generation process (step S006 in FIG. 11) of each node is executed for the number of nodes, and the flow entry DB 21 does not have an independent verification information field.
  • a process for adding an additional header including different verification information to the action field is added. (Because each node adds a header including different verification information, the verification information associated with the flow entry includes the corresponding flow.
  • the verification information field is unnecessary because it is described in the entry, and it is not necessary to maintain the correspondence between the verification information and the flow entry independently).
  • a node having the DPID of 1 in FIG. 22 receives a packet that matches the matching key “A1”
  • the verification information (Actions)
  • a process of outputting from the 9th port is executed.
  • a node with DPID 2 (for example, node # 2 in FIG. 3) has an additional header storing verification information (C2A) from a node with DPID 1 (for example, node # 1 in FIG. 3).
  • the verification information (C2A) of the additional header is rewritten with the verification information (C3A), and then the process of outputting from the sixth port is executed.
  • a node with DPID 3 (for example, node # 3 in FIG. 3) is added with an additional header storing verification information (C3A) from a node with DPID 2 (for example, node # 2 in FIG. 3).
  • the received packet packet conforming to the matching key A3
  • an additional header is removed from the packet, and a process of outputting from the first port is executed.
  • the control is realized in which the transfer is performed on the designated route while rewriting the verification information and collating with the verification information in order from the node at the first hop of the transfer route.
  • FIG. 23 is a diagram schematically showing information (verification information) held in the verification information DB 27 of the control device (controller) 20 of the present embodiment.
  • the difference from the first embodiment is that a DPID field is added and the correspondence between the matching key and the verification information is stored for each node.
  • the information held in the verification information DB 27 can be changed as appropriate depending on the function for generating the verification information.
  • FIG. 24 is a diagram schematically showing information (flow entry and verification information) held in the flow table 13 of the node having the DPID of 2 in FIG. 22 (node # 2 in FIG. 3).
  • the flow entry and verification information of the corresponding DPID are set in the flow table 13 from the flow entry DB 21 of FIG.
  • the flow entries and verification information corresponding to the respective DPIDs are also set in the nodes having the DPIDs 1 and 3 in FIG. 22 (nodes # 1 and # 3 in FIG. 3).
  • the present embodiment is different from the first embodiment only in that the control device generates verification information for each node and the action performed in each node, and the basic operation is the first embodiment. Since it is the same, description is abbreviate
  • omitted (refer FIG. 11, FIG. 12).
  • each node rewrites verification information by an action in a processing rule
  • a flow having a different matching key for a certain communication flow compared to the first embodiment An entry can be set to a node on the route.
  • the fourth embodiment of the present invention is a combination of the second embodiment and the third embodiment of the present invention, and each node has different verification information without using an additional header. Are used for collation. Note that the basic configurations of the node 10 and the control device (controller) 20 of the fourth embodiment are the same as those of the first to third embodiments, and therefore, the following description will focus on the differences.
  • FIG. 25 is a diagram schematically showing information (flow entry) held in the flow entry DB 21 of the control device (controller) 20 of the present embodiment.
  • the difference from the third embodiment is not a process of adding an additional header including different verification information to the action field, but rewriting the value of the MAC DA field to a value including the verification information of each node. The point is that processing to restore with hops has been added.
  • the MAC of the packet is determined according to its action field (Actions). After the value D1 ′ including the verification information (C2A) is set in the DA field, the process of outputting from the 9th port is executed. Similarly, the verification information (C2A) is set in the MAC DA field from the node having the DPID of 2 (for example, the node # 2 in FIG. 3) from the node having the DPID of 1 (for example, the node # 1 in FIG. 3).
  • a node with DPID 3 (for example, node # 3 in FIG. 3) is a packet in which verification information (C3A) is set in the MAC DA field from a node with DPID 2 (for example, node # 2 in FIG. 3).
  • Packet matching matching key A (Packet matching matching key A ”), the MAC DA field is the same as the MAC DA of the original received packet.
  • D1 After written back to (D1), it executes a process of outputting from the first port.
  • the control is realized in which the verification information is sequentially rewritten at the first hop node of the transfer route, and is verified with the verification information, and transferred on the designated route.
  • FIG. 26 is a diagram schematically showing information (verification information) held in the verification information DB 27 of the control device (controller) 20 of the present embodiment.
  • the difference from the third embodiment is that the contents of the Original MAC DA field for rewriting the MAC DA field to the same contents as the MAC DA of the original received packet (corresponding to D1, D2, and DX in FIG. 25). The node number of the last hop for executing this write-back process is added.
  • the information held in the verification information DB 27 can be changed as appropriate depending on the function for generating the verification information.
  • FIG. 27 is a diagram schematically showing information (flow entry) held in the flow table 13 of the node having the DPID of 2 in FIG. 25 (node # 2 in FIG. 3).
  • the flow entry of the corresponding DPID is set from the flow entry DB 21 of FIG.
  • the flow entries corresponding to the respective DPIDs are set in the nodes having the DPIDs 1 and 3 in FIG. 25 (nodes # 1 and # 3 in FIG. 3).
  • the present embodiment is different from the first embodiment only in that the control device generates verification information for each node and the action performed in each node, and the basic operation is the first embodiment. Since it is the same, description is abbreviate
  • omitted (refer FIG. 11, FIG. 12).
  • each node rewrites verification information by an action in the processing rule
  • a flow having a different matching key for a certain communication flow as compared to the second embodiment An entry can be set to a node on the route.
  • FIG. 28 is an example of a packet used in the fifth embodiment of the present invention.
  • the packet 32b with verification information has a configuration in which an additional header 33b with verification information including verification information is added to the head of the user packet 31.
  • FIG. 29 is a diagram illustrating a configuration example of the additional header 33b with verification information.
  • the additional header 33b with verification information includes a MAC destination address (MAC DA), a MAC transmission source address (MAC SA), an upper protocol type (Ether Type), a total header length (Total Length), DPID and A plurality of pairs with verification information are added.
  • MAC DA MAC destination address
  • MAC SA MAC transmission source address
  • Ether Type an upper protocol type
  • Total Length Total Length
  • DPID total header length
  • a value (f (matching key, rand)) calculated by a predetermined function (hash function or the like) that uses a matching key of each node and a random number as arguments is used as verification information.
  • This embodiment is different from the first embodiment only in that the control device generates verification information for each node and that each node extracts its own verification information using DPID and performs a verification operation. Since the basic operation is the same as that of the first embodiment, the description thereof is omitted (see FIGS. 11 and 12).
  • the present invention can also be realized by a configuration in which an additional header storing verification information of each node is added. Compared with the third embodiment, the process of rewriting verification information at each node is performed. There is an advantage that it can be omitted.
  • control devices (controllers) 20 and 20a of the above-described embodiment can also be realized as dedicated servers.
  • the nodes 10, 10a and 10b in addition to the OpenFlow switch, a router in the IP network, MPLS (Multi- It can be realized with an MPLS switch in a Protocol Label Switching network.
  • the present invention can be applied to any network where the server centrally manages nodes in the network.
  • the node identifier is included in the additional header so that each node specifies the verification information to be verified by the own device.
  • DPID node identifier
  • the last hop node has been described as removing the additional header and writing back the MAC DA field.
  • a configuration in which these processes are performed on the host side can also be employed.
  • the control device 20 is described as including the verification information generation unit 28.
  • the verification information generation function is synchronized between the nodes 10 or between the node 10 and the control device 20. If each node 10 can create verification information by allocating or arguments, a configuration in which a verification information generation unit is generated for each node can also be adopted.
  • the node collates the received packet with the collation rule, searches for a processing rule corresponding to the collation rule that matches the received packet, and the identifier of the received packet corresponds to the identifier associated with the retrieved processing rule.
  • the communication system executes processing of the received packet according to the retrieved processing rule.
  • the node searches for a processing rule associated with an identifier corresponding to the identifier of the received packet. If the matching rule corresponding to the processing rule matches the received packet by matching, the node processes the received packet according to the searched processing rule.
  • the communication system is a communication system in which the identifier is unique among a plurality of processing rules corresponding to each of a plurality of matching rules that match at least a received packet.
  • a communication system in which the node determines whether or not an identifier of the received packet is included in the received packet based on whether or not the identifier is stored in a predetermined field of the received packet.
  • the control device includes: The node located at the starting point of the packet transfer path replaces the information in a predetermined field of the received packet with information including an identifier, and then transfers the packet.
  • a communication system in which a node located at an end point of the transfer path controls each of the nodes so as to transfer the packet after rewriting the information in a predetermined field of the received packet to the content before replacement.
  • the control device includes: A different identifier is set for each processing rule set in the node on the packet transfer path, so that the node on the transfer path sequentially performs the operation of rewriting the identifier of the received packet with the identifier of the next hop node.
  • the control device includes: The node located at the start point of the packet transfer path adds an additional header including an identifier to the received packet, forwards the packet, and the node located at the end point of the transfer path removes the additional header. Then, a communication system that controls each of the nodes to transfer the packet.
  • the thirteenth to eighteenth forms can be developed into the second to twelfth forms, similar to the first form.
  • Controller communication unit 10
  • Flow table management unit 13
  • Flow table 14 Packet buffer 15, 15a Transfer processing unit 20
  • Control device 21
  • Flow entry database (flow entry DB) 22
  • topology management unit 23
  • route / action calculation unit 24
  • flow entry management unit 25
  • control message processing unit 26
  • node communication unit 27
  • verification information database (verification information DB) 28
  • Verification information generation unit 31
  • Action execution unit 251
  • Message analysis / processing unit 252
  • Message Generator 25

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

　本発明は、データ転送ネットワークに配置されたノードにおいて、処理規則（フローエントリ）の設定遅れ等により、意図しない処理が実行されることを抑止する構成を提供する。通信システムは、受信パケットを処理するノードと、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、前記ノードに設定する制御装置とを含む。前記ノードは、識別子を処理規則に関連付けて保持し、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより判定する。

Description

通信システム、ノード、制御装置、通信方法およびプログラム
　（関連出願についての記載）
　本発明は、日本国特許出願：特願２０１０－１２３０５４号（２０１０年５月２８日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
　本発明は、通信システム、ノード、制御装置、通信方法およびプログラムに関し、特に、ネットワークに配置されたノードによりパケットを転送して通信を実現する通信システム、ノード、制御装置、通信方法およびプログラムに関する。
　非特許文献１、２に示すとおり、近年、オープンフロー（ＯｐｅｎＦｌｏｗ）という技術が提案されている。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合する照合規則（ＦｌｏｗＫｅｙ／マッチングキー）と、処理内容を定義したアクション（Ａｃｔｉｏｎ）と、フロー統計情報（Ｓｔａｔｓ）との組が定義される（図３０参照）。
　図３１に、非特許文献２に定義されているアクション名とアクションの内容を例示する。ＯＵＴＰＵＴは、パケットを指定ポート（インタフェース）に出力するアクションである。ＳＥＴ＿ＶＬＡＮ＿ＶＩＤからＳＥＴ＿ＴＰ＿ＤＳＴは、パケットヘッダのフィールドを修正するアクションである。
　例えば、オープンフロースイッチは、最初のパケット（ｆｉｒｓｔ　ｐａｃｋｅｔ）を受信すると、フローテーブルから、受信パケットのヘッダ情報に適合する照合規則（ＦｌｏｗＫｅｙ）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、前記検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。
Nick McKeownほか７名、"OpenFlow: Enabling Innovation in Campus Networks"、［online］、［2010年2月26日検索］、インターネット〈URL：http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉 "OpenFlow Switch Specification" Version 1.0.0. (Wire Protocol 0x01) ［2010年4月1日検索］、インターネット〈URL：http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf〉
　なお、上記の非特許文献の各開示を、本書に引用をもって繰り込むものとする。
　以下の分析は、本発明者によってなされたものである。上記受信パケットの経路の決定依頼を受けたオープンフローコントローラは（図３３のｓ２　Ｐａｃｋｅｔ－Ｉｎ参照）、受信パケットの転送経路を決定する。前記受信パケットおよび同一フローに属する後続パケットをホスト（Ｂ）に転送するには、前記転送経路上にあるすべてのオープンフロースイッチ（図３３のノード＃１およびノード＃２）に、フローエントリを設定する必要がある。また、オープンフローコントローラはネットワーク管理者の指示等に基づいて設定済みのフローエントリについて、アクションの変更を行う場合があり、その際、フローエントリの変更・削除を行う必要がある。
　上記フローエントリの設定・変更・削除がオープンフロープロトコルで行われる場合（非特許文献２の「４．６　Ｆｌｏｗ　Ｔａｂｌｅ　Ｍｏｄｉｆｉｃａｔｉｏｎ　Ｍｅｓｓａｇｅｓ」参照）、オープンフローコントローラとオープンフロースイッチ間の通信に遅延が生じることがあり、一部のオープンフロースイッチにおけるフローエントリの設定・変更・削除が間に合わず、経路上のオープンフロースイッチにおいて、パケットがフローテーブル上の意図しないフローエントリに一致し、意図しないアクションが実行されるという問題点がある。
　図３２は、ホスト（Ａ）からホスト（Ｂ）宛てのパケットを受信したオープンフロースイッチ（ノード＃１）が、コントローラに対しフローエントリの作成要求を行った際、中継スイッチ(ノード＃２)に対するマッチングキーＸを持つフローエントリの設定が遅延した例である。図３２の例では、ノード＃２において、設定されるべきフローエントリのマッチングキーＸと競合（オープンフロープロトコルではマッチングキーとして任意のヘッダフィールドの部分一致を許可しており、フローエントリ間での競合回避はフローエントリの検索順によって制御される）するマッチングキーＢを持つフローエントリが存在している。そのため、ノード＃２において、ホスト（Ａ）から送信されたパケットは、フローエントリの設定が完了するまでの間、本来出力されるべきポート＃２ではなくポート＃１へ転送されてしまう（図３２のＳＴ８）。このように、オープンフロープロトコルではフローエントリの設定遅延により意図しないパケット転送（アクション実行）が容易に発生し得る。
　上記の対策として、図３３に示すように、（オープンフロー）コントローラが、ノード＃１、＃２に対してフローエントリを送信（図３３のｓ３、ｓ６のＦｌｏｗＭｏｄ（Ａｄｄ）参照）するとともに、オープンフロープロトコルに規定されているＢａｒｒｉｅｒ　Ｒｅｑｕｅｓｔを送信することが考えられる（図３３のｓ４　Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ；Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙについては非特許文献２の「５．３．７　Ｂａｒｒｉｅｒ　Ｍｅｓｓａｇｅ」参照）。Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔを受信したノードは、Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ受信前に受信した処理の実行を完了し、「Ｂａｒｒｉｅｒ　Ｒｅｐｌｙ」（図３３のｓ５）として、応答する。これにより、（オープンフロー）コントローラは、フローエントリが正しく設定されていることを確認できる。しかしながら、この方法では、フローエントリを設定したすべてのノードと、Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙをやり取りすることになり、ユーザパケットを送信できるまでの時間（図３３のｓ１（Ｕｓｅｒ　Ｐａｃｋｅｔ）～ｓ１０（Ｕｓｅｒ　Ｐａｃｋｅｔ）が長くなってしまうという問題点がある。
　もう一つの方法として、上記Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙに代えて、Ｓｔａｔｓ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙを用いて、各ノードが該当するエントリを持っているかどうかを確かめる方法もあるが、この場合も、上記Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙを用いる場合と同様に、フローエントリを設定したすべてのノードと該当するフローエントリが設定されているか否かをやり取りする必要が生じ、ユーザパケットを送信できるまでの時間（図３３のｓ１（Ｕｓｅｒ　Ｐａｃｋｅｔ）～ｓ１０（Ｕｓｅｒ　Ｐａｃｋｅｔ）が長くなってしまう。
　また、上記Ｂａｒｒｉｅｒ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙ、Ｓｔａｔｓ　Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙを用いるいずれの方法も、フローエントリ設定後、ノードの障害等によってフローエントリの一部が消失してしまったような場合に、意図しないアクションが実行されてしまう事態を回避することができない。
　本発明は、上記した事情に鑑みてなされたものであってその目的とするところは、上記のとおり、ノードにおいて、適切でない処理規則（フローエントリ）がヒットし、意図しない処理が実行されることを抑止することのできる通信システム、ノード、制御装置、通信方法およびプログラムを提供することにある。
　本発明の第１の視点によれば、受信パケットを処理するノードと、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、前記ノードに設定する制御装置とを含み、前記ノードは、識別子を処理規則に関連付けて保持し、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより判定する通信システムが提供される。
　本発明の第２の視点によれば、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、識別子と関連付けて保持し、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定することにより、受信パケットを処理するノードが提供される。
　本発明の第３の視点によれば、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を生成し、前記処理規則に関連付ける識別子であって、前記ノードに、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定させるための識別子を生成し、通信システムに配置されて受信パケットを処理するノードに、前記処理規則と前記識別子とを設定する制御装置が提供される。
　本発明の第４の視点によれば、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、識別子と関連付けて保持し、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定することにより、受信パケットを処理する通信方法が提供される。本方法は、受信パケットを処理するノードという、特定の機械に結びつけられている。
　本発明の第５の視点によれば、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を生成し、前記処理規則に関連付ける識別子であって、前記ノードに、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定させるための識別子を生成し、通信システムに配置されて受信パケットを処理するノードに、前記処理規則と前記識別子とを設定する通信方法が提供される。本方法は、受信パケットを処理するノードに前記処理規則を設定する制御装置という、特定の機械に結びつけられている。
　本発明の第６の視点によれば、通信システムにおいて受信パケットを処理するノードに、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、識別子と関連付けて記憶する処理と、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより判定する処理と、を実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
　本発明の第７の視点によれば、通信システムにおいて、受信パケットを処理するノードを制御する制御装置に、照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を生成する処理と、前記処理規則に関連付ける識別子であって、前記ノードに、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定させるための識別子を生成する処理と、前記処理規則と前記識別子とを前記ノードに設定する処理と、を実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
　本発明によれば、データ転送ネットワークに配置されたノードにおいて、意図しない処理が実行されることを抑止することが可能になる。
本発明の概要を説明するための図である。 本発明の概要を説明するための別の図である。 本発明の第１の実施形態の通信システムの構成を示す図である。 本発明の第１の実施形態の制御装置（コントローラ）の構成を表したブロック図である。 図４の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 図４の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第１の実施形態のノードの構成を表したブロック図である。 図７のノードのフローテーブルに保持される情報を説明するための図である。 検証情報を含んだ（付加した）パケットの一例である。 図９の検証情報付き追加ヘッダの構成例を示す図である。 本発明の第１の実施形態の制御装置（コントローラ）の動作を表したフローチャートである。 本発明の第１の実施形態のノードの動作を表したフローチャートである。 本発明の第１の実施形態の通信システムにおける一連の流れを説明するための参考図である。 本発明の第１の実施形態の通信システムにおける一連の流れを説明するためのシーケンス図である。 本発明の第２の実施形態の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 本発明の第２の実施形態の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第２の実施形態のノードの構成を表したブロック図である。 図１７のノードのフローテーブルに保持される情報を説明するための図である。 検証情報を含んだ（埋め込んだ）パケットの一例である。 本発明の第２の実施形態の制御装置（コントローラ）の動作を表したフローチャートである。 本発明の第２の実施形態のノードの動作を表したフローチャートである。 本発明の第３の実施形態の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 本発明の第３の実施形態の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第３の実施形態のノードのフローテーブルに保持される情報を説明するための図である。 本発明の第４の実施形態の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 本発明の第４の実施形態の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第４の実施形態のノードのフローテーブルに保持される情報を説明するための図である。 本発明の第５の実施形態で用いるパケットの一例である。 図２８の検証情報付き追加ヘッダの構成例を示す図である。 非特許文献２に記載のフローエントリの構成を表した図である。 非特許文献２に記載されているアクション名とアクションの内容を示す図である。 非特許文献２のオープンフローコントローラ（コントローラ）とフロースイッチ（ノード）の動作を説明するための図である。 非特許文献２のオープンフロープロトコルを用いて、フローエントリを確実に設定するための一連の流れを説明するための参考図とシーケンス図である。
　はじめに、本発明の概要について説明する。以下、この概要に付記した図面参照符号は、専ら理解を助けるための例示であり、図示の態様に限定することを意図するものではない。図１に示すように、本発明の通信システムのノード１０（図１のノード＃２参照）は、パケットを受信した際に、自装置が保持している処理規則の中の照合規則（マッチングキー）を用いて受信パケットに適合する処理規則を抽出する（ステップ１）。次に、ノード１０（図１のノード＃２参照）は、前記抽出した処理規則に関連付けられている識別子が、前記受信したパケットに含まれる識別子と一致することを確認する（ステップ２）。なお、ノード１０が、処理規則に関連付けられている識別子と、受信したパケットに含まれる識別子とが一致することを確認する場合について述べたが、本発明はこれに限らない。例えば、ノード１０が、処理規則に関連付けられている識別子と、受信したパケットに含まれている識別子とが互いに対応関係にあることを確認するような場合等も含まれる。以降のステップや実施形態においても同様である。前記確認の結果、処理規則に関連付けられている識別子が、前記受信したパケットの識別子と一致することが確認できたら、ノード１０（図１のノード＃２参照）は、当該処理規則に従って処理を実行する（ステップ３）。
　ここで、上記した識別子は、制御装置（コントローラ）２０によって、処理規則に関連付けて生成された情報であり、少なくとも受信パケットに適合し得る処理規則同士を識別できるように生成・付与される。従って、照合規則（マッチングキー）による検索で抽出された処理規則であっても、識別子が一致しない場合、当該処理規則のアクションは実行されないことになる。ユーザパケットに識別子を含める態様としては、図１、図２に示すようにユーザパケットに付加する形態のほか、ユーザパケットの特定の領域に埋め込む形態など（図１９参照）、種々の形態を採用することができる。
　以上により、冒頭に述べた、処理規則の設定遅れや、ノードの障害等によってフローエントリの一部が消失してしまったような場合に、意図しないアクションが実行されてしまう事態を回避することができる。
　図１の例では、照合規則（マッチングキー）を用いて受信パケットに適合する処理規則を抽出した後、前記抽出した処理規則に関連付けられた識別子が、前記受信したパケットの識別子と一致することを確認するものとして説明したが、図２に示すように、識別子を用いて受信パケットに適合する処理規則を抽出した後、前記抽出した処理規則の照合規則（マッチングキー）が、前記受信したパケットの内容（照合規則（マッチングキー）の照合対象となるヘッダ情報）と一致することを確認する方法も採用できる。
　この場合も、識別子による検索で抽出された処理規則であっても、照合規則（マッチングキー）が受信パケットの内容（ヘッダ情報）と一致しない場合、当該処理規則のアクションは実行されないことになる。図１の場合と同様に、処理規則の設定遅れ等により、意図しないアクションを実行してしまうといった事態を回避することができる。
［第１の実施形態］
　続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図３は、本発明の第１の実施形態に係る通信システムの構成を示す図である。図３を参照すると、３つのノード１０と、制御装置（コントローラ）２０と、ノード１０を経由して通信するホスト（Ａ）、（Ｂ）が示されている。なお、図３の例では、３つのノード１０と、制御装置（コントローラ）２０と、２つのホスト（Ｈｏｓｔ（Ａ）、Ｈｏｓｔ（Ｂ））を示しているが、それぞれの数は、あくまで例示であり、それぞれ任意の数とすることができる。
　図４は、制御装置（コントローラ）２０の詳細構成を表した図である。図４を参照すると、制御装置（コントローラ）２０は、処理規則（フローエントリ）と当該処理規則と関連付けられた検証情報を格納したフローエントリデータベース（フローエントリＤＢ）２１と、ノード通信部２６を介して収集されたノード１０の接続関係に基づいてネットワークトポロジ情報を構築するトポロジ管理部２２と、トポロジ管理部２２にて構築されたネットワークトポロジ情報に基づいてパケットの転送経路および該転送経路上のノード１０に実行させるアクションを求める経路・アクション計算部２３と、経路・アクション計算部２３および検証情報生成部２８にて計算された処理規則（フローエントリ）および検証情報を関連付けてフローエントリＤＢ２１に登録し、ノード１０からの処理規則（フローエントリ）の追加要求への対応や処理規則（フローエントリ）および検証情報の更新などを行うフローエントリ管理部２４と、制御メッセージ処理部２５と、ノード１０との通信を行うノード通信部２６と、フローエントリ管理部２４からの要求に応じて処理規則に含める検証情報を生成または検証情報データベース（検証情報ＤＢ）２７から取り出す検証情報生成部２８と、を備えて構成される。ここで、検証情報は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられる上記識別子相当の情報を指すものとする。
　さらに、制御メッセージ処理部２５は、ノード１０から受信した制御メッセージを解析して、必要な処理を行うメッセージ解析・処理部２５１と、ノード１０に送信するメッセージを生成するメッセージ生成部２５２とを備えて構成される。
　図５は、フローエントリＤＢ２１に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。例えば、図５の上から１～３番目のエントリは、ＤＰＩＤ（ノード１０の識別子；Ｄａｔａｐａｔｈ　Ｉｄｅｎｔｉｆｉｅｒ）が１～３のノードにそれぞれ設定される処理規則（フローエントリ）および処理規則に関連付けられた検証情報を示している（上から４～６番目のエントリも同様。）。
　ＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、上記上から１番目のエントリのとおり、「Ａ」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、検証情報「ＣＡ」を含むヘッダを付加してから、９番ポートから出力する処理を実行する。同様に、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）から「Ａ」というマッチングキーに適合するパケットを受信すると、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）から「Ａ」というマッチングキーに適合するパケットを受信すると、当該パケットから検証情報「ＣＡ」を含むヘッダを除去してから、１番ポートから出力する処理を実行する。以上により、「Ａ」というマッチングキーに適合するパケットに、検証情報「ＣＡ」を付加し、検証情報「ＣＡ」と照合させつつ指定した経路にて転送させる制御が実現される。なお、図５のマッチングキー「Ａ」、「Ｂ」、「Ｘ」は、実際には、図３０に示したような受信パケットのヘッダと照合するルール（ＦｌｏｗＫｅｙ；但し、ワイルドカードを利用可能）によって構成される。
　図６は、検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。図６に示すように、検証情報ＤＢ２７には、上記したマッチングキー「Ａ」、「Ｂ」、・・・、「Ｘ」と、検証情報「ＣＡ」、「ＣＢ」、・・・、「ＣＸ」の対応関係が保持される。検証情報生成部２８は、フローエントリ管理部２４から要求された処理規則（フローエントリ）対応する検証情報を生成して、それを検証情報ＤＢ２７に登録する処理を行う。このような検証情報は、例えば、照合規則（以下、「マッチングキー」とする。）やその他情報を引数とする所定の関数（ハッシュ関数等）を用いて、少なくとも、受信パケットと適合する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意、つまり、これら処理規則に少なくとも同一の検証情報が付与されないよう生成することができる。また、乱数により統計的に一意な検証情報を生成することもできる（具体例は、後に詳述する。）。検証情報ＤＢ２７は競合する可能性のある複数の処理規則（フローエントリ）間での検証情報重複を防ぐ目的のものであり、必ずしも図６の形式である必要はない。また、検証情報の重複を確率・統計的に回避することにより、検証情報ＤＢ２７を省略することも可能である。
　なお、ノード１０に対して追加または更新を指示した処理規則（フローエントリ）および当該処理規則に関連付けられた検証情報を保持する必要が無い場合、フローエントリＤＢ２１は省略することが可能である。同様に、処理規則に関連付けて生成した検証情報を保持する必要が無い場合、検証情報ＤＢ２７を省略することも可能である。また、フローエントリＤＢ２１や検証情報ＤＢ２７を別途外部サーバ等に設ける構成も採用可能である。
　上記のような制御装置（コントローラ）２０は、非特許文献１、２のオープンフローコントローラに、少なくとも上記検証情報生成部２８と、ノード１０に処理規則（フローエントリ）と当該処理規則に関連付けらけた検証情報を設定する機能を追加することにより実現することが可能である。
　図７は、ノード１０の詳細構成を表した図である。図７を参照すると、ノード１０は、制御装置（コントローラ）２０と通信する制御装置通信部１１と、フローテーブル１３を管理するフローテーブル管理部１２と、パケットバッファ１４と、転送処理部１５とを備えて構成される。なお、ノード１０は、必ずしもパケットバッファ１４を備えていなくともよい。
　転送処理部１５は、テーブル検索部１５３と、アクション実行部１５４とを含んで構成される。テーブル検索部１５３は、ある処理規則（フローエントリ）に関連付けられた検証情報と、受信パケットに付加された検証情報とを照合し、一致するか否かを判定する検証情報照合部１５２を含んで構成され、フローテーブル１３から、受信パケットに適合するマッチングキーを持つ処理規則（フローエントリ）であって、検証情報が一致する処理規則の処理内容（アクション）をアクション実行部１５４に出力する。アクション実行部１５４は、前記テーブル検索部１５３から出力された処理内容（アクション）を実行する。
　上記のようなノード１０は、オープンフロースイッチに、上記検証情報照合部１５２を追加するとともに、そのフローテーブル１３を、処理規則（フローエントリ）に関連付けて検証情報を保持可能な構成とすることで実現することも可能である。また、上記のようなノード１０の検証情報照合部１５２を含むテーブル検索部１５３は、ノード１０を構成するコンピュータに実行させるプログラムによって実現することもできる。
　図８は、図５のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。図８に示すように、フローテーブル１３には、図５のフローエントリＤＢ２１の該当するＤＰＩＤのエントリと同一内容のフローエントリおよび検証情報が設定される。図５のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリおよび検証情報が設定されることになる。
　図９は、制御装置（コントローラ）２０により設定されたアクション（Ｓｅｔ　Ｈｅａｄｅｒ　ｉｎｃｌｕｄｉｎｇ　“ＣＡ”；図５のＤＰＩＤ＝１のノードのアクション（Ａｃｔｉｏｎｓ）参照）に基づき、ノード１０にて作成される検証情報付きパケットの構成を説明するための図である。図９の例では、検証情報付きパケット３２は、検証情報を含んだ検証情報付き追加ヘッダ３３をユーザパケット３１の先頭に付加した構成となっている。
　図１０は、上記検証情報付き追加ヘッダ３３の構成例を示す図である。図１０の例では、検証情報付き追加ヘッダ３３は、ＭＡＣ宛先アドレス（ＭＡＣ　ＤＡ）、ＭＡＣ送信元アドレス（ＭＡＣ　ＳＡ）、上位プロトコルタイプ（Ｅｔｈｅｒ　Ｔｙｐｅ）、トータルヘッダ長（Ｔｏｔａｌ　Ｌｅｎｇｔｈ）に、検証情報を付加した構成となっている。なお、図１０の例では、マッチングキーと乱数を引数とする所定の関数（ハッシュ関数等）により算出した値（ｆ（ｍａｔｃｈｉｎｇ　ｋｅｙ，ｒａｎｄ））を検証情報としている。
　続いて、上記した制御装置（コントローラ）２０およびノード１０の動作について説明する。図１１は、上記制御装置（コントローラ）２０の動作を表したフローチャートである。図１１を参照すると、制御装置（コントローラ）２０は、ノード１０から問い合わせ（処理規則の作成要求；図１２のステップＳ１１１参照）を受けると（ステップＳ００１；Ｐａｃｋｅｔ－Ｉｎ）、前記問い合わせに係るパケットに検証情報が含まれているか否かを確認する（ステップＳ００２）。ここで、問い合わせに係るパケットに検証情報が含まれている場合（ステップＳ００２のＹｅｓ）、当該パケットに対応する処理規則は作成済みであるため、制御装置（コントローラ）２０は、フローエントリＤＢ２１から当該パケットに対応する処理規則および当該処理規則に関連付けられた検証情報を取り出して（ステップＳ０１２）、ステップＳ００８に進む。
　一方、問い合わせに係るパケットに検証情報が含まれていない場合（ステップＳ００２のＮｏ）、制御装置（コントローラ）２０は、トポロジ管理部２２にて構築されたネットワークトポロジ情報を取得し、パケットの転送経路を計算する（ステップＳ００３）。
　前記パケットの転送経路を計算の結果、経路を作成できない、経路上のノードが故障している等の理由により、転送できないと判定した場合（ステップＳ００４のＮｏ）を除き、制御装置（コントローラ）２０は、前記計算された転送経路に対応するアクションを計算する（ステップＳ００５）。続いて、当該経路上の各ノード１０に適用する処理規則（フローエントリ）に関連付ける検証情報を生成する（ステップＳ００６）。さらに、制御装置（コントローラ）２０は、当該問い合わせに係るパケットが属するフローを特定するためのマッチングキーおよび前記アクションを含む当該経路上の各ノード１０に適用する処理規則（フローエントリ）を生成する（ステップＳ００７）。
　処理規則（フローエントリ）および検証情報の取得または生成が完了すると、制御装置（コントローラ）２０は、前記生成した処理規則（フローエントリ）および検証情報の設定指示（Ｆｌｏｗ　Ｍｏｄ（Ａｄｄ））を生成し（ステップＳ００８）、当該処理規則（フローエントリ）によって実現されるパケット転送経路上のノード１０に対して、処理規則（フローエントリ）および検証情報の設定指示（Ｆｌｏｗ　Ｍｏｄ（Ａｄｄ））を送信する（ステップＳ００９）。
　その後、ノード１０がパケットをバッファしていない場合（ステップＳ０１０のＮｏ）、制御装置（コントローラ）２０は、パケットの出力指示（Ｐａｃｋｅｔ－Ｏｕｔ）を行う（ステップＳ０１１）。このパケットの出力指示は、出力すべきパケット（ステップＳ００１のＰａｃｋｅｔ－Ｉｎで受信したパケット）と、当該パケットに対し実行すべきアクション（検証情報の付与と指定ポートから出力）とを指示すること、あるいは、出力すべきパケット（ステップＳ００１のＰａｃｋｅｔ－Ｉｎで受信したパケット）と、当該パケットに対し実行すべきアクション（フローテーブルの検索）を指示することによって行われる。なお、ノード１０がパケットをバッファしている場合（ステップＳ０１０のＹｅｓ）、後に説明するように、ノード１０にパケットの出力処理を行わせることができるため、制御装置（コントローラ）２０側の処理は省略される。
　図１２は、ノード１０の動作を表したフローチャートである。図１２を参照すると、ノード１０は、ホストや他のノード１０からパケットを受信すると（ステップＳ１０１）、フローテーブル１３から、受信パケットに適合するマッチングキーを持つ処理規則（フローエントリ）を検索する（ステップＳ１０２）。
　ステップＳ１０２にて、処理規則（フローエントリ）を抽出できた場合（ステップＳ１０３のＹｅｓ）、ノード１０は、受信パケットに検証情報が含まれているか否かを確認する（ステップＳ１０４）。なお、本実施形態においては、受信パケットに追加ヘッダが付加されているか否かにより、検証情報が含まれているか否かを判別することができる。
　ここで、受信パケットに検証情報が含まれていない場合、ノード１０は、抽出した処理規則（フローエントリ）に記述されたアクションを実行する（ステップＳ１０７）。
　一方、ステップＳ１０４にて、受信パケットに検証情報が含まれていると判定された場合、ノード１０は、受信パケットに含まれている検証情報と、前記抽出した処理規則（フローエントリ）に関連付けられている検証情報とを照合する（ステップＳ１０５）。
　前記検証情報同士が一致した場合、ノード１０は、抽出した処理規則（フローエントリ）に記述されたアクションを実行する（ステップＳ１０７）。つまり、検証情報が含まれているパケットについてアクションを実行するには、マッチングキーによる検索にて適合する処理規則（フローエントリ）が見つかることに加えて、処理規則（フローエントリ）に関連付けられた検証情報が受信パケットのものと一致することが必要となっている。
　一方、ステップＳ１０３で受信パケットに適合する処理規則（フローエントリ）が見つからなかった場合および処理規則（フローエントリ）が見つかったが検証情報同士が一致しない場合、ノード１０は、抽出した処理規則（フローエントリ）に記述されたアクションを実行することなく、ステップＳ１１１に進み、制御装置（コントローラ）２０に対し問い合わせ（受信パケットに対応する処理規則（フローエントリ）および検証情報の作成および送信要求）を行う。
　ステップＳ１１１では、ノード１０は、受信パケットをパケットバッファ１４に保存するとともに、制御装置（コントローラ）２０に、受信パケットを送信し、処理規則および検証情報の作成を要求する。その後は、制御装置（コントローラ）２０にて、図１１に示す手順に従って処理規則および検証情報を含む応答処理が行われる。
　制御装置（コントローラ）２０から、処理規則（フローエントリ）および検証情報の設定指示（Ｆｌｏｗ　Ｍｏｄ（Ａｄｄ））を受信すると、ノード１０は、自身のフローテーブル１３に、Ｆｌｏｗ　Ｍｏｄ（Ａｄｄ）に従い処理規則（フローエントリ）と当該処理規則に関連付けられた検証情報を設定する（ステップＳ１１２）。
　次に、ノード１０は、パケットバッファ１４に受信パケットが保存されているか否かを確認し（ステップＳ１１３）、保存されていれば（ステップＳ１１３のＹｅｓ）、当該受信パケットを読み出し（ステップＳ１１４）、前記設定した処理規則（フローエントリ）に定められた処理内容（アクション；検証情報の付与と受信パケットの指定ポートからの出力）を実行する（ステップＳ１０７）。これにより、受信パケットが次ホップのノードに転送される。
　一方、ノード１０がパケットバッファ１４を備えていない場合など、ノード１０がユーザパケットを保持していない場合（ステップＳ１１３のＮｏ）、制御装置（コントローラ）２０からのパケット出力指示（Ｐａｃｋｅｔ－Ｏｕｔ）が受信される（ステップＳ１１６）。
　前記パケット出力指示（Ｐａｃｋｅｔ－Ｏｕｔ）を受信したノード１０は、パケットバッファ１４を備えている場合にはパケットバッファ１４にパケットが保存されているか否かを確認し（ステップＳ１１７）、保存されていれば（ステップＳ１１７のＹｅｓ）、当該パケットを読み出し（ステップＳ１１８）、パケット出力指示（Ｐａｃｋｅｔ－Ｏｕｔ）とともに受信した処理内容（アクション；ここでは、受信パケットの検証情報の付与と指定ポートからの出力、または、フローテーブルの検索）を実行する（ステップＳ１０７）。また、パケットを保存していない場合（ステップＳ１１７のＮｏ）、ノード１０は、パケット出力指示（Ｐａｃｋｅｔ－Ｏｕｔ）とともに受信したパケットについて、パケット出力指示（Ｐａｃｋｅｔ－Ｏｕｔ）とともに受信した処理内容（アクション；ここでは、パケットの検証情報の付与と指定ポートからの出力、または、フローテーブルの検索）を実行する（ステップＳ１０７）。これにより、受信パケットが次ホップのノードに転送される。
　図１３、図１４は、ホスト（Ａ）からホスト（Ｂ）宛てのパケットを受信したノード＃１が、制御装置（コントローラ）２０に対し問い合わせ（処理規則および検証情報の作成要求）を行ってから、ホスト（Ｂ）にパケットが届けられるまでの一連の流れを説明するための参考図とシーケンス図である。
　図１３、図１４に示すように、ホスト（Ａ）が、ノード＃１に対し、ホスト（Ｂ）宛てのユーザパケットを送信すると（図１３、図１４のＳＴ１；Ｕｓｅｒ　Ｐａｃｋｅｔ）、ノード＃１は、フローテーブル１３の検索の結果、受信したパケットに適合する処理規則（フローエントリ）が無い未知のパケットであると判定し（図１２のステップＳ１０３のＮｏ）、制御装置（コントローラ）２０に対し問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を行う（図１３、図１４のＳＴ２；Ｐａｃｋｅｔ－Ｉｎ）。
　前記問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を受けた制御装置（コントローラ）２０は、図１１のフローチャートに従って、当該パケットの転送経路上のノード＃１～＃３に設定すべき処理規則（フローエントリ）および検証情報（ＣＡ）を作成し、ノード＃１～＃３に対し、それぞれ送信する（図１３、図１４のＳＴ３－１～ＳＴ５－１；Ｆｌｏｗ　Ｍｏｄ（Ａｄｄ）　ｗ／　ＣＡ）。
　ノード＃１～＃３は、制御装置（コントローラ）２０から送信された処理規則（フローエントリ）と検証情報（ＣＡ）を自装置のフローテーブル１３に追加するとともに、バッファＩＤが付加されている場合には当該パケットに対するアクションを実行する（図１３、図１４のＳＴ３－２～ＳＴ５－２）。以下の説明では、ノード＃２には、何らかの理由で、図１３、図１４のＳＴ４－１で送信された処理規則（フローエントリ）および検証情報（ＣＡ）が到達せず、ノード＃２のフローテーブル１３には、処理規則（フローエントリ）および検証情報（ＣＡ）が追加されなかったものとする。
　ここで、ノード＃１は、ＳＴ３－１にて受信した処理規則中のアクション（図５のＤＰＩＤ＝１、マッチングキー＝Ａ、検証情報＝ＣＡのアクション（Ａｃｔｉｏｎｓ）参照）に従い、検証情報（ＣＡ）を含んだ追加ヘッダを付加したユーザパケットを生成し（図９参照）、指定ポート（ノード＃２に接続されたポート）から出力する処理を実行する（図１３、図１４のＳＴ６）。
　検証情報（ＣＡ）を含んだ追加ヘッダが付加されたユーザパケットを受信すると、ノード＃２は、フローテーブル１３の検索の結果、受信したパケットに適合する処理規則（フローエントリ）が無い、あるいは、受信したパケットに適合する処理規則（フローエントリ）があるが検証情報が一致しないと判定し（図１２のステップＳ１０３のＮｏまたはステップ１０６のＮｏ）、制御装置（コントローラ）２０に対し問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を行う（図１３、図１４のＳＴ８；Ｐａｃｋｅｔ－Ｉｎ）。
　前記問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を受けた制御装置（コントローラ）２０は、図１１のフローチャートに従って、当該パケットの転送経路上のノード＃２に設定すべき処理規則（フローエントリ）および検証情報（ＣＡ）を取得し（図１１のステップＳ０１２）、ノード＃２に対し、送信する（図１３、図１４のＳＴ９；Ｆｌｏｗ　Ｍｏｄ（Ａｄｄ）　ｗ／　ＣＡ）。
　ノード＃２は、制御装置（コントローラ）２０から送信された処理規則（フローエントリ）および検証情報を自装置のフローテーブル１３に追加するとともに、バッファＩＤが付加されている場合にはアクションを実行する（図１３、図１４のＳＴ１０）。
　ここで、ノード＃２は、ＳＴ１０にて受信した処理規則中のアクション（図５のＤＰＩＤ＝２、マッチングキー＝Ａ、検証情報＝ＣＡのアクション（Ａｃｔｉｏｎｓ）参照）に従い、検証情報（ＣＡ）を含んだ追加ヘッダが付加されたユーザパケットを、指定ポート（ノード＃３に接続されたポート）から出力する処理を実行する（図１３、図１４のＳＴ１１）。
　検証情報（ＣＡ）を含んだ追加ヘッダが付加されたユーザパケットを受信すると、ノード＃３は、フローテーブル１３の検索の結果、受信したパケットに適合する処理規則（フローエントリ）であり、検証情報も一致すると判定し（図１２のステップＳ１０３のＹｅｓかつステップ１０６のＹｅｓ）、抽出・確認した処理規則（フローエントリ）に定められたアクションを実行する（図１３、図１４のＳＴ１２）。
　具体的には、ノード＃３は、ＳＴ１２にて抽出・確認した処理規則中のアクション（図５のＤＰＩＤ＝３、マッチングキー＝Ａ、検証情報＝ＣＡのアクション（Ａｃｔｉｏｎｓ）参照）に従い、ユーザパケットから検証情報（ＣＡ）を含んだ追加ヘッダを除去した後、指定ポート（ホスト（Ｂ）に接続されたポート）から出力する処理を実行する（図１３、図１４のＳＴ１３）。
　以上のように、本実施形態によれば、処理規則（フローエントリ）のマッチングキーが、受信パケットのヘッダ情報と一致するだけでなく、別途制御装置（コントローラ）２０にて生成された検証情報が一致することを条件として、アクションを実行するようにしているため、冒頭に述べた意図しない処理規則（フローエントリ）のアクションが実行されるという事態を回避することができる。
　なお、本実施形態では、検証情報の付加を要しないパケットの存在を考慮してステップＳ１０４において、受信パケットに検証情報が含まれていない場合、検証情報の照合を行わずにアクションを実行することとしているが、受信パケットに検証情報が含まれていない場合、例外なくアクションの実行を抑止するようにしてもよい。
［第２の実施形態］
　続いて、本発明の第２の実施形態について図面を参照して詳細に説明する。上記本発明の第１の実施形態では、検証情報を含んだ追加ヘッダによりパケットに検証情報を付加するものとして説明したが、追加ヘッダを用いずに検証情報をパケットに含めることもできる。以下、追加ヘッダを用いずに検証情報をパケットに含めるようにした第２の実施形態について説明する。なお、第２の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第１の実施形態と同等であるので、以下、相違点を中心に説明を行う。
　図１５は、本実施形態の制御装置（コントローラ）２０のフローエントリＤＢ２１に保持される情報（フローエントリ）を模式的に表した図である。第１の実施形態との相違点は、フローエントリＤＢ２１に独立した検証情報フィールドを持たず、フローエントリのマッチングキーフィールドに、検証情報（ＣＡ）を含んだマッチングキーが格納されている点と、アクションとして、ＭＡＣ　ＤＡフィールドに検証情報を書き込む（元に戻す）処理（厳密には、ＭＡＣ　ＤＡフィールドの値のＤｎ’（図１９参照）への置換と復元）が規定されている点である。以下、オリジナルのＭＡＣ　ＤＡフィールドの値を「Ｄｎ」とし、検証情報（ＣＡ）を含むよう変換された後の値を「Ｄｎ’」とする。
　例えば、図１５のＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、「Ａ」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、パケットのＭＡＣ　ＤＡフィールドに、検証情報（ＣＡ）を含む値Ｄ１’をセットしてから、９番ポートから出力する処理を実行する。ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）からＭＡＣ　ＤＡフィールドに検証情報（ＣＡ）がセットされたパケット（マッチングキーＡ’に適合するパケット）を受信すると、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）からＭＡＣ　ＤＡフィールドに検証情報（ＣＡ）がセットされたパケット（マッチングキーＡ’に適合するパケット）を受信すると、そのＭＡＣ　ＤＡフィールドを元々の受信パケットのＭＡＣ　ＤＡと同じ内容（Ｄ１）に書き戻してから、１番ポートから出力する処理を実行する。以上により、転送経路の先頭ホップのノードにて検証情報「ＣＡ」を付加し、検証情報「ＣＡ」と照合させつつ、指定した経路にて転送させる制御が実現される。
　図１６は、本実施形態の制御装置（コントローラ）２０の検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。第１の実施形態との相違点は、ＭＡＣ　ＤＡフィールドを元々の受信パケットのＭＡＣ　ＤＡと同じ内容に書き戻すためのＯｒｉｇｉｎａｌ　ＭＡＣ　ＤＡフィールドの内容（図１５のＤ１、Ｄ２、ＤＸに相当。）と、この書き戻し処理を実行させる最終ホップのノード番号が追加されている点である。
　図１７は、本実施形態のノード１０ａの詳細構成を表した図である。第１の実施形態のノード１０の構成を表した図７との相違点は、上記検証情報の相違に伴い、検証情報照合部１５２ａの照合動作が異なるため（後に詳述）、検証情報照合部１５２ａ、テーブル検索部１５３ａ、転送処理部１５ａがそれぞれ置き換えられている点である。
　図１８は、図１５のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリ）を模式的に表した図である。図１８に示すように、フローテーブル１３には、図１５のフローエントリＤＢ２１から該当するＤＰＩＤのフローエントリが設定される。図１５のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリが設定されることになる。
　図１９は、制御装置（コントローラ）２０により設定されたアクション（Ｓｅｔ　ＭＡＣ　ＤＡ　ｔｏ　Ｄ１’；図１５のＤＰＩＤ＝１のノードのアクション（Ａｃｔｉｏｎｓ）参照）に基づき、ノード１０にて書き換えられるパケットの構成を説明するための図である。図１９の例では、検証情報付きパケット３２ａは、ユーザパケット３１のＭＡＣ　ＤＡフィールドに、図１９の下段に示す４８ビットの情報を書き込んだ構成となっている。なお、図１９の例では、検証情報を含むことを示す８ビットの固定データ、関数ｆ１（最終ホップのノードのＤＰＩＤ，オリジナルのＭＡＣ　ＤＡ）、関数ｆ２（マッチングキー，乱数）を書き込むものとしているが、これはあくまで一例であり、検証情報の格納に用いるフィールドや、検証情報の内容、オリジナルのデータを縮退するための関数等は適宜変更することができる。
　続いて、本実施形態の動作について説明する。図２０は、本発明の第２の実施形態の制御装置（コントローラ）の動作を表したフローチャートである。第１の実施形態の制御装置（コントローラ）の動作を表した図１１と相違するのは、ステップＳ００２ａにおいて、問い合わせを受けたパケットに検証情報が含まれているか否かを確認する際に、追加ヘッダではなく、ＭＡＣ　ＤＡに上述した固定データ（図１９参照）が書き込まれているか否かを確認する点である。その他は、第１の実施形態と同等であるので説明を省略する。
　図２１は、本発明の第２の実施形態のノード１０ａの動作を表したフローチャートである。第１の実施形態のノード１０の動作を表した図１２と相違するのは、ステップＳ１０４ａにおいて、受信パケットに検証情報が含まれているか否かを確認する際に、追加ヘッダではなく、ＭＡＣ　ＤＡに上述した固定データ（図１９参照）が書き込まれているか否かを確認する点と、最終ホップのノードが追加ヘッダの削除ではなく、アクションに従ってオリジナルのＭＡＣ　ＤＡフィールドを復元してからパケットを転送する点である。その他は、第１の実施形態と同等であるので説明を省略する。
　以上のように、本発明は、既存パケットの特定のフィールドに検証情報を含める形態でも実現することが可能である。
［第３の実施形態］
　続いて、本発明の第３の実施形態について図面を参照して詳細に説明する。上記本発明の第１の実施形態では、各ノードが同一の検証情報をそのフローテーブルのフローエントリに関連付けて格納するものとして説明したが、各ノードがそれぞれ異なる検証情報にて照合を行う構成も採用可能である。以下、各ノードがそれぞれ異なる検証情報にて照合を行うようにした第３の実施形態について説明する。なお、第３の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第１の実施形態と同等であるので、以下、相違点を中心に説明を行う。
　図２２は、本実施形態の制御装置（コントローラ）２０のフローエントリＤＢ２１に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。第１の実施形態との相違点は、各ノードの検証情報の生成処理（図１１のステップＳ００６）をノード数分実行しておき、フローエントリＤＢ２１に独立した検証情報フィールドを持たない代わりに、アクションフィールドに、それぞれ異なる検証情報を含んだ追加ヘッダを付加させる処理を追加した点である（各ノードがそれぞれ異なる検証情報含んだヘッダを付加するため、フローエントリに関連付けられた検証情報が当該フローエントリ内に記述されることになり、独立して検証情報とフローエントリの対応関係を保持する必要がないため、検証情報フィールドは不要となる）。
　例えば、図２２のＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、「Ａ１」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、検証情報（Ｃ２Ａ）を格納した追加ヘッダを受信パケットに付加してから、９番ポートから出力する処理を実行する。同様に、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）から、検証情報（Ｃ２Ａ）を格納した追加ヘッダが付加されたパケット（マッチングキーＡ２に適合するパケット）を受信すると、追加ヘッダの検証情報（Ｃ２Ａ）を検証情報（Ｃ３Ａ）に書き換えた後、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）から、検証情報（Ｃ３Ａ）を格納した追加ヘッダが付加されたパケット（マッチングキーＡ３に適合するパケット）を受信すると、当該パケットから追加ヘッダを除去した後、１番ポートから出力する処理を実行する。以上により、転送経路の先頭ホップのノードから順番に、検証情報を書き換えながら、その検証情報と照合させつつ、指定した経路にて転送させる制御が実現される。
　図２３は、本実施形態の制御装置（コントローラ）２０の検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。第１の実施形態との相違点は、ＤＰＩＤフィールドが追加され、ノード毎に、マッチングキーと、検証情報の対応関係が格納されている点である。なお、これはあくまで一例であり、検証情報ＤＢ２７に保持される情報は、検証情報生成のための関数等に依存して、適宜変更することができる。
　図２４は、図２２のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。図２４に示すように、フローテーブル１３には、図２２のフローエントリＤＢ２１から該当するＤＰＩＤのフローエントリおよび検証情報が設定される。図２２のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリおよび検証情報が設定されることになる。
　本実施形態は第１の実施形態と比較して、制御装置が各ノードの検証情報を生成する点と個々のノードで行われるアクションが異なるのみであり、基本的な動作は第１の実施形態と同一であるので説明は省略する（図１１、図１２参照）。
　以上のように、個々のノードが処理規則中のアクションにより、検証情報を書き換えていく本実施形態によれば、第１の実施形態と比較して、ある通信フローに対してマッチングキーの異なるフローエントリを経路上のノードに設定することが可能となる。
［第４の実施形態］
　続いて、本発明の第４の実施形態について図面を参照して詳細に説明する。本発明の第４の実施形態は、上記本発明の第２の実施形態と第３の実施形態とを組み合わせたものであり、追加ヘッダを用いずに、かつ、各ノードがそれぞれ異なる検証情報にて照合を行うものである。なお、第４の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第１～３の実施形態と同等であるので、以下、相違点を中心に説明を行う。
　図２５は、本実施形態の制御装置（コントローラ）２０のフローエントリＤＢ２１に保持される情報（フローエントリ）を模式的に表した図である。第３の実施形態との相違点は、アクションフィールドに、それぞれ異なる検証情報を含んだ追加ヘッダを付加させる処理ではなく、ＭＡＣ　ＤＡフィールドの値を各ノードの検証情報を含む値に書き換えていき最終ホップで復元する処理が追加されている点である。
　例えば、図２５のＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、「Ａ」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、パケットのＭＡＣ　ＤＡフィールドに検証情報（Ｃ２Ａ）を含む値Ｄ１’をセットしてから、９番ポートから出力する処理を実行する。同様に、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）からＭＡＣ　ＤＡフィールドに検証情報（Ｃ２Ａ）がセットされたパケット（マッチングキーＡ’に適合するパケット）を受信すると、パケットのＭＡＣ　ＤＡフィールドを、検証情報（Ｃ３Ａ）を含む値Ｄ１”に書き換えた後、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）からＭＡＣ　ＤＡフィールドに検証情報（Ｃ３Ａ）がセットされたパケット（マッチングキーＡ”に適合するパケット）を受信すると、そのＭＡＣ　ＤＡフィールドを元々の受信パケットのＭＡＣ　ＤＡと同じ内容（Ｄ１）に書き戻してから、１番ポートから出力する処理を実行する。以上により、転送経路の先頭ホップのノードにて検証情報を順次書き換え、かつ、検証情報と照合させ、指定した経路にて転送させる制御が実現される。
　図２６は、本実施形態の制御装置（コントローラ）２０の検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。第３の実施形態との相違点は、ＭＡＣ　ＤＡフィールドを元々の受信パケットのＭＡＣ　ＤＡと同じ内容に書き戻すためのＯｒｉｇｉｎａｌ　ＭＡＣ　ＤＡフィールドの内容（図２５のＤ１、Ｄ２、ＤＸに相当。）と、この書き戻し処理を実行させる最終ホップのノード番号が追加されている点である。なお、これはあくまで一例であり、検証情報ＤＢ２７に保持される情報は、検証情報生成のための関数等に依存して、適宜変更することができる。
　図２７は、図２５のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリ）を模式的に表した図である。図２７に示すように、フローテーブル１３には、図２５のフローエントリＤＢ２１から該当するＤＰＩＤのフローエントリが設定される。図２５のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリが設定されることになる。
　本実施形態は第１の実施形態と比較して、制御装置が各ノードの検証情報を生成する点と個々のノードで行われるアクションが異なるのみであり、基本的な動作は第１の実施形態と同一であるので説明は省略する（図１１、図１２参照）。
　以上のように、個々のノードが処理規則中のアクションにより、検証情報を書き換えていく本実施形態によれば、第２の実施形態と比較して、ある通信フローに対してマッチングキーの異なるフローエントリを経路上のノードに設定することが可能となる。
［第５の実施形態］
　続いて、本発明の第５の実施形態について図面を参照して詳細に説明する。上記本発明の第３の実施形態では、追加ヘッダにはただ一つの検証情報を格納するものとして説明したが、追加ヘッダに、転送経路上の各ノードがそれぞれ照合すべき検証情報を格納しておき、当該追加ヘッダが付加されたパケットを受信したノードが、それぞれ自身が参照すべき検証情報を特定して、照合動作を行う構成も採用可能である。以下、追加ヘッダに複数の検証情報を格納可能とした第５の実施形態について説明する。なお、第５の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第３の実施形態と同等であるので、以下、相違点を中心に説明を行う。
　図２８は、本発明の第５の実施形態で用いるパケットの一例である。図２８の例では、検証情報付きパケット３２ｂは、検証情報を含んだ検証情報付き追加ヘッダ３３ｂをユーザパケット３１の先頭に付加した構成となっている。
　図２９は、上記検証情報付き追加ヘッダ３３ｂの構成例を示す図である。図２９の例では、検証情報付き追加ヘッダ３３ｂは、ＭＡＣ宛先アドレス（ＭＡＣ　ＤＡ）、ＭＡＣ送信元アドレス（ＭＡＣ　ＳＡ）、上位プロトコルタイプ（Ｅｔｈｅｒ　Ｔｙｐｅ）、トータルヘッダ長（Ｔｏｔａｌ　Ｌｅｎｇｔｈ）に、ＤＰＩＤと検証情報との組を複数付加した構成となっている。なお、図２９の例では、個々のノードのマッチングキーと乱数を引数とする所定の関数（ハッシュ関数等）により算出した値（ｆ（ｍａｔｃｈｉｎｇ　ｋｅｙ，ｒａｎｄ））を検証情報としている。
　本実施形態は第１の実施形態と比較して、制御装置が各ノードの検証情報を生成する点と個々のノードがＤＰＩＤを用いて自身の検証情報を取り出して照合動作を行う点が異なるのみであり、基本的な動作は第１の実施形態と同一であるので説明は省略する（図１１、図１２参照）。
　以上のように、本発明は、個々のノードの検証情報を格納した追加ヘッダを付加する構成でも実現可能であり、第３の実施形態と比較して、個々のノードで検証情報を書き換える処理を省略できるという利点がある。
　以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。上記した実施形態の制御装置（コントローラ）２０、２０ａは、専用のサーバとして実現することもでき、ノード１０、１０ａ、１０ｂとしては、上記オープンフロースイッチのほか、ＩＰ網におけるルータ、ＭＰＬＳ（Ｍｕｌｔｉ－Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ）網におけるＭＰＬＳスイッチにて実現することができる。その他、サーバがネットワーク内のノードを集中管理するようなネットワークであれば、本発明を適用することが可能である。
　また、上記した第５の実施形態では、追加ヘッダにノード識別子（ＤＰＩＤ）を含めることで、各ノードが自装置が照合すべき検証情報を特定するものとして説明したが、追加ヘッダ中の先頭または末尾の検証情報から使用していき、検証情報が使用済みであることを示す使用済みフラグを立てていく方法や、照合に用いた検証情報を各ノードが追加ヘッダから順次削除していく方法も採用可能である。
　また、上記した各実施形態では、最終ホップのノードが追加ヘッダの除去やＭＡＣ　ＤＡフィールドを書き戻すものとして説明したが、ホスト側でこれらの処理を行う構成も採用可能である。
　また、上記した各実施形態で説明した検証情報として、非特許文献２のＦｌｏｗ　Ｃｏｏｋｉｅなどのコントローラがフローエントリを一意に特定するために生成する情報を用いることも可能である。
　また、上記した各実施形態では、制御装置２０に検証情報生成部２８を備えるものとして説明したが、ノード１０同士あるいはノード１０と制御装置２０で同期を取る、各ノード１０に検証情報の生成関数や引数を割り当てておくなどして、各ノード１０が検証情報を作成可能であれば、各ノードに、検証情報生成部を生成する構成も採用可能である。
　最後に、本発明の好ましい形態を要約する。
［第１の形態］
　（上記第１の視点による通信システム参照）
［第２の形態］
　第１の形態において、
　前記識別子は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられることを特徴とする通信システム。
［第３の形態］
　第１、第２の形態において、
　前記ノードは、受信パケットと照合規則とを照合して、受信パケットと適合する照合規則に対応する処理規則を検索し、受信パケットの識別子と検索された処理規則に関連付けられた識別子とが対応する場合、検索した処理規則により受信パケットの処理を実行する通信システム。
［第４の形態］
　第１、第２の形態において、
　前記ノードは、受信パケットの識別子に対応する識別子と関連付けられた処理規則を検索し、該処理規則に対応する照合規則と受信パケットとが照合により適合する場合、検索した処理規則により受信パケットの処理を実行する通信システム。
［第５の形態］
　第１～第４の形態において、
　前記識別子は、少なくとも、受信パケットと適合する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意である通信システム。
［第６の形態］
　第１～第４の形態において、
　前記識別子は、統計的に一意である通信システム。
［第７の形態］
　第１～第６の形態において、
　前記ノードは、受信パケットに、識別子を格納した追加ヘッダが付加されているか否かにより、受信パケットに、前記受信パケットの識別子が含まれているか否かを判定する通信システム。
［第８の形態］
　第１～第６の形態において、
　前記ノードは、受信パケットの所定のフィールドに、識別子が格納されているか否かにより、受信パケットに、前記受信パケットの識別子が含まれているか否かを判定する通信システム。
［第９の形態］
　第１～第６、第８いずれか一の形態において、
　前記制御装置は、
　パケットの転送経路の始点に位置するノードが、受信パケットの所定のフィールドの情報を、識別子を含んだ情報に置き換えてから、当該パケットを転送し、
　前記転送経路の終点に位置するノードが、受信パケットの所定のフィールドの情報を、置き換え前の内容に書き戻してから、当該パケットを転送するよう、前記各ノードを制御する通信システム。
［第１０の形態］
　第１～第９いずれか一の形態において、
　前記制御装置は、
　パケットの転送経路上のノードに設定する処理規則に対し、それぞれ異なる識別子を設定し、前記転送経路上のノードが、順次、受信パケットの識別子を次ホップのノードの識別子に書き換える動作を行うよう、前記各ノードを制御する通信システム。
［第１１の形態］
　第１～第７、第１０いずれか一の形態において、
　前記制御装置は、
　パケットの転送経路の始点に位置するノードが、受信パケットに、識別子を含んだ追加ヘッダを付加してから、当該パケットを転送し、前記転送経路の終点に位置するノードが、前記追加ヘッダを除去してから、当該パケットを転送するよう、前記各ノードを制御する通信システム。
［第１２の形態］
　第７、第１１いずれか一の形態において、
　前記追加ヘッダには、パケットの転送経路上のノードにて、それぞれ判定に用いられる複数の識別子が格納されている通信システム。
［第１３の形態］
　（上記第２の視点によるノード参照）
［第１４の形態］
　（上記第３の視点による制御装置参照）
［第１５の形態］
　（上記第４の視点による通信方法参照）
［第１６の形態］
　（上記第５の視点による通信方法参照）
［第１７の形態］
　（上記第６の視点によるプログラム参照）
［第１８の形態］
　（上記第７の視点によるプログラム参照）
　なお、上記第１３～第１８の形態は、上記第１の形態と同様に、第２～第１２の形態に展開することが可能である。
　なお、上記の非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
　１０、１０ａ、１０ｂ　ノード
　１１　制御装置通信部
　１２　フローテーブル管理部
　１３　フローテーブル　
　１４　パケットバッファ
　１５、１５ａ　転送処理部
　２０　制御装置
　２１　フローエントリデータベース（フローエントリＤＢ）
　２２　トポロジ管理部
　２３　経路・アクション計算部
　２４　フローエントリ管理部
　２５　制御メッセージ処理部
　２６　ノード通信部
　２７　検証情報データベース（検証情報ＤＢ）
　２８　検証情報生成部
　３１　ユーザパケット
　３２、３２ａ、３２ｂ　検証情報付きパケット
　３３、３３ｂ　検証情報付き追加ヘッダ
　１５２、１５２ａ　検証情報照合部
　１５３、１５３ａ　テーブル検索部
　１５４　アクション実行部
　２５１　メッセージ解析・処理部
　２５２　メッセージ生成部

Claims (18)

  1. 　受信パケットを処理するノードと、
    　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、前記ノードに設定する制御装置とを含み、
    　前記ノードは、識別子を処理規則に関連付けて保持し、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより判定する
    　ことを特徴とする通信システム。
  2. 　前記識別子は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられることを特徴とする
    　請求項１に記載の通信システム。
  3. 　前記ノードは、受信パケットと照合規則とを照合して、受信パケットと適合する照合規則に対応する処理規則を検索し、受信パケットの識別子と検索された処理規則に関連付けられた識別子とが対応する場合、検索した処理規則により受信パケットの処理を実行する
    　ことを特徴とする請求項１または２に記載の通信システム。
  4. 　前記ノードは、受信パケットの識別子に対応する識別子と関連付けられた処理規則を検索し、該処理規則に対応する照合規則と受信パケットとが照合により適合する場合、検索した処理規則により受信パケットの処理を実行する
    　ことを特徴とする請求項１または２に記載の通信システム。
  5. 　前記識別子は、少なくとも、受信パケットと適合する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意である
    　請求項１から４いずれか一の通信システム。
  6. 　前記識別子は、統計的に一意であることを特徴とする
    　請求項１から４いずれか一の通信システム。
  7. 　前記ノードは、受信パケットに、識別子を格納した追加ヘッダが付加されているか否かにより、受信パケットに、前記受信パケットの識別子が含まれているか否かを判定する請求項１から６いずれか一の通信システム。
  8. 　前記ノードは、受信パケットの所定のフィールドに、識別子が格納されているか否かにより、受信パケットに、前記受信パケットの識別子が含まれているか否かを判定する請求項１から６いずれか一の通信システム。
  9. 　前記制御装置は、
    　パケットの転送経路の始点に位置するノードが、受信パケットの所定のフィールドの情報を、識別子を含んだ情報に置き換えてから、当該パケットを転送し、
    　前記転送経路の終点に位置するノードが、受信パケットの所定のフィールドの情報を、置き換え前の内容に書き戻してから、当該パケットを転送するよう、前記各ノードを制御する請求項１から６、８いずれか一の通信システム。
  10. 　前記制御装置は、
    　パケットの転送経路上のノードに設定する処理規則に対し、それぞれ異なる識別子を設定し、前記転送経路上のノードが、順次、受信パケットの識別子を次ホップのノードの識別子に書き換える動作を行うよう、前記各ノードを制御する請求項１から９いずれか一の通信システム。
  11. 　前記制御装置は、
    　パケットの転送経路の始点に位置するノードが、受信パケットに、識別子を含んだ追加ヘッダを付加してから、当該パケットを転送し、前記転送経路の終点に位置するノードが、前記追加ヘッダを除去してから、当該パケットを転送するよう、前記各ノードを制御する請求項１から７、１０いずれか一の通信システム。
  12. 　前記追加ヘッダには、パケットの転送経路上のノードにて、それぞれ判定に用いられる複数の識別子が格納されている請求項７または１１の通信システム。
  13. 　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、識別子と関連付けて保持し、
    　受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定することにより、
    　受信パケットを処理する
    　ことを特徴とするノード。
  14. 　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を生成し、
    　前記処理規則に関連付ける識別子であって、前記ノードに、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定させるための識別子を生成し、
    　通信システムに配置されて受信パケットを処理するノードに、前記処理規則と前記識別子とを設定する
    　ことを特徴とする制御装置。
  15. 　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、識別子と関連付けて保持し、
    　受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定することにより、受信パケットを処理する
    　ことを特徴とする通信方法。
  16. 　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を生成し、
    　前記処理規則に関連付ける識別子であって、前記ノードに、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定させるための識別子を生成し、
    　通信システムに配置されて受信パケットを処理するノードに、前記処理規則と前記識別子とを設定する
    　ことを特徴とする通信方法。
  17. 　通信システムにおいて受信パケットを処理するノードに、
    　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を、識別子と関連付けて記憶する処理と、
    　受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を、受信パケットの識別子と、受信パケットと適合する照合規則に対応する処理規則に関連付けられた識別子とが対応するか否かにより判定する処理と、
    　を実行させることを特徴とするプログラム。
  18. 　通信システムにおいて、受信パケットを処理するノードを制御する制御装置に、
    　照合規則と、該照合規則に適合するパケットの処理とを規定した処理規則を生成する処理と、
    　前記処理規則に関連付ける識別子であって、前記ノードに、受信パケットと適合する照合規則に対応する処理規則による受信パケットの処理の実行可否を判定させるための識別子を生成する処理と、
    　前記処理規則と前記識別子とを前記ノードに設定する処理と、
    　を実行させることを特徴とするプログラム。
PCT/JP2011/062046 2010-05-28 2011-05-26 通信システム、ノード、制御装置、通信方法およびプログラム WO2011149003A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
KR1020127031930A KR20130032314A (ko) 2010-05-28 2011-05-26 통신 시스템, 노드, 제어 장치, 통신 방법 및 프로그램
CN201180022831.3A CN102884769B (zh) 2010-05-28 2011-05-26 通信系统、节点、控制设备以及通信方法
BR112012030135A BR112012030135A2 (pt) 2010-05-28 2011-05-26 sistema de comunicação, nó, dispositivo de controle, método de comunicação e programa
RU2012157742/08A RU2556457C2 (ru) 2010-05-28 2011-05-26 Система связи, узел, устройство управления, способ связи и программа
AU2011259267A AU2011259267B2 (en) 2010-05-28 2011-05-26 Communication system, node, control apparatus, communication method and program
EP11786702.8A EP2579510B1 (en) 2010-05-28 2011-05-26 Communication system, node, control apparatus, communication method and program
JP2012517305A JP5370588B2 (ja) 2010-05-28 2011-05-26 通信システム、ノード、制御装置、通信方法およびプログラム
US13/333,827 US9426061B2 (en) 2010-05-28 2011-12-21 Communication system, node, control device, communication method, and program
HK13108288.9A HK1181928A1 (en) 2010-05-28 2013-07-15 Communication system, node, control apparatus, communication method and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010123054 2010-05-28
JP2010-123054 2010-05-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/333,827 Continuation US9426061B2 (en) 2010-05-28 2011-12-21 Communication system, node, control device, communication method, and program

Publications (1)

Publication Number Publication Date
WO2011149003A1 true WO2011149003A1 (ja) 2011-12-01

Family

ID=45003989

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/062046 WO2011149003A1 (ja) 2010-05-28 2011-05-26 通信システム、ノード、制御装置、通信方法およびプログラム

Country Status (10)

Country Link
US (1) US9426061B2 (ja)
EP (2) EP2897327B1 (ja)
JP (2) JP5370588B2 (ja)
KR (1) KR20130032314A (ja)
CN (2) CN105357035B (ja)
AU (1) AU2011259267B2 (ja)
BR (1) BR112012030135A2 (ja)
HK (1) HK1181928A1 (ja)
RU (2) RU2628151C2 (ja)
WO (1) WO2011149003A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014104278A1 (ja) * 2012-12-28 2014-07-03 日本電気株式会社 制御装置、制御装置の制御方法及びプログラム
KR101434375B1 (ko) 2011-02-17 2014-08-27 닛본 덴끼 가부시끼가이샤 플로우 통신 시스템
JP2016523062A (ja) * 2013-05-31 2016-08-04 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 入力パラメータを生成するための方法および装置

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013180207A1 (ja) * 2012-05-31 2013-12-05 日本電気株式会社 制御装置、通信システム、スイッチ制御方法及びプログラム
US9363152B2 (en) * 2012-06-11 2016-06-07 Microsoft Technology Licensing, Llc Large-scale passive network monitoring using multiple tiers of ordinary network switches
CN103929334B (zh) * 2013-01-11 2018-02-23 华为技术有限公司 网络异常通知方法和装置
US9210074B2 (en) * 2013-05-03 2015-12-08 Alcatel Lucent Low-cost flow matching in software defined networks without TCAMs
CN104412560B (zh) * 2013-05-06 2018-03-13 华为技术有限公司 基于sdn的网络配置方法、装置及系统
CN104144156B (zh) 2013-05-10 2018-09-21 华为技术有限公司 报文处理方法和装置
EP3001620A4 (en) * 2013-06-25 2016-07-13 Huawei Tech Co Ltd ROUTING NODE, CONTROL NODE, AND PROCESSING METHOD FOR ROUTING NODE
CN103581018B (zh) * 2013-07-26 2017-08-11 北京华为数字技术有限公司 报文发送方法、路由器以及业务交换器
CN104734964B (zh) 2013-12-24 2018-12-14 华为技术有限公司 报文处理方法、节点及系统
CN105075191B (zh) * 2014-01-29 2018-09-21 华为技术有限公司 无线网络数据处理装置和无线网络系统
EP3116175A4 (en) * 2014-03-04 2017-09-13 Nec Corporation Server, control device, management device, communication system, communication method, control method, management method, and program
US9565114B1 (en) * 2014-03-08 2017-02-07 Google Inc. Weighted load balancing using scaled parallel hashing
US9491031B2 (en) * 2014-05-06 2016-11-08 At&T Intellectual Property I, L.P. Devices, methods, and computer readable storage devices for collecting information and sharing information associated with session flows between communication devices and servers
JP2016015672A (ja) * 2014-07-03 2016-01-28 日立金属株式会社 ネットワーク制御装置、及びネットワーク設定システム
US10069727B2 (en) * 2015-04-17 2018-09-04 International Business Machines Corporation Data packet retransmission processing
US9654424B2 (en) * 2015-07-31 2017-05-16 Nicira, Inc. Managed forwarding element with conjunctive match flow entries
US10348619B2 (en) 2015-07-31 2019-07-09 Nicira, Inc. Generating conjunctive match flow entries
EP3361684B1 (en) 2015-10-31 2020-07-29 Huawei Technologies Co., Ltd. Route determining method and corresponding apparatus and system
WO2018006929A1 (en) * 2016-07-04 2018-01-11 Telefonaktiebolaget Lm Ericsson (Publ) Packet buffering in a telecommunications network
EP3267658A1 (de) * 2016-07-08 2018-01-10 Deutsche Telekom AG Netzwerkentität zum kommunizieren mit einer weiteren netzwerkentität über ein kommunikationsnetzwerk
EP3614642B1 (de) * 2018-08-20 2021-03-17 Siemens Aktiengesellschaft Verfahren zum einrichten eines streams, verfahren zur bereitstellung von stream-kennungs-informationen, verwendung eines namensdienst-servers, gerät, computerprogramm und computerlesbares medium
CN110972138B (zh) 2018-09-30 2021-06-15 华为技术有限公司 一种数据处理方法及其数据处理设备
CN115827754A (zh) * 2022-11-25 2023-03-21 北京友友天宇系统技术有限公司 基于抽象策略模型的同构环境下的数据处理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0998189A (ja) * 1995-09-29 1997-04-08 Toshiba Corp ネットワーク中継装置
JP2010050719A (ja) * 2008-08-21 2010-03-04 Nippon Telegr & Teleph Corp <Ntt> 通信システム、制御ノード、通信方法、およびプログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05189318A (ja) * 1992-01-16 1993-07-30 Fujitsu Ltd 情報処理装置
US6154776A (en) * 1998-03-20 2000-11-28 Sun Microsystems, Inc. Quality of service allocation on a network
JP2003512799A (ja) 1999-10-20 2003-04-02 アルカテル・インターネツトワーキング・インコーポレイテツド データ通信スイッチのためのオンスイッチポリシールールキャッシング
US7436830B2 (en) * 2000-04-03 2008-10-14 P-Cube Ltd. Method and apparatus for wire-speed application layer classification of upstream and downstream data packets
KR100425745B1 (ko) * 2001-11-24 2004-04-06 엘지전자 주식회사 패킷의 헤더압축을 지원하는 통신 시스템에서 패킷의전송방법
US7688832B2 (en) * 2005-01-28 2010-03-30 Cisco Technology, Inc. MPLS cookie label
US20080212613A1 (en) * 2007-03-02 2008-09-04 Perkinson Terry D Multilink meshed transport service
KR101495126B1 (ko) * 2010-03-17 2015-02-24 닛본 덴끼 가부시끼가이샤 통신 시스템, 노드, 제어 서버 및 통신 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0998189A (ja) * 1995-09-29 1997-04-08 Toshiba Corp ネットワーク中継装置
JP2010050719A (ja) * 2008-08-21 2010-03-04 Nippon Telegr & Teleph Corp <Ntt> 通信システム、制御ノード、通信方法、およびプログラム

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
NICK MCKEOWN, OPENFLOW: ENABLING INNOVATION IN CAMPUS NETWORKS, 26 February 2010 (2010-02-26), Retrieved from the Internet <URL:http://www.openflowswitch.org//documents/openflow-wp-latest.pdf>>
OPENFLOW SWITCH SPECIFICATION, 1 April 2010 (2010-04-01), Retrieved from the Internet <URL:http://www.openflowswitch.org/documents/openflow-spec-vl.0.0.pdf>>
See also references of EP2579510A4
YASUNOBU CHIBA ET AL.: "A Proposal of Flow Entry Reduction Scheme for Flow-based Networks and Its Implementation on OpenFlow-based Network", IEICE TECHNICAL REPORT, NS2009-162 TO NS2009- 260, NETWORK SYSTEM, vol. 109, no. 448, 25 February 2010 (2010-02-25), pages 7 - 12, XP008168095 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101434375B1 (ko) 2011-02-17 2014-08-27 닛본 덴끼 가부시끼가이샤 플로우 통신 시스템
WO2014104278A1 (ja) * 2012-12-28 2014-07-03 日本電気株式会社 制御装置、制御装置の制御方法及びプログラム
US9847916B2 (en) 2012-12-28 2017-12-19 Nec Corporation Control apparatus, control apparatus control method, and program
JP2016523062A (ja) * 2013-05-31 2016-08-04 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 入力パラメータを生成するための方法および装置

Also Published As

Publication number Publication date
JPWO2011149003A1 (ja) 2013-07-25
BR112012030135A2 (pt) 2016-12-13
US20120093158A1 (en) 2012-04-19
CN102884769B (zh) 2015-11-25
RU2628151C2 (ru) 2017-08-15
US9426061B2 (en) 2016-08-23
EP2579510A1 (en) 2013-04-10
RU2556457C2 (ru) 2015-07-10
AU2011259267B2 (en) 2015-01-15
CN105357035B (zh) 2019-02-12
AU2011259267A1 (en) 2012-11-15
KR20130032314A (ko) 2013-04-01
EP2579510B1 (en) 2015-02-25
CN105357035A (zh) 2016-02-24
JP2013236399A (ja) 2013-11-21
HK1181928A1 (en) 2013-11-15
EP2897327A1 (en) 2015-07-22
RU2015120346A (ru) 2015-11-20
CN102884769A (zh) 2013-01-16
RU2012157742A (ru) 2014-07-10
EP2579510A4 (en) 2014-03-12
EP2897327B1 (en) 2016-09-14
JP5370588B2 (ja) 2013-12-18
JP5598582B2 (ja) 2014-10-01

Similar Documents

Publication Publication Date Title
JP5598582B2 (ja) 通信システム、ノード、制御装置、通信方法およびプログラム
JP5768861B2 (ja) 通信システム、ノード、制御サーバ、通信方法およびプログラム
JP6418261B2 (ja) 通信システム、ノード、制御装置、通信方法及びプログラム
JP5494668B2 (ja) 情報システム、制御サーバ、仮想ネットワーク管理方法およびプログラム
JP5994851B2 (ja) 転送装置の制御装置、転送装置の制御方法、通信システムおよびプログラム
JP5854048B2 (ja) 通信システム、転送ノード、制御装置、通信制御方法およびプログラム
US10171352B2 (en) Communication system, node, control device, communication method, and program
JP5854047B2 (ja) 通信システム、制御装置、転送ノード、通信制御方法およびプログラム
WO2014126094A1 (ja) 通信システム、通信方法、制御装置、制御装置の制御方法及びプログラム
WO2014175335A1 (ja) 制御装置、計算機システム、通信制御方法及びプログラム
JP5768600B2 (ja) 通信システム、制御装置、パケット転送方法およびプログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180022831.3

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11786702

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012517305

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 2011259267

Country of ref document: AU

Date of ref document: 20110526

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20127031930

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2011786702

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10737/CHENP/2012

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 2012157742

Country of ref document: RU

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112012030135

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112012030135

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20121127