WO2015118822A1 - 通信制御システム、通信制御方法および通信制御プログラム - Google Patents

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

Info

Publication number
WO2015118822A1
WO2015118822A1 PCT/JP2015/000262 JP2015000262W WO2015118822A1 WO 2015118822 A1 WO2015118822 A1 WO 2015118822A1 JP 2015000262 W JP2015000262 W JP 2015000262W WO 2015118822 A1 WO2015118822 A1 WO 2015118822A1
Authority
WO
WIPO (PCT)
Prior art keywords
domain
controller
communication
adjacent
ofc
Prior art date
Application number
PCT/JP2015/000262
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 US15/111,082 priority Critical patent/US9998367B2/en
Priority to EP15745896.9A priority patent/EP3104561A4/en
Priority to JP2015561200A priority patent/JP6191703B2/ja
Publication of WO2015118822A1 publication Critical patent/WO2015118822A1/ja

Links

Images

Classifications

    • 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/48—Routing tree calculation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • 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/02—Topology update or discovery
    • H04L45/036—Updating the topology between route computation elements, e.g. between OpenFlow controllers
    • 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/02—Topology update or discovery
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • 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/12—Shortest path evaluation
    • 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/18—Loop-free operations
    • 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/64—Routing or path finding of packets in data switching networks using an overlay routing layer

Definitions

  • the present invention relates to a communication control system, a communication control method, and a communication control program for performing communication control between controllers that manage a plurality of communication devices.
  • OpenFlow is widely known as a technology for centrally managing multiple communication devices with a single control device.
  • one or more OpenFlow switches (Open Flow Switch, hereinafter referred to as OFS) are controlled by an OpenFlow controller (OpenFlow Controller, hereinafter referred to as OFC).
  • OFS Open Flow Switch
  • OFC OpenFlow Controller
  • Patent Document 1 discloses a load that enables load balancing of a controller even in a combination of a switch and a controller that does not have a load balancing function uniquely, or in a combination of a switch and a controller that have incompatible load balancing functions due to differences in manufacturers.
  • a distributed system is described.
  • a proxy is installed between a switch and a controller, and the proxy notifies a plurality of controllers of connections from one switch and becomes a master for the switch.
  • One controller is determined, and an inquiry message from the switch is transferred to only one master controller.
  • OFC detects the subordinate topology managed by itself without being aware of the connection with OFS groups managed by other OFCs.
  • the OFS group managed by the OFC is referred to as an OFC domain. That is, the OFC controls BCMC (Broadcast and Multicast), Unknown unicast, and Unicast transfer using the OpenFlow protocol based on the topology of the own OFC domain detected for each OFC.
  • BCMC Broadcast and Multicast
  • Unknown unicast Unknown unicast
  • Unicast transfer using the OpenFlow protocol based on the topology of the own OFC domain detected for each OFC.
  • the OFC detects and controls only the topology of its own OFC domain, the following problems occur.
  • FIG. 11 is an explanatory diagram showing an example in which two OFC domains are connected by a plurality of lines.
  • the OFC1 domain 110 and the OFC2 domain 120 are connected by two lines C41 and C42.
  • the OFC1 domain 110 is a domain managed by OFC1
  • the OFC2 domain 120 is a domain managed by OFC2.
  • the OFC1 domain 110 includes four OFS (OFS1 to 4).
  • OFS1 and OFS2 are connected by a line C11
  • OFS1 and OFS3 are connected by a line C12
  • OFS2 and OFS4 are connected by a line C13
  • OFS3 and OFS4 are connected by a line C14.
  • a client PC (Personal Computer) 210 is connected to the OFS 1 of the OFC 1 domain 110.
  • the OFC2 domain 120 similarly includes four OFS (OFS1 to 4).
  • OFS1 and OFS2 are connected by a line C21
  • OFS1 and OFS3 are connected by a line C22
  • OFS2 and OFS4 are connected by a line C23
  • OFS3 and OFS4 are connected by a line C24.
  • OFC 1 detects (discovers) the topology of the OFC 1 domain 110
  • OFC 2 detects (discovers) the topology of the OFC 2 domain 120.
  • the OFC 1 constructs a logical spanning tree so as to block (block) the line C14 in its own domain
  • the OFC 2 blocks (blocks) the line C23 in its own domain.
  • MCLAG Multi-Chasis Link Aggregation Group
  • FIG. 12 is an explanatory diagram showing an example when three OFC domains are connected.
  • the OFC3 domain 130 is a domain managed by the OFC3.
  • the OFC1 domain 110 and the OFC3 domain 130 are connected by a line C43, and the OFC2 domain 120 and the OFC3 domain 130 are connected by a line C44.
  • the OFC3 domain 130 also includes four OFS (OFS1 to 4).
  • OFS1 and OFS2 are connected by line C31
  • OFS1 and OFS3 are connected by line C32
  • OFS2 and OFS4 are connected by line C33
  • OFS3 and OFS4 are connected by line C34.
  • the OFC1 domain 110 and the OFC2 domain 120 are connected by MCLAG created using the line C41 and the line C42.
  • the BCMC packet transmitted from the PC 1 passes through the MCLAG created using the line C 41 and the line C 42, the link of the line C 43 and the line C 44, and the OFC 1 domain 110, the OFC 2 domain 120, and the OFC 3 domain 130. Loop between. Therefore, a BCMC storm occurs in the entire system illustrated in FIG.
  • the present invention enables communication using an optimal route without looping communication even when a physical loop exists between a plurality of connected OFC domains in an open flow network environment. It is an object to provide a communication control system, a communication control method, and a communication control program that can be performed.
  • the communication control system controls communication between controller domains in a network in which controller domains indicating ranges in which at least one or more OpenFlow switches are managed by each OpenFlow controller are connected to each other.
  • An adjacent domain specifying means for specifying a controller domain adjacent to the own controller domain; a loop solving means for creating a communication tree that avoids a loop configuration existing in a communication path between adjacent controller domains;
  • the topology specifying means for specifying the network topology between the controller domains and the network topology, the optimum route based on the communication tree is calculated, and communication from the communication device connected to each OpenFlow switch is controlled. Characterized in that a signal control unit.
  • Another communication control system controls communication between controller domains in a network in which controller domains indicating ranges in which at least one or more OpenFlow switches are managed by each OpenFlow controller are connected to each other.
  • An open flow controller comprising a plurality of OpenFlow controllers and a topology manager that is connected so that communication from the OpenFlow controller reaches and creates a communication tree indicating a communication path between controller domains.
  • Adjacent domain specifying means for specifying a controller domain adjacent to its own controller domain, and adjacent domain information transmitting means for transmitting information indicating the specified adjacent controller domain to the topology manager
  • a communication control means for calculating an optimum route based on the network topology calculated by the topology manager and controlling communication from a communication device connected to each OpenFlow switch, and received by the topology manager from the OpenFlow controller Based on the information, the network topology between each controller domain is specified, and a communication tree creation means for creating a communication tree that avoids a loop configuration existing in the communication path between adjacent controller domains and the created communication tree are opened.
  • Network topology distribution means for distributing to the flow controller.
  • the communication control method is a communication control for controlling communication between controller domains in a network in which controller domains indicating ranges in which at least one or more OpenFlow switches are managed by each OpenFlow controller are connected to each other.
  • a communication control program is provided in a computer that controls communication between controller domains in a network in which controller domains indicating ranges in which at least one or more OpenFlow switches are managed by each OpenFlow controller are connected to each other.
  • Applicable communication control program that creates a communication tree that avoids a loop configuration that exists in the communication path between adjacent controller domains, and an adjacent domain specifying process that specifies a controller domain adjacent to its own controller domain. Loop solving process, topology identifying process for identifying the network topology between the controller domains, and calculating the optimal route based on the communication tree using the network topology, Characterized in that to execute a communication control process for controlling the communication from the communication device connected to the pitch.
  • FIG. FIG. 1 is an explanatory diagram showing a configuration example of a first embodiment of a communication control system according to the present invention.
  • FIG. 2 is a block diagram showing a configuration example of the OFC used in the communication control system of this embodiment.
  • the communication network includes three OFC domains (OFC domains 110, 120, and 130) and four OFSs managed by the OFC in each OFC domain. That is, the environment described below is a multi-controller environment including three OFCs.
  • the number of OFC domains included in the communication control system is not limited to three, and may be four or more. Further, the number of OFS included in each OFC domain is not limited to four, but may be 1 to 3, or 5 or more.
  • FIG. 2 shows the functional module configuration of the OFC of this embodiment.
  • the OFC 100 illustrated in FIG. 2 controls the OFC domain.
  • the OFC 100 illustrated in FIG. 2 corresponds to the OFC1, OFC2, and OFC3 illustrated in FIG.
  • the OFC 100 includes a path calculation module 10, a topology management module 20, a message analysis module 30, and a message transmission / reception module 40.
  • the message transmission / reception module 40 is a module for transmitting / receiving an OpenFlow message.
  • the message analysis module 30 analyzes the OpenFlow message received from the message transmission / reception module 40 and notifies the higher module (the route calculation module 10 and the topology management module 20). In addition, the message analysis module 30 converts the OFS control message issued from the upper module (the route calculation module 10 and the topology management module 20) into an open flow message and notifies the message transmission / reception module 40.
  • the topology management module 20 includes an interdomain topology management module 21 and an internal domain topology management module 22.
  • Topology management module 20 (more specifically, interdomain topology management module 21 and internal domain topology management module 22) is realized by a CPU of a computer that operates according to a program (communication control program).
  • the program is stored in a storage unit (not shown) of the OFC 100, and the CPU reads the program and, according to the program, the topology management module 20 (more specifically, the inter-domain topology management module 21 and the internal domain). It may operate as a topology management module 22).
  • each of the inter-domain topology management module 21 and the internal domain topology management module 22 may be realized by dedicated hardware. Further, the topology management module 20 may collectively perform the processes performed by the inter-domain topology management module 21 and the internal domain topology management module 22.
  • the internal domain topology management module 22 searches the topology in the OFC domain and maintains the topology.
  • the method for searching the topology in the OFC domain varies depending on the implementation of the OFC, but the internal domain topology management module 22 may search the topology and maintain the topology using a generally known method.
  • a detailed description of the topology search method and maintenance method in the OFC domain managed by the OFC is omitted.
  • the inter-domain topology management module 21 searches for topology between OFC domains and maintains the topology. Further, the inter-domain topology management module 21 notifies the route calculation module 10 of information on the searched topology.
  • the path calculation module 10 includes a MAC (Media Access Control) / destination domain table storage unit 11, a MAC local table storage unit 12, and an inter-domain topology information storage unit 13.
  • the MAC / destination domain table storage unit 11, the MAC local table storage unit 12, and the inter-domain topology information storage unit 13 are realized by, for example, a memory or a magnetic disk.
  • the route calculation module 10 is realized by a CPU of a computer that operates according to a program (communication control program).
  • the inter-domain topology information storage unit 13 holds topology information between OFC domains in the entire system notified from the inter-domain topology management module 21.
  • the MAC local table storage unit 12 holds MAC information learned in the own OFC domain.
  • the MAC information is updated by the movement or disappearance of the OFS in the own OFC domain or new learning.
  • the topology management module 20 floods OFCSDA (OFC Source Domain Advertise) to another OFC domain when the MAC information disappears or when new MAC information is learned.
  • OFCSDA OFFC Source Domain Advertise
  • the MAC / destination domain table storage unit 11 stores a MAC / destination domain table generated based on information collected from other OFC domains (for example, OFCSDA).
  • inter-domain topology management module 21 the processing performed by the inter-domain topology management module 21 will be described in detail.
  • the inter-domain topology management module 21 specifies an OFC domain adjacent to its own OFC domain and notifies the OFC in another OFC domain.
  • the inter-domain topology management module 21 uses an OFC ND (OFC Neighbor Discovery) packet to search for an adjacent OFC domain.
  • OFC ND OFFC Neighbor Discovery
  • an OFCND packet with a packet type of NAD may be referred to as an OFCNDAD packet
  • an OFCND packet with a packet type of NRS may be referred to as an OFCNRS packet.
  • FIG. 3 is an explanatory diagram showing an example of information propagated by an OFCND packet whose packet type is NAD.
  • FIG. 4 is an explanatory diagram showing an example of information propagated by an OFCND packet whose packet type is NRS.
  • the OFCND message includes a Type field indicating the type and a Node field indicating the type of the node (Node).
  • the Node field includes fields of OFC Domain ID, OFS Domain ID, OFS ID, OFS Port ID, and Port Link Cost.
  • the OFC Domain ID includes the sending domain ID
  • the OFS Domain ID includes the OFS domain ID
  • the OFS ID includes the OFS ID
  • the OFS Port ID includes the port ID of the OFS to be transmitted and the information indicating the link cost of the port to be transmitted.
  • NN Neighbor Node
  • the OFC Domain ID receives the adjacent OFC domain ID that received the NAD
  • the OFS Domain ID receives the adjacent OFS domain ID that received the NAD
  • the OFS ID receives the NAD.
  • information indicating the port ID of the adjacent OFS that has received the NAD and information indicating the link cost of the adjacent port that has received the NAD is set in the Port Link Cost.
  • the OFS Domain ID in the Node field is a field for identifying each OFS group when one OFC manages a plurality of isolated island-state OFS groups.
  • FIG. 5 is an explanatory diagram showing a state in which the OFC manages a plurality of OFS groups.
  • the OFC 1 manages two OFS domains, respectively.
  • each OFC may manage a plurality of isolated (island state) OFS groups.
  • the OFS Domain ID is assigned a unique ID within the OFC domain and is managed by the OFC.
  • a unique ID is also assigned to the OFC Domain ID within the communication control system.
  • the method of allocating the OFC Domain ID is arbitrary.
  • the OFC Domain ID may be set manually for each OFC, or may be automatically assigned between OFCs, or may be automatically assigned by another device having a centralized management function. Good.
  • the frame of the OFCND packet is not particularly limited as long as the following conditions are satisfied.
  • Each OFC transmits an OFFCNAD packet to another OFC domain, and the OFC that has received the OFFCNAD returns an OFCNRS to the OFC domain that has transmitted the OFCNAD, thereby identifying an adjacent OFC domain (neighbor discovery).
  • the inter-domain topology management module 21 transmits an OFNAD packet to another OFC domain.
  • the inter-domain topology management module 21 replies OFFCRS to the OFC domain that transmitted the OFNAD.
  • the inter-domain topology management module 21 records the port that has transmitted the OFCNAD packet as an outgoing port with a neighbor (a port in which an adjacent OFC domain exists).
  • OFC-OFS domain a domain managed by the OFC.
  • there is one OFS domain managed by the OFC but the same applies to the case where there are two or more OFS domains.
  • the internal domain topology management module 22 detects the topology of its own OFC-OFS domain and constructs a physical BCMC distribution tree and a logical BCMC distribution tree. Note that a method for detecting a topology in its own domain and a method for constructing a distribution tree are widely known, and a description thereof is omitted here.
  • the outgoing port state is set to information (for example, 0) indicating that the connection is unknown. Therefore, the internal domain topology management module 22 sets the flow entry so as to prohibit transmission / reception of packets other than OFCND from the outward port whose outgoing port state is set to 0.
  • the internal domain topology management module 22 may perform settings for permitting transmission / reception of the packet in the same manner as OFCND.
  • the internal domain topology management module 22 notifies the inter-domain topology management module 21 of the outward port state.
  • the inter-domain topology management module 21 registers a flow entry (OFCND packet inflow) for packetizing an OFCND packet that satisfies the following conditions for an outgoing port whose outgoing port state is 0.
  • OFCND packet inflow a flow entry for packetizing an OFCND packet that satisfies the following conditions for an outgoing port whose outgoing port state is 0.
  • the internal domain topology management module 22 transmits an OFNAD packet to all outward ports using a Packet_Out message. Since the OFFCNAD packet reaches the external OFC domain with connectivity, the OFCNDAD packet matches the OFCND packet inflow and is Packeted-In to the OFC.
  • the inter-domain topology management module 21 compares the received MACSA in the OFFCNAD, the OFC Domain ID and OFS Domain ID in the ON Node with the OFS Domain ID that has received the own MAC, the own OFC domain ID, and the OFNAD.
  • the inter-domain topology management module 21 immediately blocks the packet transfer from the port identified by the OFS Port ID of the ON Node or the OFS Port that has received the OFNAD. Which port is to be blocked may be determined according to the implementation of the OFC.
  • the inter-domain topology management module 21 transmits the OFCNRS packet to the receiving port of the OFCNAD packet. Since the OFCNRS packet reaches the OFC domain that transmitted the OFCDNAD, it matches the OFCND packet inflow and is Packeted-In to the OFC.
  • the inter-domain topology management module 21 compares the OFS domain ID, OFS domain ID, OFS ID, and PORT ID that received the OFCRS with the information of the ON Node in OFCNRS. If all items do not match, the received packet is discarded.
  • the inter-domain topology management module 21 connects the OFC-OFS domain under its management with the adjacent OFC-OFS domain from the ON Node information and NN Node information of the received OFCNRS.
  • the inter-domain topology information storage unit 13 stores a neighbor domain DB as information indicating that the information has been stored.
  • the inter-domain topology management module 21 determines that the port connected to the external OFC-OFS domain is an outgoing port where an adjacent domain exists, and sets the outgoing port state to 2. That is, an outward port in which 2 is set in the outward port state indicates that neighbor discovery has been completed and an adjacent domain exists.
  • the inter-domain topology management module 21 sets the outgoing port state to 1 for the outgoing port for which the outgoing port state is set to 0. To do. That is, an outward port with 1 set to the outward port state indicates that neighbor discovery has been completed and there is no adjacent domain.
  • the inter-domain topology management module 21 recognizes an outward port in which 1 is set in the outward port state as an outward port in which no adjacent domain exists.
  • the inter-domain topology management module 21 performs general processing (for example, processing for permitting packet in, processing performed as an element of the BCMC tree in the OFC) performed by the OFC on the outbound port with respect to the outbound port. Do.
  • the OFC maintains the neighbor domain DB by sending and receiving OFCND to all outward ports. For example, when a new OFCNRS for OFNAD is correctly received, the inter-domain topology management module 21 updates the neighbor domain DB with new information.
  • the inter-domain topology management module 21 performs a certain retry process and performs operations such as deleting the corresponding information from the neighbor domain DB.
  • the interdomain topology management module 21 determines whether a loop exists in the communication path.
  • the loop in the communication path may be referred to as a closed graph.
  • the inter-domain topology management module 21 uses an OFCDU (OFC Data Unit) packet when determining whether or not a loop exists.
  • OFCDU OFFC Data Unit
  • OFCDU has the same format as the BPDU (Bridge Protocol Data Unit) packet used in STP (Spanning Tree Protocol). However, while the BPDU packet is used for transmission of switch information, the OFCDU packet used in this embodiment is used for transmission of information exemplified below (specifically, information of the OFC-OFS domain). .
  • BPDU Binary Protocol Data Unit
  • STP Session Transfer Protocol
  • Root OFC-OFS Domain ID Transmission OFC-OFS Domain ID Root Path Cost (for each OFC-OFS domain, the path cost with the root OFC-OFS domain)
  • the inter-domain topology management module 21 performs processing on OFCDU using the same algorithm as STP. Hereinafter, processing for avoiding a loop will be described.
  • the inter-domain topology management module 21 registers a flow entry (OFCDU packet inflow) for packetizing an OFCDU packet that satisfies the following conditions with respect to all outward ports where adjacent domains exist. -When the OFCDU packet is received, the OFC makes Packet_In.
  • the inter-domain topology management module 21 transmits and receives OFCDUs from all outward ports where adjacent domains exist. By sending and receiving OFCDU between OFCs, OFC determines Root OFC-OFS Domain.
  • the inter-domain topology management module 21 first recognizes that all OFC-OFS Domains managed by itself are Root OFC-OFS Domains, and sets the OFC-OFS Domain ID as the OFCDU Root OFC. -Set to OFS Domain ID. Then, the inter-domain topology management module 21 transmits the OFCDU to each outward port where an adjacent domain exists.
  • Each controller compares the OFCDU Root OFC-OFS Domain ID of the received OFCDU with the OFC-OFS Domain ID managed by itself.
  • the inter-domain topology management module 21 determines that it is not the Root OFC-OFS Domain.
  • Root OFC-OFS Domain The outgoing port where the adjacent domain exists in Root OFC-OFS Domain becomes the representative port. In the other OFC-OFS Domain, the port closest to the Root OFC-OFS Domain (Root Path Cost) is the Root Port.
  • the OFC-OFS Domain ports that are close to the Root OFC-OFS Domain become representative ports, and the far ports become non-representative ports.
  • the inter-domain topology management module 21 performs general processing (for example, processing for permitting packet in, processing performed as an element of a BCMC tree in the OFC, etc.) performed by the OFC on the representative port in which the adjacent domain exists. )I do.
  • general processing for example, processing for permitting packet in, processing performed as an element of a BCMC tree in the OFC, etc.
  • OFC on the representative port in which the adjacent domain exists.
  • a communication tree single path
  • such a communication tree may be referred to as Inter-Domain BCMC Tree.
  • the inter-domain topology management module 21 may sequentially compare the transmission OFC-OFS Domain ID, the reception OFS ID, and the reception OFS Port ID in the OFCDU.
  • the inter-domain topology management module 21 maintains Inter-Domain BCMC Tree using a method similar to the method used in STP.
  • the inter-domain topology management module 21 of Root OFC-OFS Domain may, for example, continuously transmit OFCDUs at regular intervals. When the OFCDU cannot be received within a certain time, the inter-domain topology management module 21 may transmit the OFCDU by itself and perform the loop discovery process again.
  • the inter-domain topology management module 21 calculates a communication tree that avoids the loop configuration used in the STP for the closed graph. .
  • communication between OFC-OFS domains becomes possible via Inter-Domain BCMC Tree, which is a built communication tree.
  • the inter-domain topology management module 21 specifies the network topology between the OFC domains.
  • the inter-domain topology management module 21 uses an OFCTDDU (OFC Topology Discovery Data Unit) packet when determining the network topology between domains.
  • OFCTDDU OFFC Topology Discovery Data Unit
  • FIG. 6 is an explanatory diagram showing an example of the OCTDDU packet.
  • the OFCTDDU packet illustrated in FIG. 6 includes fields of OFC Domain ID, OFS Domain ID, OFS ID, OFS Port ID, and Port Link Cost for each Node ID.
  • the frame of the OCCTDDU packet is not particularly limited as long as the following conditions are satisfied.
  • Node information is stored in each Node label.
  • the inter-domain topology management module 21 increments the last Node ID of the OCCTDDU, creates a new Node label, and stores the received OFC-OFS domain information in the Node label. .
  • the inter-domain topology management module 21 of each OFC transmits OFCTDDU storing the OFC-OFS Domain information of the transmission source to all outward ports where adjacent domains exist.
  • the inter-domain topology management module 21 determines whether the information indicating the OFC-OFS Domain that has received the OFCTDDU is included in the OFCTDDU.
  • the inter-domain topology management module 21 learns the topology information.
  • the inter-domain topology management module 21 learns the topology information and further adds OFC-OFS Domain information to OFCTDDU, and there is an adjacent domain other than the receiving port. Forward to outgoing port.
  • the OFC topology management module 20 identifies the topology of the entire network (hereinafter also referred to as “Inter-Domain Topology”) based on the collected topology information, and notifies the route calculation module 10 of it.
  • the inter-domain topology management module 21 may use the largest value among the link costs of adjacent ports as the link cost (edge cost) in the topology.
  • the route calculation module 10 calculates a route based on the above-described communication route using the specified network topology, and controls communication from devices connected to each OFS. Specifically, the route calculation module 10 rewrites the broadcast MACDA of ARP (Address Resolution Protocol) Request, and sets the MACSA source OFC-OFS Domain ID information. Then, the path calculation module 10 notifies the rewritten packet to other OFCs via the Inter-Domain BCMC Tree.
  • ARP Address Resolution Protocol
  • FIG. 7 is an explanatory diagram illustrating an example of an OFSDA packet and an OFSDD packet.
  • “03255c00” is set as a fixed value for identifying the OFSDA.
  • “03255c01” is set as a fixed value for identifying OFSDD.
  • the OFSDA packet and OFSDD packet shown in FIG. 7 are examples. However, the following conditions are satisfied.
  • ⁇ MACDA Multicast It has a field for storing an identifier for identifying OFCDA and OFCDD. It has a field for storing MACSA transmission source OFC-OFS Domain ID information. ⁇ Ether Type ARP
  • the path calculation module 10 registers the following OFCDA-OFCDD packet inflow for an outward port where an adjacent domain exists on the Inter-Domain BCMC Tree. -When OFCDA or OFCDD is received, Packet_In is made to OFC.
  • the route calculation module 10 passes the BC ARP Request received from the terminal (for example, PC) through the BCMC tree inside the OFC domain to the outgoing port where no adjacent domain exists in each OFS in each OFS domain. Flood.
  • the route calculation module 10 learns the MAC ARP Request BCSA and registers it in the MAC local table storage unit 12.
  • the route inside the OFS domain is specified by an existing method.
  • the route calculation module 10 rewrites the BC ARP Request received from the terminal (for example, PC) to OFSDA, and floods to the outward port where the adjacent domain exists on the Inter-Domain BCMC Tree.
  • the path calculation module 10 registers the MACSA included in the OFSDA and the OFC domain ID and OFS domain ID set in the MACDA in the MAC / destination domain table storage unit 11.
  • the path calculation module 10 floods the OFCDA packet to all outward ports (excluding reception ports) in which adjacent domains exist on the Inter-Domain BCMC Tree.
  • the route calculation module 10 floods the ARP Request, in which the MACDA of the OFCDA is written back to the broadcast MACDA, to the outgoing port where the adjacent domain does not exist in the domain via the BCMC tree inside the received OFC domain. .
  • each OFC can grasp the ID of the OFC-OFS Domain in which the terminal MAC exists.
  • the path calculation module 10 When the MAC of the terminal exists in the MAC local table storage unit 12, the path calculation module 10 performs control to transfer a packet to a port where the MAC of the terminal exists by a general method. For example, the route calculation module 10 may control to add a flow entry and transfer a packet.
  • the path calculation module 10 searches the MAC / destination domain table storage unit 11.
  • the route calculation module 10 recognizes the received packet as an unknown unicast packet. Then, the route calculation module 10 sends the received packets to all outgoing ports where the adjacent domain exists on the Inter-Domain BCMC Tree and to outgoing ports where the adjacent domain does not exist within the own OFC-OFS domain. Flood.
  • the path calculation module 10 starts from the own OFC-OFS domain that received the Unicast packet, and the destination OFC-OFS in the MAC / destination domain table.
  • the shortest path is searched with the domain as the end point.
  • the route calculation module 10 may search for the shortest route using any commonly used search algorithm such as the Dijkstra method.
  • the path calculation module 10 may select a path using a predetermined distributed algorithm (for example, round robin method, MAC hash, IP hash, etc.).
  • a predetermined distributed algorithm for example, round robin method, MAC hash, IP hash, etc.
  • the path calculation module 10 controls the OFC to transfer the corresponding packet to the port connected to the OFC-OFS domain on the calculated shortest path. For example, the path calculation module 10 sets a flow entry in OFS and causes hardware transfer of a Unicast packet to be transmitted.
  • the path calculation module 10 deletes the disappearing MAC learning information from the MAC local table storage unit 12. Then, the path calculation module 10 floods the OFCDD in which the MAC is set to MACSA to each OFC-OFS domain via the Inter-Domain BCMC Tree. When the OFC receives the OFCDD, the path calculation module 10 deletes the MACSA information set in the OFCDD from the MAC / destination domain table storage unit 11.
  • the route calculation module 10 performs a Unicast transfer and load distribution by calculating a Unicast route after the topology discovery is completed. Therefore, even when a physical loop exists between a plurality of connected OFC domains, communication can be performed using an optimal route without looping communication.
  • each OFC constructs a BCMC Tree inside its own domain using an existing method.
  • the link between OFS3 and OFS4 is blocked in the OFC1 domain 110 (hereinafter referred to as OFC1-OFS1 domain), and OFS2 in the OFC2 domain 120 (hereinafter referred to as OFC2-OFS1 domain).
  • OFC1-OFS1 domain the link between OFS4 is blocked and the link between OFS3 and OFS4 is blocked in OFC3 domain 130 (hereinafter referred to as OFC3-OFS1 domain).
  • OFS1-Port1, OFS2-Port1, OFS3-Port1, and OFS4-Port1 in the OFC1-OFS1 domain are recognized by OFC1 as outward ports.
  • OFS1-Port1 and OFS3-Port1 in the OFC2-OFS1 domain are recognized by OFC2 as outgoing ports. Further, OFS1-Port1 and OFS2-Port1 in the OFC3-OFS1 domain are recognized by OFC3 as outward ports.
  • the internal domain topology management module 22 of each OFC floods the OFNAD to the outward ports that are under its control.
  • the OFNAD transmitted by the OFC 1 includes information exemplified below.
  • -For OFS1-Port1 Type NAD, Original Node: ⁇ OFC1 domain, OFS1 domain, OFS1, Port1, LinkCost1 ⁇ -For OFS2-Por1, Type: NAD, Original Node: ⁇ OFC1 domain, OFS1 domain, OFS2, Port1, LinkCost1 ⁇ -For OFS3-Por1, Type: NAD, Original Node: ⁇ OFC1 domain, OFS1 domain, OFS3, Port1, LinkCost1 ⁇ -For OFS4-Por1, Type: NAD, Original Node: ⁇ OFC1 domain, OFS1 domain, OFS4, Port1, LinkCost2 ⁇
  • OFCND (NAD) transmitted from OFC1 reaches PC211, PC212, OFC2-OFS1 domain, and OFC3-OFS1 domain. Since the PCs 211 and 212 are terminals, no reply is made to the ONCND (NAD) packet.
  • the OFCND (NAD) that has reached the OFC2-OFS1 domain and the OFC3-OFS1 domain coincides with the OFCND packet inflow, and is Packeted-In to OFC2 and OFC3, respectively.
  • the inter-domain topology management module 21 of OFC2 and OFS3 returns an OFCND (NRS) packet.
  • the OFCND (NRS) packet transmitted by the OFC2 and OFC3 includes the following information.
  • OFC2 is for OFS1-Port1 Type: NRS, Original Node: ⁇ OFC1 domain, OFS1 domain, OFS2, Port1, LinkCost1 ⁇ , Neighbor Node: ⁇ OFC2 domain, OFS1 domain, OFS1, Port1, LinkCost1 ⁇ -OFC3 is relative to OFS1-Port1 Type: NRS, Original Node: ⁇ OFC1 domain, OFS1 domain, OFS4, Port1, LinkCost2 ⁇ , Neighbor Node: ⁇ OFC3 domain, OFS1 domain, OFS1, Port1, LinkCost1 ⁇
  • OFCND (NRS) transmitted from OFC2 and OFC3 reaches the OFC1-OFS1 domain, matches the OFCND packet flow, and is Packeted-In to OFC1.
  • the inter-domain topology management module 21 of OFC 1 recognizes OFS 2 -Port 1 and OFS 4 -Port 1 as neighbor outgoing ports and records the following information in the inter-domain topology information storage unit 13.
  • OFSND NRS
  • OFS3-Port1 OFS3-Port1. Therefore, the inter-domain topology management module 21 of the OFC 1 recognizes these two ports as no-neighboring outward ports, and permits packet_in and packet transfer of OFS1-Port1 and OFS3-Port1 according to an existing method.
  • the other OFC 2 and OFC 3 also perform the neighbor discovery process.
  • the information detected by the OFC 2 has the following contents.
  • the information detected by the OFC 3 has the following contents.
  • Each OFC performs an operation similar to the STP described in the above embodiment by transmitting and receiving OFCDU and prevents a loop between OFC domains. Since the algorithm for preventing the loop is the same as the processing based on STP, detailed description is omitted here.
  • the OFC1-OFS1 domain with the smallest OFC domain ID is selected as the Root Domain.
  • OFS3-Port1 of the OFC3-OFS1 domain is selected as a non-representative port.
  • the inter-domain topology management module 21 of each OFC permits Packet_In, packet transfer, and the like to an outbound port with a neighbor other than OFS2-Port1 in the OFC3-OFS1 domain.
  • the Inter-Domain BCMC Tree illustrated below is configured. Thereafter, communication between the OFC-OFS domains is performed via the Inter-Domain BCMC Tree.
  • Each OFC transmits OFCTDDU to all outgoing ports with neighbors.
  • OFCTDDU transmitted from OFC 1
  • the inter-domain topology management module 21 of OFC1 transmits OFCTDDU including the following information to OFS2-Port1 and OFS4-Port1, respectively.
  • Node ID 0 for OFS2-Port1 ⁇ OFC1 domain, OFS1 domain, Linkcost1 ⁇
  • Node ID 0 for OFS4-Port1 ⁇ OFC1 domain, OFS1 domain, Linkcost2 ⁇
  • the OFCTDDU that has reached the OFC2-OFS1 domain matches the OCTDDU packet inflow and is Packeted-In to OFC2.
  • the inter-domain topology management module 21 of OFC 2 learns the topology information included in the OFCTDDU.
  • the OFC2 inter-domain topology management module 21 determines that the information of the OFC-OFS domain (OFC2-OFS1 domain) that received the OFCTDDU is not included in the Node label of the OFCTDDU. Therefore, the inter-domain topology management module 21 increments the last Node ID in the received OFCTDDU, and stores the information of the OFC2-OFS1 domain that has received the OFCTDDU in a Node label having a new Node ID.
  • the OFC2 inter-domain topology management module 21 floods the newly created OFCTDDU to an outgoing port with a neighbor other than the receiving port (OFS3-Port1 existing in the OFC2-OFS1 domain).
  • OFCTDDU transmitted by OFC1 is transferred via OFC2 and includes information exemplified below.
  • the inter-domain topology management module 21 of the OFC 3 learns topology information from the received OFCTDDU packet.
  • the inter-domain topology management module 21 of the OFC 3 creates a new OFCTDDU based on the received OFCTDDU and floods it to OFS2-Port1.
  • OFCTDDU transmitted by OFC1 is transferred via OFC3 and includes information exemplified below.
  • OFCTDDU transmitted from OFC1 is transferred from OFC2 and reaches OFC3.
  • the inter-domain topology management module 21 of the OFC 3 learns topology information from the received OFCTDDU packet.
  • the inter-domain topology management module 21 of the OFC 3 determines that the information of the received OFC-OFS domain that received the OFCTDDU is not included in the Node label of the OFCTDDU. Therefore, the inter-domain topology management module 21 creates a new OFCTDDU and floods it to OFS1-Port1.
  • the newly created OFCTDDU includes information exemplified below.
  • OFCTDDU transmitted from OFC1 is transferred from OFC2 and reaches OFC2.
  • the inter-domain topology management module 21 of the OFC 2 learns topology information from the received OFCTDDU packet.
  • the OFC2 inter-domain topology management module 21 determines that the information of the received OFC-OFS domain that received the OFCTDDU is not included in the Node label of the OCCTDDU. Therefore, the inter-domain topology management module 21 creates a new OFCTDDU and floods it to OFS1-Port1.
  • the newly created OFCTDDU includes information exemplified below.
  • OFC1 receives OFCTDDU from OFC1 through OFC2 and further through OFC3, and OFCTDDU from OFC1 through OFC3 and further through OFC2.
  • the OFC1 inter-domain topology management module 21 determines that its OFC-OFS domain (OFC1-OFS1 domain) is included in the Node label of OFCTDDU. Therefore, the inter-domain topology management module 21 learns the topology information included in the OFCTDDU and discards the OCTDDU packet.
  • OFC2 and OFC3 issue OFCDDDDU themselves and perform topology discovery processing.
  • OFC1, OFC2, and OFC3 hold the following topology information.
  • the OFC1-OFS1 domain and the OFC2-OFS1 domain are connected by Linkcost1.
  • the OFC1-OFS1 domain and the OFC3-OFS1 domain are connected by Linkcost2.
  • -The OFC2-OFS1 domain and the OFC3-OFS1 domain are connected by Linkcost1.
  • the PC 211 transmits an ARP Request.
  • the APR Request reaches the OFC1-OFS1 domain and is Packeted-In to OFC1.
  • the OFC1 path calculation module 10 floods the ARP Request to OFS3-Port1, and registers the MAC ARP of the ARP Request and the learning position (OFS1-Port1 of the OFS1 domain) in the MAC local table.
  • the OFC1 path calculation module 10 rewrites ARP Request to OFCDA. Specifically, the path calculation module 10 includes the OFC1-OFS1 domain ID that received the ARP Request in the OFCDA, and floods the OFCDA to the outgoing port with a neighbor in the Inter-Domain BCMC Tree.
  • OFC2 and OFC3 receive OFCDA including MAC of PC211 issued from OFC1 as MACSA by Packet_In.
  • the OFC2 path calculation module 10 extracts the MACSA of the PC 211 and the OFC1-OFS1 domain ID which is the MAC transmission source domain from the received OFCDA, and registers them in the MAC / destination domain table storage unit 11.
  • the path calculation module 10 of the OFC 3 extracts the MACSA of the PC 211 and the OFC1-OFS1 domain ID that is the transmission source domain of the MAC, and registers them in the MAC / destination domain table storage unit 11. Also, the OFC3 path calculation module 10 rewrites OFCDA to ARP Request and floods it to OFS4-Port1 and OFS3-Port1.
  • the path calculation module 10 of the OFC 1 searches the MAC local table storage unit 12 using the MACDA (PC 231) of the Unicast packet received by Packet_In.
  • the path calculation module 10 of the OFC 1 searches the MAC / destination domain table storage unit 11 using the PC 231. As a result, the OFC1 path calculation module 10 knows that the PC 231 exists in the OFC3-OFS1 domain.
  • the OFC1 path calculation module 10 searches for the lowest cost path on the topology, starting from the OFC-OFS domain (OFC1-OFS1 domain) that received the Unicast packet-in and starting from the OFC3-OFS1 domain in which the PC 231 exists.
  • the OFC 1 path calculation module 10 calculates the minimum cost path exemplified below.
  • Linkcost 2 from the OFC1-OFS1 domain to the OFC3-OFS1 domain via the OFC2-OFS1 domain
  • Linkcost from the OFC1-OFS1 domain to the OFC3-OFS1 domain 2
  • the OFC 1 path calculation module 10 selects an arbitrary path according to a general OFC load distribution algorithm. Here, it is assumed that the route (1) is selected.
  • the OFC1 path calculation module 10 refers to the inter-domain topology information storage unit 13 and acquires the OFS ID and Port ID for transfer to the OFC2-OFS1 domain. Then, the OFC1 path calculation module 10 controls to transfer the Unicast packet addressed to the PC 231 from the PC 211 to the OFC2-OFS1 domain.
  • Unicast packet addressed to PC 231 from PC 211 is transferred from OFC1-OFS1 domain to OFC2-OFS1 domain.
  • OFC2 receives the Unicast packet with Packet_In.
  • the OFC 2 path calculation module 10 searches the MAC local table storage unit 12 and the MAC / destination domain table storage unit 11 for MACDA (PC 231). In this example, the OFC2 path calculation module 10 knows that the PC 231 exists in the OFC3-OFS1 domain.
  • the OFC2 path calculation module 10 searches the lowest cost path on the topology starting from the OFC-OFS domain (OFC2-OFS1 domain) that received the Unicast packet-in and the OFC3-OFS1 domain where the PC 231 exists as the end point.
  • the OFC 2 path calculation module 10 calculates the minimum cost path exemplified below.
  • the OFC2 path calculation module 10 refers to the inter-domain topology information storage unit 13 and obtains the OFS ID and Port ID for transfer to the OFC3-OFS1 domain. Then, the OFC 2 path calculation module 10 controls to transfer the Unicast packet addressed to the PC 231 from the PC 211 to the OFC3-OFS1 domain.
  • the OFC 3 path calculation module 10 searches the MAC local table storage unit 12 for MACDA (PC 231). Then, the route calculation module 10 knows that the PC 231 is connected to the OFS4-Port1 in the subordinate domain to be managed. Therefore, the OFC 3 path calculation module 10 controls to transfer the Unicast packet addressed to the PC 231 from the PC 211 to OFS 4 -Port 1.
  • the Unicast packet is transferred from the PC 211 to the PC 231 via the domains in the order of OFC1-OFS1 domain, OFC2-OFS1 domain, OFC3-OFS1 domain.
  • the path calculation module 10 of each OFC may perform processing in consideration of traffic load distribution.
  • the route calculation module 10 may perform load distribution processing using, for example, a round robin algorithm. In this case, for the communication from the PC 211 to the PC 231, the path calculation module 10 may calculate a path that reaches the OFC3-OFS1 domain from the OFC1-OFS1 domain via the OFC2-OFS1 domain. Further, the path calculation module 10 may calculate a path from the OFC1-OFS1 domain to the OFC3-OFS1 domain for communication from the PC 221 to the PC 232.
  • the inter-domain topology management module 21 specifies an OFC domain adjacent to the own OFC domain.
  • the inter-domain topology management module 21 creates a communication tree that avoids a loop configuration existing in a communication path between adjacent OFC domains, and specifies a network topology between the OFC domains.
  • the route calculation module 10 calculates the optimum route based on the above-described communication tree using the identified network topology, and controls communication from the communication devices connected to each OFS.
  • the communication control system of the present embodiment can be realized using the standard OpenFlow protocol without affecting the existing OFC processing method.
  • a loop between OpenFlow networks controlled by a plurality of independently operated OFCs can be prevented, so that a redundant configuration between OpenFlow networks can be formed.
  • route calculation can be performed using an optimal link cost, so that the utilization rate of the network bandwidth can be increased. Therefore, it is possible to reduce the probability of band compression caused by erroneous determination of the dark fiber link cost.
  • Embodiment 2 a second embodiment of the present invention will be described.
  • the OFC calculates the domain topology of the entire system based on information on adjacent domains, and further calculates the SPT between domains.
  • a topology manager having IP reachability with all OFCs in the system is prepared, and the topology manager performs these processes and notifies the process results to each OFC.
  • the method described in the first embodiment can be called a completely autonomous method. Further, the method described in this embodiment can be called a hybrid method because the OFC and the topology manager perform communication control in cooperation.
  • FIG. 8 is an explanatory diagram showing a configuration example of the second embodiment of the communication control system according to the present invention.
  • symbol same as FIG. 1 is attached
  • subjected and description is abbreviate
  • the communication control system illustrated in FIG. 8 includes a topology manager 140 in addition to the communication control system of the first embodiment.
  • the topology manager 140 includes a control unit 141.
  • the control unit 141 is realized by a CPU of a computer that operates according to a program (interdomain topology management program).
  • the program may be stored in a storage unit (not shown) of the topology manager 140, and the CPU may read the program and operate as the control unit 141 according to the program.
  • the inter-domain topology management module 21 of each OFC transmits information indicating an adjacent domain to the topology manager 140.
  • the control unit 141 calculates a topology between the OFC domains based on the received information, and further avoids a loop configuration between the OFC domains. (Eg, spanning tree) is calculated. Then, the control unit 141 distributes the calculated communication tree to each OFC.
  • the control unit 141 may calculate the topology between the OFC domains using a method similar to the method performed by the interdomain topology management module 21 in the first embodiment, and performs communication that avoids a loop configuration between the OFC domains.
  • a tree may be calculated.
  • the inter-domain topology management module 21 determines that the communication tree received from the topology manager 140 is a communication path between domains, and constructs a spanning tree between domains, for example. Thereafter, the route calculation module 10 performs processing at the Unicast route calculation stage.
  • the method for calculating the Unicast route by the route calculation module 10 is the same as in the first embodiment.
  • the loop discovery stage process and the topology discovery stage process in the fully autonomous system are performed by the topology manager 140 instead of the OFC.
  • the control unit 141 of the topology manager 140 identifies the topology between the OFC domains based on the adjacent domain information received from the OFC, and the adjacent OFC Create a communication tree that avoids the loop configuration that exists in the communication path between domains. Then, the control unit 141 distributes the created communication tree to each OFC.
  • a fully autonomous method and a hybrid method there are a fully autonomous method and a hybrid method, and it is possible to flexibly cope with different environments.
  • the fully autonomous system for example, loop prevention and load distribution can be realized without using other devices.
  • the network bandwidth and load occupied by OFCDU and OFCTDDU can be reduced by using a topology manager that centrally manages the topology between OFC domains.
  • FIG. 9 is a block diagram showing an outline of a communication control system according to the present invention.
  • the communication control system according to the present invention includes a controller domain (for example, OFC domain) indicating a range in which at least one open flow switch (for example, OFS1 to OFS4) is managed by each open flow controller (for example, OFC1 to OFC3).
  • a controller domain for example, OFC domain
  • OFS1 to OFS4 open flow controller
  • OFC1 to OFC3 OFC1 to OFC3
  • an adjacent domain specifying means 81 for example, an inter-domain topology management module 21
  • a loop solving means 82 for example, an inter-domain topology management module 21
  • a topology specifying means 83 for example, an inter-domain topology management module 21
  • communication control means 84 for example, route calculation module 10 for controlling communication from a communication device (for example, PC 211 etc.) connected to.
  • the adjacent domain specifying unit 81 transmits an adjacency confirmation packet (for example, OFCNAD) for confirming the adjoining domain from the outward port of the own controller domain, and when receiving the adjacency confirmation packet, the controller that transmitted the adjacency confirmation packet.
  • An adjacent response packet (for example, OFCNRS) may be returned to the domain, and the adjacent response packet may be received to identify the adjacent controller domain.
  • the loop solving means 82 may create a communication tree that avoids a loop configuration existing in a communication path between adjacent controller domains based on a spanning tree algorithm.
  • the loop solving unit 82 sets a flow entry that prohibits packet transfer for a port (for example, a non-representative port) in a communication path between adjacent controller domains, thereby avoiding a loop configuration. May be created.
  • the communication control unit 84 may calculate a plurality of routes and perform control (for example, ECMP load balancing) for distributing the load from the communication device connected to each OpenFlow switch to the plurality of routes. Good.
  • FIG. 10 is a block diagram showing another outline of the communication control system according to the present invention.
  • Another communication control system according to the present invention includes a controller domain (eg, OFC) indicating a range in which at least one open flow switch (eg, OFS1 to OFS4) is managed by each open flow controller (eg, OFC1 to OFC3).
  • a communication control system that controls communication between controller domains in a network in which domains are connected to each other, and communication from a plurality of OpenFlow controllers 80 (for example, OFC1 to OFC3) and OpenFlow controllers arrives.
  • a topology manager 90 for example, topology manager 140
  • the OpenFlow controller 80 includes adjacent domain specifying means 81 (for example, the inter-domain topology management module 21 in the second embodiment) that specifies a controller domain adjacent to its own controller domain, and information indicating the specified adjacent controller domain.
  • the adjacent domain information transmitting means 85 (for example, the inter-domain topology management module 21 in the second embodiment) for transmitting to the topology manager, and calculating the optimum route based on the network topology calculated by the topology manager, each OpenFlow switch Communication control means 86 (for example, route calculation module 10) for controlling communication from a communication device connected to the communication device.
  • the topology manager 90 identifies the network topology between the controller domains based on the information received from the OpenFlow controller 80, and creates a communication tree that avoids a loop configuration existing in the communication path between adjacent controller domains.
  • Communication tree creation means 91 for example, control unit 141
  • network topology distribution means 92 for example, control unit 141 for distributing the created communication tree to the OpenFlow controller.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

　隣接ドメイン特定手段８１は、自コントローラドメインに隣接するコントローラドメインを特定する。ループ解決手段８２は、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する。トポロジ特定手段８３は、各コントローラドメイン間のネットワークトポロジを特定する。通信制御手段８４は、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する。

Description

通信制御システム、通信制御方法および通信制御プログラム
　本発明は、複数の通信装置を管理するコントローラ間の通信制御を行う通信制御システム、通信制御方法および通信制御プログラムに関する。
　複数の通信機器を一つの制御装置で集中管理する技術として、オープンフローが広く知られている。オープンフローでは、１台以上のオープンフロースイッチ（Open Flow Switch。以下、ＯＦＳと記す。）を、オープンフローコントローラ（Open Flow Controller。以下、ＯＦＣと記す。）が制御する。また、近年、ＯＦＣが制御可能なＯＦＳの台数や、ＯＦＳの設置場所などの関係で、オープンフローを用いたネットワークを、複数のＯＦＣで管理する要求が高まっている。
　特許文献１には、独自に負荷分散機能を持たないスイッチとコントローラの組合せや、メーカの違いにより負荷分散機能に互換性がないスイッチとコントローラの組合せにおいても、コントローラの負荷分散を可能にする負荷分散システムが記載されている。特許文献１に記載された負荷分散システムでは、スイッチとコントローラの間にプロキシが設置され、そのプロキシが、１つのスイッチからの接続を複数のコントローラに通知しつつ、そのスイッチに対してマスタとなる１つのコントローラを決定し、そのスイッチからの問合せメッセージを、マスタとなる１つのコントローラのみに転送する。
再特ＷＯ２０１１－０６５２６８号公報
　一般にＯＦＣは、他のＯＦＣが管理するＯＦＳ群との繋がりを意識せず、自身が管理している配下のトポロジを検出する。以下、ＯＦＣが管理するＯＦＳ群のことを、ＯＦＣドメインと記す。すなわち、ＯＦＣは、ＯＦＣごとに検出された自ＯＦＣドメインのトポロジをベースとして、ＢＣＭＣ（Ｂｒｏａｄｃａｓｔ　ａｎｄ　Ｍｕｌｔｉｃａｓｔ）、Ｕｎｋｏｎｗｎ　ｕｎｉｃａｓｔ、Ｕｎｉｃａｓｔ転送をＯｐｅｎＦｌｏｗプロトコルで制御する。しかし、ＯＦＣが自ＯＦＣドメインのトポロジのみを検出して制御を行う場合、以下の課題が発生する。
　図１１は、２つのＯＦＣドメイン間を複数の回線で接続した場合の例を示す説明図である。図１１に示す例では、ＯＦＣ１ドメイン１１０と、ＯＦＣ２ドメイン１２０が、２本の回線Ｃ４１および回線Ｃ４２で接続されている。ＯＦＣ１ドメイン１１０は、ＯＦＣ１によって管理されるドメインであり、ＯＦＣ２ドメイン１２０は、ＯＦＣ２によって管理されるドメインである。
　ＯＦＣ１ドメイン１１０は、４つのＯＦＳ（ＯＦＳ１～４）を含む。ＯＦＣ１ドメイン１１０において、ＯＦＳ１とＯＦＳ２は、回線Ｃ１１で接続され、ＯＦＳ１とＯＦＳ３は、回線Ｃ１２で接続され、ＯＦＳ２とＯＦＳ４は、回線Ｃ１３で接続され、ＯＦＳ３とＯＦＳ４は、回線Ｃ１４で接続される。また、クライアントＰＣ（Personal Computer ）２１０が、ＯＦＣ１ドメイン１１０のＯＦＳ１に接続されている。
　ＯＦＣ２ドメイン１２０も同様に、４つのＯＦＳ（ＯＦＳ１～４）を含む。ＯＦＣ２ドメイン１２０において、ＯＦＳ１とＯＦＳ２は、回線Ｃ２１で接続され、ＯＦＳ１とＯＦＳ３は、回線Ｃ２２で接続され、ＯＦＳ２とＯＦＳ４は、回線Ｃ２３で接続され、ＯＦＳ３とＯＦＳ４は、回線Ｃ２４で接続される。
　ＯＦＣ１は、ＯＦＣ１ドメイン１１０のトポロジを検出（ディスカバリ）し、ＯＦＣ２は、ＯＦＣ２ドメイン１２０のトポロジを検出（ディスカバリ）する。さらに、ＯＦＣ１は、自ドメイン内の回線Ｃ１４を遮断（ブロック）し、また、ＯＦＣ２は、自ドメイン内の回線Ｃ２３を遮断（ブロック）するように、論理スパニングツリーを構築している。
　図１１に例示する環境の場合、ＰＣ２１０からＢＣＭＣパケットが送信されても、ＢＣＭＣパケットは、各ＯＦＳドメイン内でループされなくなる。
　しかし、回線Ｃ４１、回線Ｃ２２、回線Ｃ４２および回線Ｃ１３は、遮断されていないため、ＯＦＣドメインを跨いだこれらの回線では、ループが発生する。そのため、図１１に例示するシステム全体で、ＢＣＭＣストームが発生してしまう。
　このような課題を解決する方法として、ＭＣＬＡＧ（Ｍｕｌｔｉ－Ｃｈａｓｓｉｓ　Ｌｉｎｋ　Ａｇｇｒｅｇａｔｉｏｎ　Ｇｒｏｕｐ）という技術が知られている。この技術を用いた場合、回線Ｃ４１と回線Ｃ４２を論理的に一本のリンクとして扱うことができるため、図１１に例示するループの発生を回避することは可能である。
　しかし、ＭＣＬＡＧ技術を用いた場合であっても、３つ以上のＯＦＣドメインが接続されたネットワークでループを回避することは困難である。図１２は、３つのＯＦＣドメインが接続された場合の例を示す説明図である。
　図１２に示す例では、ＯＦＣ１ドメイン１１０と、ＯＦＣ２ドメイン１２０に加えて、さらに、ＯＦＣ３ドメイン１３０が存在する。ＯＦＣ３ドメイン１３０は、ＯＦＣ３によって管理されるドメインである。ＯＦＣ１ドメイン１１０とＯＦＣ３ドメイン１３０は、回線Ｃ４３で接続され、ＯＦＣ２ドメイン１２０とＯＦＣ３ドメイン１３０は、回線Ｃ４４で接続される。
　ＯＦＣ３ドメイン１３０も、４つのＯＦＳ（ＯＦＳ１～４）を含む。ＯＦＳ１とＯＦＳ２は、回線Ｃ３１で接続され、ＯＦＳ１とＯＦＳ３は、回線Ｃ３２で接続され、ＯＦＳ２とＯＦＳ４は、回線Ｃ３３で接続され、ＯＦＳ３とＯＦＳ４は、回線Ｃ３４で接続される。さらに、図１２に示す例では、ＯＦＣ１ドメイン１１０とＯＦＣ２ドメイン１２０は、回線Ｃ４１および回線Ｃ４２を用いて作成されるＭＣＬＡＧで接続される。
　この場合、ＰＣ１から送信されるＢＣＭＣパケットは、回線Ｃ４１および回線Ｃ４２を用いて作成されるＭＣＬＡＧ、回線Ｃ４３および回線Ｃ４４のリンクを経由することにより、ＯＦＣ１ドメイン１１０、ＯＦＣ２ドメイン１２０およびＯＦＣ３ドメイン１３０の間でループになる。そのため、図１２に例示するシステム全体で、ＢＣＭＣストームが発生してしまう。
　このように、一般的な通信ネットワークでは、複数のＯＦＣドメイン間の接続を冗長構成にすることは困難である。そのため、全ＯＦＣドメイン間の繋がりを配慮し、ループ構成を排除するようなトポロジを構築することが望まれる。
　また、特許文献１に記載された負荷分散システムでは、このような状況を想定していない。そのため、複数のＯＦＣを利用したオープンフローのネットワーク環境であっても、ＯＦＣドメインを跨いだ通信を複数の経路に負荷分散させたり、最適な経路を算出したりすることが望まれている。
　そこで、本発明は、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる通信制御システム、通信制御方法および通信制御プログラムを提供することを目的とする。
　本発明による通信制御システムは、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決手段と、各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定手段と、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを備えたことを特徴とする。
　本発明による他の通信制御システムは、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、複数のオープンフローコントローラと、オープンフローコントローラからの通信が到達するように接続され、コントローラドメイン間の通信経路を示す通信ツリーを作成するトポロジマネージャとを備え、オープンフローコントローラが、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、特定した隣接するコントローラドメインを示す情報を、トポロジマネージャに送信する隣接ドメイン情報送信手段と、トポロジマネージャが算出したネットワークトポロジに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを含み、トポロジマネージャが、オープンフローコントローラから受信した情報に基づいて、各コントローラドメイン間のネットワークトポロジを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する通信ツリー作成手段と、作成した通信ツリーをオープンフローコントローラに配信するネットワークトポロジ配信手段とを含むことを特徴とする。
　本発明による通信制御方法は、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御方法であって、自コントローラドメインに隣接するコントローラドメインを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成し、各コントローラドメイン間のネットワークトポロジを特定し、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御することを特徴とする。
　本発明による通信制御プログラムは、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御するコンピュータに適用される通信制御プログラムであって、コンピュータに、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定処理、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決処理、各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定処理、および、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御処理を実行させることを特徴とする。
　本発明によれば、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
本発明による通信制御システムの第１の実施形態の構成例を示すブロック図である。 本実施形態の通信制御システムで用いられるＯＦＣの構成例を示すブロック図である。 パケットのタイプがＮＡＤであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。 パケットのタイプがＮＲＳであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。 ＯＦＣが複数のＯＦＳ群を管理している状態を示す説明図である。 ＯＦＣＴＤＤＵパケットの例を示す説明図である。 ＯＦＳＤＡパケットとＯＦＳＤＤパケットの例を示す説明図である。 本発明による通信制御システムの第２の実施形態の構成例を示す説明図である。 本発明による通信制御システムの概要を示すブロック図である。 本発明による通信制御システムの他の概要を示すブロック図である。 ２つのＯＦＣドメイン間を複数の回線で接続した場合の例を示す説明図である。 ３つのＯＦＣドメインが接続された場合の例を示す説明図である。
　以下、本発明の実施形態を図面を参照して説明する。
実施形態１．
　図１は、本発明による通信制御システムの第１の実施形態の構成例を示す説明図である。また、図２は、本実施形態の通信制御システムで用いられるＯＦＣの構成例を示すブロック図である。以下の説明では、通信ネットワーク内には、３つのＯＦＣドメイン（ＯＦＣドメイン１１０，１２０，１３０）と各ＯＦＣドメインにおけるＯＦＣに管理されるそれぞれ４台のＯＦＳが含まれるものとする。すなわち、以下で説明する環境は、３台のＯＦＣを含むマルチコントローラ環境である。
　ただし、通信制御システムに含まれるＯＦＣドメインの数は３つに限定されず、４つ以上であってもよい。また、各ＯＦＣドメインに含まれるＯＦＳの数は４つに限定されず、１～３つであってもよく、５つ以上であってもよい。
　また、図１に例示する通信制御システムにおいて、ＰＣ２１１は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ１のｐｏｒｔ１にｃｏｓｔ＝１で接続され、ＰＣ２１２は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ３のｐｏｒｔ１にｃｏｓｔ＝１で接続される。また、ＰＣ２３１は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ４のｐｏｒｔ１にｃｏｓｔ＝１で接続され、ＰＣ２３２は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ３のｐｏｒｔ１にｃｏｓｔ＝１で接続される。
　さらに、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ２のｐｏｒｔ１は、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ１のｐｏｒｔ１とｃｏｓｔ＝１で接続され、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ１のｐｏｒｔ１は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ２のｐｏｒｔ１とｃｏｓｔ＝１で接続される。また、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ４のｐｏｒｔ１は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ１のｐｏｒｔ１とｃｏｓｔ＝２で接続され、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ１のｐｏｒｔ１は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ４のｐｏｒｔ１とｃｏｓｔ＝１で接続される。また、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ３のｐｏｒｔ１は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ２のｐｏｒｔ１とｃｏｓｔ＝１で接続され、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ２のｐｏｒｔ１は、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ３のｐｏｒｔ１とｃｏｓｔ＝１で接続される。
　図２は、本実施形態のＯＦＣの機能モジュール構成を示している。図２に例示するＯＦＣ１００は、ＯＦＣドメインを制御する。図２に例示するＯＦＣ１００は、図１に例示するＯＦＣ１、ＯＦＣ２およびＯＦＣ３に対応する。ＯＦＣ１００は、経路計算モジュール１０と、トポロジ管理モジュール２０と、メッセージ解析モジュール３０と、メッセージ送受信モジュール４０とを備えている。
　メッセージ送受信モジュール４０は、オープンフローメッセージを送受信するモジュールである。
　メッセージ解析モジュール３０は、メッセージ送受信モジュール４０から受信したオープンフローメッセージを解析し、上位モジュール（経路計算モジュール１０およびトポロジ管理モジュール２０）に通知する。また、メッセージ解析モジュール３０は、上位モジュール（経路計算モジュール１０およびトポロジ管理モジュール２０）から発行されたＯＦＳ制御メッセージをオープンフローメッセージに変換し、メッセージ送受信モジュール４０に通知する。
　トポロジ管理モジュール２０は、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２とを含む。
　トポロジ管理モジュール２０（より具体的には、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２）は、プログラム（通信制御プログラム）に従って動作するコンピュータのＣＰＵによって実現される。例えば、プログラムは、ＯＦＣ１００の記憶部（図示せず）に記憶され、ＣＰＵは、そのプログラムを読み込み、プログラムに従って、トポロジ管理モジュール２０（より具体的には、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２）として動作してもよい。
　また、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２とは、それぞれが専用のハードウェアで実現されていてもよい。また、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２がそれぞれ行う処理を、トポロジ管理モジュール２０がまとめて行ってもよい。
　内部ドメイントポロジ管理モジュール２２は、ＯＦＣドメイン内のトポロジの探索およびトポロジの維持を行う。ＯＦＣドメイン内のトポロジを検索する方法は、ＯＦＣの実装によって異なるが、内部ドメイントポロジ管理モジュール２２は、一般的に知られた方法を用いてトポロジの探索およびトポロジの維持を行えばよい。ここでは、ＯＦＣが管理するＯＦＣドメイン内のトポロジの探索方法および維持方法について、詳細な説明を省略する。
　ドメイン間トポロジ管理モジュール２１は、ＯＦＣドメイン間のトポロジの探索およびトポロジの維持を行う。また、ドメイン間トポロジ管理モジュール２１は、探索したトポロジの情報を経路計算モジュール１０に通知する。
　経路計算モジュール１０は、ＭＡＣ（Media Access Control）・宛先ドメインテーブル記憶部１１と、ＭＡＣローカルテーブル記憶部１２と、ドメイン間トポロジ情報記憶部１３とを含む。ＭＡＣ・宛先ドメインテーブル記憶部１１、ＭＡＣローカルテーブル記憶部１２およびドメイン間トポロジ情報記憶部１３は、例えばメモリや、磁気ディスク等により実現される。また、経路計算モジュール１０は、プログラム（通信制御プログラム）に従って動作するコンピュータのＣＰＵによって実現される。
　ドメイン間トポロジ情報記憶部１３は、ドメイン間トポロジ管理モジュール２１から通知されたシステム全体におけるＯＦＣドメイン間のトポロジ情報を保持する。
　ＭＡＣローカルテーブル記憶部１２は、自ＯＦＣドメイン内で学習したＭＡＣ情報を保持する。ＭＡＣ情報は、自ＯＦＣドメイン内のＯＦＳの移動や消滅、新規学習により更新される。なお、トポロジ管理モジュール２０は、ＭＡＣ情報が消滅したり、新規にＭＡＣ情報を学習した場合、ＯＦＣＳＤＡ（OFC Source Domain Advertise ）を他のＯＦＣドメインにフラディングする。
　ＭＡＣ・宛先ドメインテーブル記憶部１１は、他のＯＦＣドメインから収集した情報（例えば、ＯＦＣＳＤＡ）に基づいて生成されるＭＡＣ・宛先ドメインテーブルを記憶する。
　以下、ドメイン間トポロジ管理モジュール２１が行う処理を、具体的に説明する。
（１）ネーバーディスカバリ段階
　ドメイン間トポロジ管理モジュール２１は、自ＯＦＣドメインに隣接するＯＦＣドメインを特定し、他のＯＦＣドメインにおけるＯＦＣに通知する。ドメイン間トポロジ管理モジュール２１は、隣接するＯＦＣドメインを探索するため、ＯＦＣＮＤ（OFC Neighbor Discovery）パケットを使用する。
　ＯＦＣＮＤパケットのうち、自ＯＦＣドメインから他のＯＦＣドメインに対して送信されるパケットのタイプはＮＡＤ（Neighbor Advertise）で識別され、他のＯＦＣドメインから自ＯＦＣドメインに対して送信されるパケットのタイプはＮＲＳ（Neighbor Response）で識別される。以下の説明では、パケットのタイプがＮＡＤのＯＦＣＮＤパケットをＯＦＣＮＡＤパケットと記すことがあり、パケットのタイプがＮＲＳのＯＦＣＮＤパケットをＯＦＣＮＲＳパケットと記すことがある。
　図３は、パケットのタイプがＮＡＤであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。また、図４は、パケットのタイプがＮＲＳであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。
　ＯＦＣＮＤメッセージは、タイプを示すＴｙｐｅフィールドおよびノード（Ｎｏｄｅ）の種類を示すＮｏｄｅフィールドを含む。Ｎｏｄｅフィールドは、ＯＦＣ　Ｄｏｍａｉｎ　ＩＤ、ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ、ＯＦＳ　ＩＤ、ＯＦＳ　Ｐｏｒｔ　ＩＤおよびＰｏｒｔ　Ｌｉｎｋ　Ｃｏｓｔの各フィールドを含む。
　図３に示す例では、ＮｏｄｅフィールドにＯＮ（Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ）が設定されている。また、図３に例示するＯＦＣＮＤメッセージにおいて、ＯＦＣ　Ｄｏｍａｉｎ　ＩＤには、送信する自ドメインＩＤ、ＯＦＳ　Ｄｏｍａｉｎ　ＩＤには、送信するＯＦＳのドメインＩＤ、ＯＦＳ　ＩＤには、送信するＯＦＳのＩＤ、ＯＦＳ　Ｐｏｒｔ　ＩＤには、送信するＯＦＳのポートＩＤ、Ｐｏｒｔ　Ｌｉｎｋ　Ｃｏｓｔには、送信するポートのリンクコストを示す情報がそれぞれ設定されている。
　図４に示す例では、ＯＮが設定されたＮｏｄｅフィールド以外に、ＮＮ（Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ）が設定されたＮｏｄｅフィールドが存在する。図４に例示するＯＦＣＮＤメッセージにおいて、図３に例示するＮｏｄｅフィールドのＮｏｄｅＩＤがＮＮに設定されている。
　また、ＯＮが設定されたＮｏｄｅフィールドにおいて、ＯＦＣ　Ｄｏｍａｉｎ　ＩＤには、ＮＡＤを受信した隣接ＯＦＣドメインＩＤ、ＯＦＳ　Ｄｏｍａｉｎ　ＩＤには、ＮＡＤを受信した隣接ＯＦＳのドメインＩＤ、ＯＦＳ　ＩＤには、ＮＡＤを受信した隣接ＯＦＳのＩＤ、ＯＦＳ　Ｐｏｒｔ　ＩＤには、ＮＡＤを受信した隣接ＯＦＳのポートＩＤ、Ｐｏｒｔ　Ｌｉｎｋ　Ｃｏｓｔには、ＮＡＤを受信した隣接ポートのリンクコストを示す情報がそれぞれ設定されている。
　なお、ＮｏｄｅフィールドのＯＦＳ　Ｄｏｍａｉｎ　ＩＤは、１つのＯＦＣが複数の隔離したアイランド状態のＯＦＳ群を管理する場合において、それぞれのＯＦＳ群を識別するためのフィールドである。図５は、ＯＦＣが複数のＯＦＳ群を管理している状態を示す説明図である。図５に示す例では、ＯＦＣ１が、２つのＯＦＳドメインをそれぞれ管理していることを示す。このように、各ＯＦＣが、複数の隔離された（アイランド状態）のＯＦＳ群を管理していてもよい。
　ＯＦＳ　Ｄｏｍａｉｎ　ＩＤは、ＯＦＣドメイン内でユニークなＩＤが割り振られ、ＯＦＣによって管理される。
　なお、ＯＦＣ　Ｄｏｍａｉｎ　ＩＤも、通信制御システム内でユニークなＩＤが割り振られる。ＯＦＣ　Ｄｏｍａｉｎ　ＩＤを割り振る方法は任意である。例えば、ＯＦＣ　Ｄｏｍａｉｎ　ＩＤを各ＯＦＣに手動で設定してもよいし、ＯＦＣ間で自動的に割り振るようにしてもよいし、集中管理機能を持つ他の装置によって自動的に割り振られるようにしてもよい。
　ＯＦＣＮＤパケットのフレームは、以下の条件を満たせば、その他のフォーマット等については、特に限定されない。
・ＭＡＣＳＡ（ＭＡＣ　Ｓｏｕｒｃｅ　Ａｄｄｒｅｓｓ）
　ＯＦＣ　ＯｐｅｎＦｌｏｗ　Ｃｈａｎｎｅｌとして利用するＮＩＣ（Network Interface Card）のＭＡＣ
　なお、クラスタ構成の場合、共有の仮想ＭＡＣ
・ＭＡＣＤＡ（ＭＡＣ　Ｄｅｓｔｉｎａｔｉｏｎ　Ａｄｄｒｅｓｓ）
　パケットのタイプがＮＡＤの場合、ＢＣ／ＭＣ
　パケットのタイプがＮＲＳの場合、受信ＮＡＤのＭＡＣＳＡ
　レガシースイッチの透過性があるＭＡＣＤＡ
・Ｅｔｈｅｒ　Ｔｙｐｅ
　レガシースイッチの透過性があるＥｔｈｅｒ　Ｔｙｐｅ
　各ＯＦＣがＯＦＣＮＡＤパケットを他のＯＦＣドメインに送信し、ＯＦＣＮＡＤを受信したＯＦＣがＯＦＣＮＡＤを送信したＯＦＣドメインに対してＯＦＣＮＲＳを回答することで、隣接するＯＦＣドメインの特定（ネーバーディスカバリ）を行う。
　具体的には、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＡＤパケットを他のＯＦＣドメインに送信する。また、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＡＤを受信すると、ＯＦＣＮＡＤを送信したＯＦＣドメインに対してＯＦＣＮＲＳを回答する。
　ドメイン間トポロジ管理モジュール２１は、送信したＯＦＣＮＡＤパケットに対して、正しいＯＦＣＮＲＳパケットを受信した場合、ＯＦＣＮＡＤパケットを送信したポートをネーバーあり外向きポート（隣接するＯＦＣドメインが存在するポート）として記録する。
　次に、隣接するＯＦＣドメインの特定処理（ネーバーディスカバリ処理）について具体的に説明する。以下、ＯＦＣが管理するドメインをＯＦＣ－ＯＦＳドメインと記す。なお、本実施形態の説明では、ＯＦＣが管理するＯＦＳドメインは１つであるが、ＯＦＳドメインが２つ以上に場合についても同様である。
　まず、内部ドメイントポロジ管理モジュール２２は、自ＯＦＣ－ＯＦＳドメインのトポロジを検出して、物理ＢＣＭＣ配信ツリーおよび論理ＢＣＭＣ配信ツリーを構築する。なお、自ドメイン内のトポロジを検出する方法および配信ツリーを構築する方法は広く知られており、ここでは説明を省略する。
　初期状態において、外向きポートが外部ＯＦＣドメインとの接続している状況は不明であるため、外向きポート状態は接続不明であることを示す情報（例えば、０）に設定されている。そこで、内部ドメイントポロジ管理モジュール２２は、外向きポート状態が０に設定されている外向きポートからのＯＦＣＮＤ以外のパケットの送受信を禁止するように、フローエントリを設定する。
　なお、自ＯＦＣドメイン内のトポロジを検知する際にＯＦＣＮＤと異なるタイプのパケットが使用される場合、内部ドメイントポロジ管理モジュール２２は、そのパケットの送受信をＯＦＣＮＤと同様に許可する設定を行えばよい。
　内部ドメイントポロジ管理モジュール２２は、外向きポート状態をドメイン間トポロジ管理モジュール２１に通知する。
　ドメイン間トポロジ管理モジュール２１は、外向きポート状態が０の外向きポートに関して、以下の条件を満たすＯＦＣＮＤパケットをパケットインさせるフローエントリ（ＯＦＣＮＤパケットインフロー）を登録する。
・ＯＦＣＮＤパケットを受信した場合、ＯＦＣにＰａｃｋｅｔ＿Ｉｎさせる。
　内部ドメイントポロジ管理モジュール２２は、ＯＦＣＮＡＤパケットを全外向きポートにＰａｃｋｅｔ＿Ｏｕｔメッセージを用いて送信する。ＯＦＣＮＡＤパケットは、接続性がある外部ＯＦＣドメインに到達するため、ＯＦＣＮＤパケットインフローにマッチしてＯＦＣにＰａｃｋｅｔ＿Ｉｎされる。
　ドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＮＡＤにおけるＭＡＣＳＡ、ＯＮ　ＮｏｄｅにおけるＯＦＣ　Ｄｏｍａｉｎ　ＩＤおよびＯＦＳ　Ｄｏｍａｉｎ　ＩＤを、自ＭＡＣ、自ＯＦＣドメインＩＤおよびＯＦＣＮＡＤを受信したＯＦＳ　Ｄｏｍａｉｎ　ＩＤと比較する。
　すべての項目が一致した場合、ドメイン間トポロジ管理モジュール２１は、ＯＮ　ＮｏｄｅのＯＦＳ　Ｐｏｒｔ　ＩＤで識別されるポート、または、ＯＦＣＮＡＤを受信したＯＦＳのＰｏｒｔからのパケット転送を即時ブロックする。なお、どちらのポートをブロックするかは、ＯＦＣの実装に応じて定められればよい。
　ＯＦＣＮＡＤパケットを受信すると、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＲＳパケットを、ＯＦＣＮＡＤパケットの受信ポートに送信する。ＯＦＣＮＲＳパケットは、ＯＦＣＮＡＤを送信したＯＦＣドメインに到達するため、ＯＦＣＮＤパケットインフローにマッチし、ＯＦＣにＰａｃｋｅｔ＿Ｉｎされる。
　ドメイン間トポロジ管理モジュール２１は、自ＯＦＣドメインＩＤ、ＯＦＣＮＲＳを受信したＯＦＳドメインＩＤ、ＯＦＳ　ＩＤおよびＰＯＲＴ　ＩＤを、ＯＦＣＮＲＳにおけるＯＮ　Ｎｏｄｅの情報と比較する。すべての項目が一致しない場合、受信したパケットを廃棄する。
　一方、すべての項目が一致した場合、ドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＮＲＳのＯＮ　Ｎｏｄｅ情報およびＮＮ　Ｎｏｄｅ情報から、自管理配下のＯＦＣ－ＯＦＳドメインと、隣接するＯＦＣ－ＯＦＳドメインとが接続されていることを示す情報としてドメイン間トポロジ情報記憶部１３にネーバードメインＤＢを保持する。
　さらに、ドメイン間トポロジ管理モジュール２１は、外部ＯＦＣ－ＯＦＳドメインと接続しているポートを、隣接するドメインが存在する外向きポートと判定し、外向きポート状態を２に設定する。すなわち、外向きポート状態に２が設定された外向きポートは、ネーバーディスカバリが完了し、隣接するドメインが存在することを示す。
　事前に設定された一定の時間を経過し、タイムアウトが発生すると、ドメイン間トポロジ管理モジュール２１は、外向きポート状態に０が設定されている外向きポートについて、その外向きポート状態を１に設定する。すなわち、外向きポート状態に１が設定された外向きポートは、ネーバーディスカバリが完了し、隣接するドメインが存在しないことを示す。
　以後、ドメイン間トポロジ管理モジュール２１は、外向きポート状態に１が設定された外向きポートを、隣接ドメインが存在しない外向きポートと認識する。ドメイン間トポロジ管理モジュール２１は、ＯＦＣが外向きポートに対して行う一般的な処理（例えば、パケットインを許可する処理、ＯＦＣ内部のＢＣＭＣツリーの要素として行う処理、など）をその外向きポートに関して行う。
　ＯＦＣは、全外向きポートに対してＯＦＣＮＤを送受信することで、ネーバードメインＤＢを維持する。例えば、ＯＦＣＮＡＤに対する新たなＯＦＣＮＲＳを正しく受信した場合、ドメイン間トポロジ管理モジュール２１は、ネーバードメインＤＢを新しい情報で更新する。
　一方、ＯＦＣＮＡＤに対するＯＦＣＮＲＳを正しく受信できない場合、ドメイン間トポロジ管理モジュール２１は、一定のリトライ処理を行い、該当の情報をネーバードメインＤＢから削除するなどの動作を行う。
　なお、ここまでの処理において、隣接ドメインが存在する外向きポートでＯＦＣＮＤ以外のパケットを送受信する処理は、まだ禁止されている。
（２）ループディスカバリ段階
　ドメイン間トポロジ管理モジュール２１は、通信経路内にループが存在するか否か判断する。以下の説明では、通信経路内のループのことを、閉鎖グラフと記すこともある。本実施形態では、ドメイン間トポロジ管理モジュール２１は、ループが存在するか否か判断する際に、ＯＦＣＤＵ（ＯＦＣ　Ｄａｔａ　Ｕｎｉｔ）パケットを利用する。
　ＯＦＣＤＵは、ＳＴＰ（Spanning Tree Protocol）で用いられるＢＰＤＵ（Bridge Protocol Data Unit）パケットと同様のフォーマットである。ただし、ＢＰＤＵパケットがスイッチの情報の伝送に用いられるのに対し、本実施形態で用いられるＯＦＣＤＵパケットは、以下に例示する情報（具体的には、ＯＦＣ－ＯＦＳドメインの情報）の伝送に用いられる。
・Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ
・送信ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ
・Ｒｏｏｔ　Ｐａｔｈ　Ｃｏｓｔ（各ＯＦＣ－ＯＦＳドメインについて、ルートＯＦＣ－ＯＦＳドメインとのパスコスト）
　ドメイン間トポロジ管理モジュール２１は、ＳＴＰと同様のアルゴリズムを用いて、ＯＦＣＤＵに対する処理を行う。以下、ループを回避するための処理を説明する。
　ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する全外向きポートに関して、以下の条件を満たすＯＦＣＤＵパケットをパケットインさせるフローエントリ（ＯＦＣＤＵパケットインフロー）を登録する。
・ＯＦＣＤＵパケットを受信した場合、ＯＦＣにＰａｃｋｅｔ＿Ｉｎさせる。
　ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する全外向きポートからＯＦＣＤＵを送受信する。ＯＦＣ同士でＯＦＣＤＵを送受信することにより、ＯＦＣは、Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎを決定する。
　具体的には、ドメイン間トポロジ管理モジュール２１は、初めに、自身が管理するすべてのＯＦＣ－ＯＦＳ　ＤｏｍａｉｎがＲｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎであると認識し、そのＯＦＣ－ＯＦＳ　ＤｏｍａｉｎのＩＤをＯＦＣＤＵのＲｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤに設定する。そして、ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する各外向きポートにＯＦＣＤＵを送信する。
　各コントローラは、受信したＯＦＣＤＵのＲｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤを、自身が管理するＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤと比較する。自身が管理するＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤよりも、受信したＯＦＣＤＵのＲｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤが小さい場合、ドメイン間トポロジ管理モジュール２１は、自身がＲｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎではないと判断する。
　この処理を繰り返すことで、各閉鎖グラフ上に、唯一のＲｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎが特定される。以後、Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎと特定されたＯＦＣのみ、ＯＦＣＤＵを送信する。それ以外のＯＦＣは、ＯＦＣＤＵを受信し、Ｐａｔｈ　Ｃｏｓｔを加算して転送する。
　Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎにおいて隣接ドメインが存在する外向きポートは、代表ポートになる。また、他のＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎにおいて、Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎに一番近い（Ｒｏｏｔ　Ｐａｔｈ　Ｃｏｓｔ）ポートは、Ｒｏｏｔ　Ｐｏｒｔになる。
　また、他の異なるＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎに存在する隣り合うポートについて、Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎに近いＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎのポートは、代表ポートになり、遠いポートは非代表ポートになる。
　ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する代表ポートに関して、ＯＦＣがポートに対して行う一般的な処理（例えば、パケットインを許可する処理、ＯＦＣ内部のＢＣＭＣツリーの要素として行う処理、など）を行う。このような処理を行うことで、ＳＴＰで構築されるようなループ構成を回避する（単一経路）の通信ツリーが構築される。以下、このような通信ツリーを、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅと記すこともある。
　なお、上述の処理において、Ｒｏｏｔ　Ｐａｔｈ　Ｃｏｓｔが同一の場合、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＤＵにおける送信ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ、受信ＯＦＳ　ＩＤ、受信ＯＦＳ　ＰｏｒｔＩＤを順次比較すればよい。
　ドメイン間トポロジ管理モジュール２１は、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　ＴｒｅｅをＳＴＰで用いられる方法と同様の方法を用いて維持する。Ｒｏｏｔ　ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎのドメイン間トポロジ管理モジュール２１は、例えば、一定間隔で継続的にＯＦＣＤＵを送信してもよい。また、一定時間内にＯＦＣＤＵを受信できない場合、ドメイン間トポロジ管理モジュール２１は、自らＯＦＣＤＵを送信し、ループディスカバリ処理を再度行ってもよい。
　このように、ドメイン間トポロジ管理モジュール２１は、ＯＦＣドメイン間で通信経路がループする閉鎖グラフが存在する場合、その閉鎖グラフを対象としてＳＴＰで用いられるようなループ構成を回避する通信ツリーを計算する。その結果、構築された通信ツリーであるＩｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ経由で、ＯＦＣ－ＯＦＳドメイン間の通信が可能になる。
（３）トポロジディスカバリ段階
　ドメイン間トポロジ管理モジュール２１は、各ＯＦＣドメイン間のネットワークトポロジを特定する。本実施形態では、ドメイン間トポロジ管理モジュール２１は、ドメイン間のネットワークトポロジを判断する際に、ＯＦＣＴＤＤＵ（ＯＦＣ　Ｔｏｐｏｌｏｇｙ　Ｄｉｓｃｏｖｅｒｙ　Ｄａｔａ　Ｕｎｉｔ）パケットを利用する。
　図６は、ＯＦＣＴＤＤＵパケットの例を示す説明図である。図６に例示するＯＦＣＴＤＤＵパケットでは、Ｎｏｄｅ　ＩＤごとに、ＯＦＣ　Ｄｏｍａｉｎ　ＩＤ、ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ、ＯＦＳ　ＩＤ、ＯＦＳ　Ｐｏｒｔ　ＩＤ、Ｐｏｒｔ　Ｌｉｎｋ　Ｃｏｓｔの各フィールドを含む。
　ＯＦＣＴＤＤＵパケットのフレームは、以下の条件を満たせば、その他のフォーマット等については、特に限定されない。
・ＭＡＣＳＡ
　ＯＦＣ　ＯｐｅｎＦｌｏｗ　Ｃｈａｎｎｅｌとして利用するＮＩＣのＭＡＣ
　なお、クラスタ構成の場合、共有の仮想ＭＡＣ
・ＭＡＣＤＡ
　ＢＣ／ＭＣ
　レガシースイッチの透過性があるＭＡＣＤＡ
・Ｅｔｈｅｒ　Ｔｙｐｅ
　レガシースイッチの透過性があるＥｔｈｅｒ　Ｔｙｐｅ
　ＯＦＣＴＤＤＵには、Ｎｏｄｅ情報が各Ｎｏｄｅラベルに格納される。Ｎｏｄｅ　ＩＤ＝０のＮｏｄｅラベルには、ＯＦＣＴＤＤＵを送信するＯＦＣ－ＯＦＳドメインの情報が格納される。ＯＦＣがＯＦＣＴＤＤＵを受信すると、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵの最後尾のＮｏｄｅ　ＩＤをインクリメントして、新たなＮｏｄｅラベルを作成し、受信ＯＦＣ－ＯＦＳドメインの情報を、そのＮｏｄｅラベルに格納する。
　具体的には、各ＯＦＣのドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する全外向きポートに対して、送信元のＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ情報を格納したＯＦＣＴＤＤＵを送信する。ＯＦＣがＯＦＣＴＤＤＵを受信すると、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵを受信したＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎを示す情報がそのＯＦＣＴＤＤＵに含まれているか判断する。
　その情報がＯＦＣＴＤＤＵに含まれている場合、ドメイン間トポロジ管理モジュール２１は、トポロジ情報を学習する。一方、その情報がＯＦＣＴＤＤＵに含まれていない場合、ドメイン間トポロジ管理モジュール２１は、トポロジ情報を学習し、さらに、ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ情報をＯＦＣＴＤＤＵに追加して、受信ポート以外で隣接ドメインが存在する外向きポートに転送する。
　一定時間経過後、ＯＦＣのトポロジ管理モジュール２０は、収集したトポロジ情報に基づいてネットワーク全体のトポロジ（以下、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　Ｔｏｐｏｌｏｇｙと記すこともある。）を特定し、経路計算モジュール１０に通知する。
　Ｉｎｔｅｒ－Ｄｏｍａｉｎ　Ｔｏｐｏｌｏｇｙを特定する際、ドメイン間トポロジ管理モジュール２１は、隣り合うポートのリンクコストのうち、最も大きな値を、トポロジにおけるリンクコスト（エッジコスト）として利用してもよい。
（４）Ｕｎｉｃａｓｔ経路計算段階
　経路計算モジュール１０は、特定されたネットワークトポロジを利用して、上述する通信経路に基づく経路を算出して、各ＯＦＳに接続される装置からの通信を制御する。具体的には、経路計算モジュール１０は、ＡＲＰ（Address Resolution Protocol ）　ＲｅｑｕｅｓｔのブロードキャストＭＡＣＤＡを書き換え、ＭＡＣＳＡの発信元ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ情報を設定する。そして、経路計算モジュール１０は、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ経由で、書き換えたパケットを他のＯＦＣに通知する。
　ＭＡＣＳＡの発信元ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ情報は、ＯＦＳＤＡパケットおよびＯＦＳＤＤパケットで伝送される。図７は、ＯＦＳＤＡパケットとＯＦＳＤＤパケットの例を示す説明図である。図７に例示するＯＦＳＤＡパケットには、ＯＦＳＤＡを識別するための固定値として“０３２５５ｃ００”が設定されている。また、図７に例示するＯＦＳＤＤパケットには、ＯＦＳＤＤを識別するための固定値として“０３２５５ｃ０１”が設定されている。
　なお、図７に示すＯＦＳＤＡパケットおよびＯＦＳＤＤパケットは一例である。ただし、以下の条件を満たす。
・ＭＡＣＤＡ
　Ｍｕｌｔｉｃａｓｔ
　ＯＦＣＤＡとＯＦＣＤＤを識別するための識別子を格納するフィールドを有する。
　ＭＡＣＳＡの送信元ＯＦＣ－ＯＦＳ　Ｄｏｍａｉｎ　ＩＤ情報を格納するフィールドを有する。
・Ｅｔｈｅｒ　Ｔｙｐｅ
　ＡＲＰ
　まず、経路計算モジュール１０は、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ上で、隣接ドメインが存在する外向きポートに対して、以下のＯＦＣＤＡ－ＯＦＣＤＤパケットインフローを登録する。
・ＯＦＣＤＡまたはＯＦＣＤＤを受信した場合、ＯＦＣにＰａｃｋｅｔ＿Ｉｎさせる。
　次に、経路計算モジュール１０は、端末（例えば、ＰＣ）から受信したＢＣ　ＡＲＰ　Ｒｅｑｕｅｓｔを、ＯＦＣドメイン内部のＢＣＭＣツリーを経由させ、各ＯＦＳドメイン内の各ＯＦＳにおいて隣接ドメインが存在しない外向きポートにフラディングする。
　経路計算モジュール１０は、ＢＣ　ＡＲＰ　ＲｅｑｕｅｓｔのＭＡＣＳＡを学習し、ＭＡＣローカルテーブル記憶部１２に登録する。なお、ＯＦＳドメイン内部の経路は、既存の方法により特定される。
　次に、経路計算モジュール１０は、端末（例えば、ＰＣ）から受信したＢＣ　ＡＲＰ　ＲｅｑｕｅｓｔをＯＦＳＤＡに書き換え、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ上で、隣接ドメインが存在する外向きポートにフラディングする。
　ＯＦＣがＯＦＣＤＡを受信すると、経路計算モジュール１０は、ＯＦＳＤＡに含まれるＭＡＣＳＡ、および、ＭＡＣＤＡに設定されたＯＦＣドメインＩＤとＯＦＳドメインＩＤとを、ＭＡＣ・宛先ドメインテーブル記憶部１１に登録する。
　そして、経路計算モジュール１０は、そのＯＦＣＤＡパケットを、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ上で、隣接ドメインが存在する全外向きポート（ただし、受信ポートを除く。）にフラディングする。
　次に、経路計算モジュール１０は、ＯＦＣＤＡのＭＡＣＤＡをブロードキャストＭＡＣＤＡに書き戻したＡＲＰ　Ｒｅｑｕｅｓｔを、受信したＯＦＣドメイン内部のＢＣＭＣツリーを経由させ、ドメイン内において隣接ドメインが存在しない外向きポートにフラディングする。
　以上の処理を行うことで、各ＯＦＣは、端末のＭＡＣが存在するＯＦＣ－ＯＦＳ　ＤｏｍａｉｎのＩＤを把握できる。
　次に、その端末のＭＡＣがＭＡＣＤＡに設定されたパケットを、ＯＦＣが受信した場合の処理を説明する。
　ＭＡＣローカルテーブル記憶部１２にその端末のＭＡＣが存在する場合、経路計算モジュール１０は、一般的な方法で、その端末のＭＡＣが存在するポートにパケットを転送する制御を行う。経路計算モジュール１０は、例えば、フローエントリを追加してパケットを転送するように制御してもよい。
　一方、ＭＡＣローカルテーブル記憶部１２にその端末のＭＡＣが存在しない場合、経路計算モジュール１０は、ＭＡＣ・宛先ドメインテーブル記憶部１１を検索する。
　ＭＡＣ・宛先ドメインテーブル記憶部１１にも、その端末のＭＡＣが存在しない場合、経路計算モジュール１０は、受信したパケットをＵｎｋｎｏｗｎ　ｕｎｉｃａｓｔパケットとして認識する。そして、経路計算モジュール１０は、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ上において隣接ドメインが存在する全外向きポート、および、自ＯＦＣ－ＯＦＳドメイン内において隣接ドメインが存在しない外向きポートに対して、受信したパケットをフラディングする。
　一方、ＭＡＣ・宛先ドメインテーブル記憶部１１にその端末のＭＡＣが存在する場合、経路計算モジュール１０は、Ｕｎｉｃａｓｔパケットを受信した自ＯＦＣ－ＯＦＳドメインを始点とし、ＭＡＣ・宛先ドメインテーブルの宛先ＯＦＣ－ＯＦＳドメインを終点として、最短経路を探索する。
　経路計算モジュール１０は、例えば、ダイクストラ法など、一般的に用いられる任意の探索アルゴリズムを用いて最短経路を探索すればよい。
　また、最短経路が複数存在する場合、経路計算モジュール１０は、予め定めた分散アルゴリズム（例えば、ラウンドロビン法や、ＭＡＣハッシュ、ＩＰハッシュなど）を用いて、経路を選択してもよい。
　経路計算モジュール１０は、ＯＦＣは、計算された最短経路上のＯＦＣ－ＯＦＳドメインに接続されたポートに該当のパケットを転送する制御を行う。経路計算モジュール１０は、例えば、フローエントリをＯＦＳに設定し、送信するＵｎｉｃａｓｔパケットのハードウェア転送を実施させる。
　また、ＯＦＣ管理配下のＭＡＣが消滅した場合、経路計算モジュール１０は、ＭＡＣローカルテーブル記憶部１２から、消滅したＭＡＣのラーニング情報を削除する。そして、経路計算モジュール１０は、そのＭＡＣをＭＡＣＳＡに設定したＯＦＣＤＤを、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅ経由で、各ＯＦＣ－ＯＦＳドメインにフラディングする。ＯＦＣがＯＦＣＤＤを受信すると、経路計算モジュール１０は、ＯＦＣＤＤに設定されたＭＡＣＳＡの情報を、ＭＡＣ・宛先ドメインテーブル記憶部１１から削除する。
　経路計算モジュール１０は、トポロジディスカバリが完了した後、Ｕｎｉｃａｓｔ経路を計算することで、Ｋｎｏｗｎ　Ｕｎｉｃａｓｔの転送および負荷分散を行う。よって、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
　以下、第１の実施形態の通信制御システムの動作例を、図１を参照して用いてさらに説明する。図１に示す例では、各ＯＦＣは、既存の方式で自ドメイン内部のＢＣＭＣ　Ｔｒｅｅを構築する。具体的には、ＯＦＣ１ドメイン１１０（以下、ＯＦＣ１－ＯＦＳ１ドメインと記す。）においてはＯＦＳ３とＯＦＳ４の間のリンクがブロックされ、ＯＦＣ２ドメイン１２０（以下、ＯＦＣ２－ＯＦＳ１ドメインと記す。）においてはＯＦＳ２とＯＦＳ４の間のリンクがブロックされ、ＯＦＣ３ドメイン１３０（以下、ＯＦＣ３－ＯＦＳ１ドメインと記す。）においてはＯＦＳ３とＯＦＳ４の間のリンクがブロックされたものとする。
　また、ＯＦＣ１－ＯＦＳ１ドメインにおけるＯＦＳ１－Ｐｏｒｔ１、ＯＦＳ２－Ｐｏｒｔ１、ＯＦＳ３－Ｐｏｒｔ１およびＯＦＳ４－Ｐｏｒｔ１は、外向きポートとしてＯＦＣ１に認識されている。
　同様に、ＯＦＣ２－ＯＦＳ１ドメインにおけるＯＦＳ１－Ｐｏｒｔ１およびＯＦＳ３－Ｐｏｒｔ１は、外向きポートとしてＯＦＣ２に認識されている。また、ＯＦＣ３－ＯＦＳ１ドメインにおけるＯＦＳ１－Ｐｏｒｔ１およびＯＦＳ２－Ｐｏｒｔ１は、外向きポートとしてＯＦＣ３に認識されている。
（１）ネーバーディスカバリ段階
　各ＯＦＣの内部ドメイントポロジ管理モジュール２２は、自身が管理する配下に存在する外向きポートに対して、ＯＦＣＮＡＤをフラディングする。ＯＦＣ１が送信するＯＦＣＮＡＤは、以下に例示する情報を含む。
・ＯＦＳ１－Ｐｏｒｔ１に対して
　Ｔｙｐｅ：ＮＡＤ，
　Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＳ２－Ｐｏｒ１に対して
　Ｔｙｐｅ：ＮＡＤ，
　Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＳ３－Ｐｏｒ１に対して
　Ｔｙｐｅ：ＮＡＤ，
　Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ３，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＳ４－Ｐｏｒ１に対して
　Ｔｙｐｅ：ＮＡＤ，
　Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝
　ＯＦＣ１から送信されるＯＦＣＮＤ（ＮＡＤ）は、ＰＣ２１１、ＰＣ２１２、ＯＦＣ２－ＯＦＳ１ドメインおよびＯＦＣ３－ＯＦＳ１ドメインに到達する。ＰＣ２１１とＰＣ２１２は端末なので、ＯＮＣＮＤ（ＮＡＤ）パケットに対して回答を行わない。
　ＯＦＣ２－ＯＦＳ１ドメインおよびＯＦＣ３－ＯＦＳ１ドメインに到達したＯＦＣＮＤ（ＮＡＤ）は、ＯＦＣＮＤパケットインフローに一致し、それぞれ、ＯＦＣ２とＯＦＣ３にＰａｃｋｅｔ＿Ｉｎされる。
　ＯＦＣ２およびＯＦＳ３のドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＤ（ＮＲＳ）パケットを回答する。この場合にＯＦＣ２およびＯＦＣ３が送信するＯＦＣＮＤ（ＮＲＳ）パケットは、以下の情報を含む。
・ＯＦＣ２はＯＦＳ１－Ｐｏｒｔ１に対して
　Ｔｙｐｅ：ＮＲＳ，
　Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＣ３はＯＦＳ１－Ｐｏｒｔ１に対して
　Ｔｙｐｅ：ＮＲＳ，
　Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
　ＯＦＣ２およびＯＦＣ３から送信されるＯＦＣＮＤ（ＮＲＳ）は、ＯＦＣ１－ＯＦＳ１ドメインに到達し、ＯＦＣＮＤパケットフローに一致し、ＯＦＣ１にＰａｃｋｅｔ＿Ｉｎされる。ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、ＯＦＳ２－Ｐｏｒｔ１およびＯＦＳ４－Ｐｏｒｔ１をネーバーあり外向きポートとして認識し、ドメイン間トポロジ情報記憶部１３に以下の情報を記録する。
・Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
　一方、ＯＦＳ１－Ｐｏｒｔ１およびＯＦＳ３－Ｐｏｒｔ１では、ＯＦＣＮＤ（ＮＲＳ）が受信されない。そのため、ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、この２つのポートをネーバーなし外向きポートとして認識し、既存の方式に従って、ＯＦＳ１－Ｐｏｒｔ１およびＯＦＳ３－Ｐｏｒｔ１のＰａｃｋｅｔ＿Ｉｎやパケット転送を許可する。
　この場合、ＯＦＣ１ドメイン内の通信（例えば、ＰＣ２１１とＰＣ２１２との間の通信）は可能になる。他のＯＦＣ２とＯＦＣ３も同様にネーバーディスカバリ処理を行う。ＯＦＣ２が検出した情報は、以下に例示する内容である。
・Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ３，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
　同様に、ＯＦＣ３が検出した情報は、以下に例示する内容である。
・Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝
・Ｏｒｉｇｉｎａｌ　Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
　Ｎｅｉｇｈｂｏｒ　Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ３，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
（２）ループディスカバリ段階
　各ＯＦＣは、ＯＦＣＤＵを送受信することにより、上記の実施形態で説明したＳＴＰに類似する動作を行い、ＯＦＣドメイン間のループを防止する。ループを防止する際のアルゴリズムは、ＳＴＰに基づく処理と同様のため、ここでは詳細な説明は省略する。
　ここでは、ＯＦＣドメインＩＤが最小のドメインであるＯＦＣ１－ＯＦＳ１ドメインが、Ｒｏｏｔ　Ｄｏｍａｉｎとして選出される。一方、ＯＦＣ３－ＯＦＳ１ドメインのＯＦＳ２－Ｐｏｒｔ１が、非代表ポートとして選出される。
　各ＯＦＣのドメイン間トポロジ管理モジュール２１は、ＯＦＣ３－ＯＦＳ１ドメインのＯＦＳ２－Ｐｏｒｔ１以外のネーバーあり外向きポートに対して、Ｐａｃｋｅｔ＿Ｉｎやパケット転送などを許可する。その結果、以下に例示するＩｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅが構成される。以降、ＯＦＣ－ＯＦＳドメイン間の通信は、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅを介して行われる。
・（ＯＦＣ１－ＯＦＳ１ドメイン、ＯＦＳ２、Ｐｏｒｔ１）と、
　（ＯＦＣ２－ＯＦＳ１ドメイン、ＯＦＳ１、Ｐｏｒｔ１）とが接続される。
・（ＯＦＣ１－ＯＦＳ１ドメイン、ＯＦＳ４、Ｐｏｒｔ１）と、
　（ＯＦＣ３－ＯＦＳ１ドメイン、ＯＦＳ１、Ｐｏｒｔ１）とが接続される。
（３）トポロジディスカバリ段階
　各ＯＦＣは、ネーバーあり全外向きポートに対して、ＯＦＣＴＤＤＵを送信する。ここでは、ＯＦＣ１から送信されたＯＦＣＴＤＤＵに対する処理例を説明する。
　ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、ＯＦＳ２－Ｐｏｒｔ１とＯＦＳ４－Ｐｏｒｔ１に対して、それぞれ以下の情報を含むＯＦＣＴＤＤＵを送信する。このとき、Ｎｏｄｅ　ＩＤ＝０のＮｏｄｅラベルに格納されるＬｉｎｋｃｏｓｔは、ＯＦＣＴＤＤＵが送信されたポート（ＯＦＳ２－Ｐｏｒｔ１およびＯＦＳ４－Ｐｏｒｔ１）に設定されるリンクのリンクコスト値である。
・ＯＦＳ２－Ｐｏｒｔ１に対して
　Ｎｏｄｅ　ＩＤ＝０
　｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
・ＯＦＳ４－Ｐｏｒｔ１に対して
　Ｎｏｄｅ　ＩＤ＝０
　｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ２｝
　ＯＦＣ２－ＯＦＳ１ドメインに到達したＯＦＣＴＤＤＵは、ＯＦＣＴＤＤＵパケットインフローに一致し、ＯＦＣ２にＰａｃｋｅｔ＿Ｉｎされる。ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵに含まれるトポロジ情報を学習する。
　ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵのＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信したＯＦＣ－ＯＦＳドメイン（ＯＦＣ２－ＯＦＳ１ドメイン）の情報が含まれていないと判定する。そこで、ドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵにおける最後のＮｏｄｅ　ＩＤをインクリメントし、新たなＮｏｄｅ　ＩＤを有するＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信したＯＦＣ２－ＯＦＳ１ドメインの情報を格納する。
　ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、新たに作成したＯＦＣＴＤＤＵを、受信ポート以外のネーバーあり外向きポート（ＯＦＣ２－ＯＦＳ１ドメインに存在するＯＦＳ３－Ｐｏｒｔ１）にフラディングする。
　ＯＦＣ１が発信したＯＦＣＴＤＤＵは、ＯＦＣ２を経由して転送され、以下に例示する情報を含む。
・ＯＦＳ３－Ｐｏｒｔ１に対して
　Ｎｏｄｅ　ＩＤ＝０
　｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　Ｎｏｄｅ　ＩＤ＝１
　｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　同様に、ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵパケットからトポロジ情報を学習する。ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵに基づいて新たなＯＦＣＴＤＤＵを作成し、ＯＦＳ２－Ｐｏｒｔ１にフラディングする。
　ＯＦＣ１が発信したＯＦＣＴＤＤＵは、ＯＦＣ３を経由して転送され、以下に例示する情報を含む。
・ＯＦＳ２－Ｐｏｒｔ１に対して
　Ｎｏｄｅ　ＩＤ＝０
　｛ＯＦＣ１ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ２｝
・Ｎｏｄｅ　ＩＤ＝１
　｛ＯＦＣ３ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　一方、ＯＦＣ１が発信したＯＦＣＴＤＤＵがＯＦＣ２から転送されてＯＦＣ３に到達する。ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵパケットからトポロジ情報を学習する。
　ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵのＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信した受信ＯＦＣ－ＯＦＳドメインの情報が含まれていないと判定する。そこで、ドメイン間トポロジ管理モジュール２１は、新たなＯＦＣＴＤＤＵを作成し、ＯＦＳ１－Ｐｏｒｔ１にフラディングする。
　新たに作成されたＯＦＣＴＤＤＵには、以下に例示する情報が含まれる。
・ＯＦＳ１－Ｐｏｒｔ１に対して
　Ｎｏｄｅ　ＩＤ＝０
　｛ＯＦＣ１ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　Ｎｏｄｅ　ＩＤ＝１
　｛ＯＦＣ２ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　Ｎｏｄｅ　ＩＤ＝２
　｛ＯＦＣ３ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　さらに、ＯＦＣ１が発信したＯＦＣＴＤＤＵがＯＦＣ２から転送されてＯＦＣ２に到達する。ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵパケットからトポロジ情報を学習する。
　ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵのＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信した受信ＯＦＣ－ＯＦＳドメインの情報が含まれていないと判定する。そこで、ドメイン間トポロジ管理モジュール２１は、新たなＯＦＣＴＤＤＵを作成し、ＯＦＳ１－Ｐｏｒｔ１にフラディングする。
　新たに作成されたＯＦＣＴＤＤＵには、以下に例示する情報が含まれる。
・ＯＦＳ１－Ｐｏｒｔ１に対して
　Ｎｏｄｅ　ＩＤ＝０
　｛ＯＦＣ１ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ２｝
　Ｎｏｄｅ　ＩＤ＝１
　｛ＯＦＣ２ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　Ｎｏｄｅ　ＩＤ＝２
　｛ＯＦＣ３ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
　その後、ＯＦＣ１は、ＯＦＣ１からＯＦＣ２を経由しさらにＯＦＣ３を経由したＯＦＣＴＤＤＵと、ＯＦＣ１からＯＦＣ３を経由しさらにＯＦＣ２を経由したＯＦＣＴＤＤＵとを受信する。ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、自身のＯＦＣ－ＯＦＳドメイン（ＯＦＣ１－ＯＦＳ１ドメイン）がＯＦＣＴＤＤＵのＮｏｄｅラベルに含まれていると判定する。そこで、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵに含まれるトポロジ情報を学習し、ＯＦＣＴＤＤＵパケットを廃棄する。
　ＯＦＣ２およびＯＦＣ３も同様に、自らＯＦＣＴＤＤＵを発行し、トポロジディスカバリ処理を行う。その結果、ＯＦＣ１、ＯＦＣ２およびＯＦＣ３は、以下のトポロジ情報を保持する。
・ＯＦＣ１－ＯＦＳ１ドメインとＯＦＣ２－ＯＦＳ１ドメインが、Ｌｉｎｋｃｏｓｔ１で接続されている。
・ＯＦＣ１－ＯＦＳ１ドメインとＯＦＣ３－ＯＦＳ１ドメインが、Ｌｉｎｋｃｏｓｔ２で接続されている。
・ＯＦＣ２－ＯＦＳ１ドメインとＯＦＣ３－ＯＦＳ１ドメインが、Ｌｉｎｋｃｏｓｔ１で接続されている。
（４）Ｕｎｉｃａｓｔ経路計算段階
　本具体例では、ＰＣ２１１がＡＲＰ　Ｒｅｑｕｅｓｔを送信する。ＡＰＲ　Ｒｅｑｕｅｓｔは、ＯＦＣ１－ＯＦＳ１ドメインに到達し、ＯＦＣ１にＰａｃｋｅｔ＿Ｉｎされる。
　ＯＦＣ１の経路計算モジュール１０は、ＡＲＰ　ＲｅｑｕｅｓｔをＯＦＳ３－Ｐｏｒｔ１にフラディングし、ＭＡＣローカルテーブルにＡＲＰ　ＲｅｑｕｅｓｔのＭＡＣＳＡと学習位置（ＯＦＳ１ドメインのＯＦＳ１－Ｐｏｒｔ１）を登録する。
　ＯＦＣ１の経路計算モジュール１０は、ＡＲＰ　ＲｅｑｕｅｓｔをＯＦＣＤＡに書き換える。具体的には、経路計算モジュール１０は、ＡＲＰ　Ｒｅｑｕｅｓｔを受信したＯＦＣ１－ＯＦＳ１ドメインのＩＤをＯＦＣＤＡに含め、Ｉｎｔｅｒ－Ｄｏｍａｉｎ　ＢＣＭＣ　Ｔｒｅｅにあるネーバーあり外向きポートに対してそのＯＦＣＤＡをフラディングする。
　ＯＦＣ２およびＯＦＣ３は、ＯＦＣ１から発行されたＰＣ２１１のＭＡＣがＭＡＣＳＡとして含まれるＯＦＣＤＡをＰａｃｋｅｔ＿Ｉｎで受信する。
　ＯＦＣ２の経路計算モジュール１０は、受信したＯＦＣＤＡから、ＰＣ２１１のＭＡＣＳＡと、そのＭＡＣの送信元ドメインであるＯＦＣ１－ＯＦＳ１ドメインＩＤを抽出し、ＭＡＣ・宛先ドメインテーブル記憶部１１に登録する。
　同様に、ＯＦＣ３の経路計算モジュール１０は、ＰＣ２１１のＭＡＣＳＡと、そのＭＡＣの送信元ドメインであるＯＦＣ１－ＯＦＳ１ドメインＩＤを抽出し、ＭＡＣ・宛先ドメインテーブル記憶部１１に登録する。また、ＯＦＣ３の経路計算モジュール１０は、ＯＦＣＤＡをＡＲＰ　Ｒｅｑｕｅｓｔに書き換え、ＯＦＳ４－Ｐｏｒｔ１とＯＦＳ３－Ｐｏｒｔ１にフラディングする。
　ＰＣ２１１、ＰＣ２１２、ＰＣ２３１およびＰＣ２３２のすべてが、ＡＲＰ　Ｒｅｑｕｅｓｔを出した場合、ＯＦＣ１、ＯＦＣ２およびＯＦＣ３のＭＡＣローカルテーブル記憶部１２およびＭＡＣ・宛先ドメインテーブル記憶部１１には、以下の情報が登録される。
＜ＯＦＣ１＞
・ＭＡＣローカルテーブル
ＭＡＣＳＡ＝ＰＣ２１１，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＳ１－Ｐｏｒｔ１
ＭＡＣＤＡ＝ＰＣ２１２，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＳ２－Ｐｏｒｔ１
・ＭＡＣ・宛先ドメインテーブル
ＭＡＣＳＡ＝ＰＣ２３１，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ３－ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２３２，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ３－ＯＦＳ１ドメイン
＜ＯＦＣ２＞
・ＭＡＣローカルテーブル
空（未設定）
・ＭＡＣ・宛先ドメインテーブル
ＭＡＣＳＡ＝ＰＣ２１１，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ１－ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２１２，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ１－ＯＦＳ１ドメインＭＡＣＳＡ＝ＰＣ２３１，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ３－ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２３２，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ３－ＯＦＳ１ドメイン
＜ＯＦＣ３＞
・ＭＡＣローカルテーブル
ＭＡＣＳＡ＝ＰＣ２３１，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＳ４－Ｐｏｒｔ１
ＭＡＣＤＡ＝ＰＣ２３２，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＳ３－Ｐｏｒｔ１
・ＭＡＣ・宛先ドメインテーブル
ＭＡＣＳＡ＝ＰＣ２１１，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ１－ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２１２，Ｌｅａｒｎｉｎｇ　Ｐｏｉｎｔ：ＯＦＣ１－ＯＦＳ１ドメイン
　例えば、ＰＣ２１１からＰＣ２３１に対してＵｎｉｃａｓｔ通信を行う場合、ＯＦＣ１の経路計算モジュール１０は、Ｐａｃｋｅｔ＿Ｉｎで受信したＵｎｉｃａｓｔパケットのＭＡＣＤＡ（ＰＣ２３１）で、ＭＡＣローカルテーブル記憶部１２を検索する。
　この場合、ＭＡＣローカルテーブル記憶部１２には、対象のＭＡＣＤＡが存在しないため、ＯＦＣ１の経路計算モジュール１０は、ＰＣ２３１でＭＡＣ・宛先ドメインテーブル記憶部１１を検索する。その結果、ＯＦＣ１の経路計算モジュール１０は、ＰＣ２３１がＯＦＣ３－ＯＦＳ１ドメインに存在することを知る。
　ＯＦＣ１の経路計算モジュール１０は、Ｕｎｉｃａｓｔパケットインを受信したＯＦＣ－ＯＦＳドメイン（ＯＦＣ１－ＯＦＳ１ドメイン）を始点とし、ＰＣ２３１が存在するＯＦＣ３－ＯＦＳ１ドメインを終点として、トポロジ上における最小コスト経路を探索する。
　本例の場合、ＯＦＣ１の経路計算モジュール１０は、以下に例示する最小コスト経路を算出する。
（１）ＯＦＣ１－ＯＦＳ１ドメインからＯＦＣ２－ＯＦＳ１ドメインを経由し、ＯＦＣ３－ＯＦＳ１ドメインに至るまでのＬｉｎｋｃｏｓｔ＝２
（２）ＯＦＣ１－ＯＦＳ１ドメインからＯＦＣ３－ＯＦＳ１ドメインに至るまでのＬｉｎｋｃｏｓｔ＝２
　上記に例示するように、最小コスト経路は２つ存在する。そこで、ＯＦＣ１の経路計算モジュール１０は、一般的なＯＦＣの負荷分散アルゴリズムに従って、任意の経路を選択する。なお、ここでは、（１）の経路が選択されたものとする。
　ＯＦＣ１の経路計算モジュール１０は、ドメイン間トポロジ情報記憶部１３を参照し、ＯＦＣ２－ＯＦＳ１ドメインに転送するためのＯＦＳ　ＩＤおよびＰｏｒｔ　ＩＤを取得する。そして、ＯＦＣ１の経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットを、ＯＦＣ２－ＯＦＳ１ドメインに転送するように制御する。
　ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットは、ＯＦＣ１－ＯＦＳ１ドメインからＯＦＣ２－ＯＦＳ１ドメインに転送される。
　ＯＦＣ２は、ＵｎｉｃａｓｔパケットをＰａｃｋｅｔ＿Ｉｎで受信する。ＯＦＣ２の経路計算モジュール１０は、ＭＡＣローカルテーブル記憶部１２およびＭＡＣ・宛先ドメインテーブル記憶部１１からＭＡＣＤＡ（ＰＣ２３１）を検索する。本例において、ＯＦＣ２の経路計算モジュール１０は、ＰＣ２３１がＯＦＣ３－ＯＦＳ１ドメインに存在することを知る。
　ＯＦＣ２の経路計算モジュール１０は、Ｕｎｉｃａｓｔパケットインを受信したＯＦＣ－ＯＦＳドメイン（ＯＦＣ２－ＯＦＳ１ドメイン）を始点とし、ＰＣ２３１が存在するＯＦＣ３－ＯＦＳ１ドメインを終点として、トポロジ上における最小コスト経路を探索する。
　本例の場合、ＯＦＣ２の経路計算モジュール１０は、以下に例示する最小コスト経路を算出する。
（１）ＯＦＣ２－ＯＦＳ１ドメインからＯＦＣ３－ＯＦＳ１ドメインに至るまでのＬｉｎｋｃｏｓｔ＝１
　ＯＦＣ２の経路計算モジュール１０は、ドメイン間トポロジ情報記憶部１３を参照し、ＯＦＣ３－ＯＦＳ１ドメインに転送するためのＯＦＳ　ＩＤおよびＰｏｒｔ　ＩＤを取得する。そして、ＯＦＣ２の経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットを、ＯＦＣ３－ＯＦＳ１ドメインに転送するように制御する。
　ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットは、Ｐａｃｋｅｔ＿ＩｎでＯＦＣ３に到達する。
　ＯＦＣ３の経路計算モジュール１０は、ＭＡＣローカルテーブル記憶部１２からＭＡＣＤＡ（ＰＣ２３１）を検索する。すると、経路計算モジュール１０は、管理する配下のドメイン内のＯＦＳ４－Ｐｏｒｔ１にＰＣ２３１が接続されていることを知る。よって、ＯＦＣ３の経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットを、ＯＦＳ４－Ｐｏｒｔ１転送するように制御する。
　以上の処理により、Ｕｎｉｃａｓｔパケットは、ＰＣ２１１から、ＯＦＣ１－ＯＦＳ１ドメイン、ＯＦＣ２－ＯＦＳ１ドメイン、ＯＦＣ３－ＯＦＳ１ドメインの順にドメインを経由して、ＰＣ２３１まで転送される。
　なお、上記説明では、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットが単独で送信される場合を例示した。例えば、ＰＣ２１１からＰＣ２３１宛の通信と、ＰＣ２１２からＰＣ２３２宛の通信が同時に行われてもよい。この場合、各ＯＦＣの経路計算モジュール１０は、トラヒック負荷分散を考慮した処理を行ってもよい。
　ＰＣ２１１からＰＣ２３１宛の通信と、ＰＣ２１２からＰＣ２３２宛の通信が同時に行われる場合、ＯＦＣ１－ＯＦＳ１ドメインからＯＦＣ３－ＯＦＳ１ドメイン宛の最小コスト経路は２つ存在する。経路計算モジュール１０は、例えば、ラウンドロビンアルゴリズムを用いて負荷分散処理を行ってもよい。この場合、経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１への通信には、ＯＦＣ１－ＯＦＳ１ドメインからＯＦＣ２－ＯＦＳ１ドメインを経由し、ＯＦＣ３－ＯＦＳ１ドメインへ到達する経路を算出してもよい。また、経路計算モジュール１０は、ＰＣ２２１からＰＣ２３２への通信には、ＯＦＣ１－ＯＦＳ１ドメインからＯＦＣ３－ＯＦＳ１ドメインへ到達する経路を算出してもよい。
　以上のように、本実施形態によれば、ドメイン間トポロジ管理モジュール２１が、自ＯＦＣドメインに隣接するＯＦＣドメインを特定する。ドメイン間トポロジ管理モジュール２１は、隣接するＯＦＣドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成し、各ＯＦＣドメイン間のネットワークトポロジを特定する。そして、経路計算モジュール１０が、特定されたネットワークトポロジを利用して、上述する通信ツリーに基づく最適経路を算出して、各ＯＦＳに接続される通信装置からの通信を制御する。
　よって、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
　具体的には、本実施形態の通信制御システムは、既存のＯＦＣの処理方式に影響を与えず、標準的なＯｐｅｎＦｌｏｗプロトコルを用いて実現できる。そして、本実施形態の通信制御システムを用いることで、独立に動作する複数のＯＦＣによって制御されているＯｐｅｎＦｌｏｗネットワーク間のループを防止できるため、ＯｐｅｎＦｌｏｗネットワーク間の冗長構成を組むことができる。
　また、本実施形態によれば、独立に動作する複数のＯＦＣによって制御されているＯｐｅｎＦｌｏｗネットワーク間に、複数の通信経路の候補が存在する場合であっても、ＥＣＭＰ（Equal-cost multi-path ）的なロードバランシングを実現できる。そのため、ネットワーク帯域の利用効率を上げることができる。
　また、本実施形態によれば、オープンフローのネットワーク内にダークファイバが存在する場合でも、最適なリンクコストを用いて経路計算ができるため、ネットワーク帯域の利用率を上げることができる。したがって、ダークファイバリンクコストの誤判断により発生する帯域圧迫の確率を低減できる。
実施形態２．
　次に、本発明の第２の実施形態を説明する。第１の実施形態では、ＯＦＣが、隣接するドメインの情報に基づいてシステム全体のドメイントポロジを計算し、さらに、ドメイン間のＳＰＴを算出していた。一方、本実施形態では、システム内全てのＯＦＣとＩＰ到達性を有するトポロジマネージャを用意し、これらの処理をそのトポロジマネージャが行って、処理結果を各ＯＦＣに通知する。
　このように、第１の実施形態では、各ＯＦＣが自律的に通信制御を行うことから、第１の実施形態で説明した手法を、完全自律手法と呼ぶことができる。また、本実施形態で説明する手法は、ＯＦＣとトポロジマネージャが協働して通信制御を行うことから、ハイブリッド手法と呼ぶことができる。
　図８は、本発明による通信制御システムの第２の実施形態の構成例を示す説明図である。なお、第１の実施形態と同様の構成については、図１と同一の符号を付し、説明を省略する。
　図８に例示する通信制御システムは、第１の実施形態の通信制御システムに加え、トポロジマネージャ１４０を備えている。また、トポロジマネージャ１４０は、制御部１４１を含む。制御部１４１は、プログラム（ドメイン間トポロジ管理プログラム）に従って動作するコンピュータのＣＰＵによって実現される。例えば、プログラムは、トポロジマネージャ１４０の記憶部（図示せず）に記憶され、ＣＰＵは、そのプログラムを読み込み、プログラムに従って、制御部１４１として動作してもよい。
　本実施形態のＯＦＣでは、ネーバーディスカバリ段階の処理が完了すると、各ＯＦＣのドメイン間トポロジ管理モジュール２１は、隣接ドメインを示す情報をトポロジマネージャ１４０に送信する。
　トポロジマネージャ１４０が各ＯＦＣから隣接ドメインを示す情報を受信すると、制御部１４１は、受信した情報に基づいて、ＯＦＣドメイン間のトポロジを計算し、さらに、ＯＦＣドメイン間でループ構成を回避する通信ツリー（例えば、スパニングツリー）を算出する。そして、制御部１４１は、算出した通信ツリーを各ＯＦＣに配信する。
　制御部１４１は、第１の実施形態でドメイン間トポロジ管理モジュール２１が行う方法と同様の方法を用いて、ＯＦＣドメイン間のトポロジを計算してもよく、ＯＦＣドメイン間のループ構成を回避する通信ツリーを算出してもよい。
　ドメイン間トポロジ管理モジュール２１は、トポロジマネージャ１４０から受信した通信ツリーを、ドメイン間の通信経路と判断し、例えば、ドメイン間のスパンニングツリーを構築する。以降、経路計算モジュール１０は、Ｕｎｉｃａｓｔ経路計算段階の処理を行う。経路計算モジュール１０がＵｎｉｃａｓｔ経路を計算する方法は、第１の実施形態と同様である。
　このように、ハイブリッド方式では、完全自律方式におけるループディスカバリ段階の処理、および、トポロジディスカバリ段階の処理が、ＯＦＣではなく、トポロジマネージャ１４０で行われることになる。
　以上のように、本実施形態によれば、ＯＦＣの代わりに、トポロジマネージャ１４０の制御部１４１が、ＯＦＣから受信した隣接ドメイン情報に基づいて、各ＯＦＣドメイン間のトポロジを特定し、隣接するＯＦＣドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する。そして、制御部１４１が、作成した通信ツリーを各ＯＦＣに配信する。
　このような構成であっても、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
　このように、本発明を実現する方式として、完全自律方式とハイブリッド方式が挙げられ、異なる環境に柔軟に対応することが可能である。完全自律方式の場合、例えば、ループ防止や負荷分散を、他の装置を介さずに実現することが可能である。一方、ハイブリッド方式の場合、ＯＦＣドメイン間のトポロジを集中管理するトポロジマネージャを利用することで、例えば、ＯＦＣＤＵやＯＦＣＴＤＤＵに占有されるネットワーク帯域や負荷を低減できる。
　次に、本発明の概要を説明する。図９は、本発明による通信制御システムの概要を示すブロック図である。本発明による通信制御システムは、各オープンフローコントローラ（例えば、ＯＦＣ１～ＯＦＣ３）によって少なくとも１つ以上のオープンフロースイッチ（例えば、ＯＦＳ１～ＯＦＳ４）が管理される範囲を示すコントローラドメイン（例えば、ＯＦＣドメイン）が相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段８１（例えば、ドメイン間トポロジ管理モジュール２１）と、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリー（例えば、スパニングツリー）を作成するループ解決手段８２（例えば、ドメイン間トポロジ管理モジュール２１）と、各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定手段８３（例えば、ドメイン間トポロジ管理モジュール２１）と、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置（例えば、ＰＣ２１１等）からの通信を制御する通信制御手段８４（例えば、経路計算モジュール１０）とを備えている。
　そのような構成により、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
　また、隣接ドメイン特定手段８１は、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケット（例えば、ＯＦＣＮＡＤ）を送信し、隣接確認パケットを受信したときにその隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケット（例えば、ＯＦＣＮＲＳ）を返信し、隣接応答パケットを受信して隣接するコントローラドメインを特定してもよい。
　また、ループ解決手段８２は、スパニングツリーアルゴリズムに基づいて、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成してもよい。
　また、ループ解決手段８２は、隣接するコントローラドメイン間の通信経路中のポート（例えば、非代表ポート）に対して、パケット転送を禁止するフローエントリを設定することにより、ループ構成を回避する通信ツリーを作成してもよい。
　また、通信制御手段８４は、複数の経路を算出し、各オープンフロースイッチに接続される通信装置からの通信を複数の経路に負荷分散する制御（例えば、ＥＣＭＰ的なロードバランシング）を行ってもよい。
　また、図１０は、本発明による通信制御システムの他の概要を示すブロック図である。本発明による他の通信制御システムは、各オープンフローコントローラ（例えば、ＯＦＣ１～ＯＦＣ３）によって少なくとも１つ以上のオープンフロースイッチ（例えば、ＯＦＳ１～ＯＦＳ４）が管理される範囲を示すコントローラドメイン（例えば、ＯＦＣドメイン）が相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、複数のオープンフローコントローラ８０（例えば、ＯＦＣ１～ＯＦＣ３）と、オープンフローコントローラからの通信が到達するように（例えば、ＩＰ到達性を有するように）接続され、コントローラドメイン間の通信経路を示す通信ツリーを作成するトポロジマネージャ９０（例えば、トポロジマネージャ１４０）とを備えている。
　オープンフローコントローラ８０は、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段８１（例えば、第２の実施形態におけるドメイン間トポロジ管理モジュール２１）と、特定した隣接するコントローラドメインを示す情報を、トポロジマネージャに送信する隣接ドメイン情報送信手段８５（例えば、第２の実施形態におけるドメイン間トポロジ管理モジュール２１）と、トポロジマネージャが算出したネットワークトポロジに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段８６（例えば、経路計算モジュール１０）とを含む。
　トポロジマネージャ９０は、オープンフローコントローラ８０から受信した情報に基づいて、各コントローラドメイン間のネットワークトポロジを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する通信ツリー作成手段９１（例えば、制御部１４１）と、作成した通信ツリーをオープンフローコントローラに配信するネットワークトポロジ配信手段９２（例えば、制御部１４１）とを含む。
　そのような構成によっても、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
　以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　この出願は、２０１４年２月５日に出願された日本特許出願２０１４－０２０３９０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１０　経路計算モジュール
　１１　ＭＡＣ・宛先ドメインテーブル記憶部
　１２　ＭＡＣローカルテーブル記憶部
　１３　ドメイン間トポロジ情報記憶部
　２０　トポロジ管理モジュール
　２１　ドメイン間トポロジ管理モジュール
　２２　内部ドメイントポロジ管理モジュール
　３０　メッセージ解析モジュール
　４０　メッセージ送受信モジュール
　１００　ＯＦＣ
　１１０　ＯＦＣ１ドメイン
　１２０　ＯＦＣ２ドメイン
　１３０　ＯＦＣ３ドメイン
　２１０，２１１，２１２，２３１，２３２　ＰＣ

Claims (10)

  1. 　各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、
    　自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、
    　前記隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決手段と、
    　各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定手段と、
    　前記ネットワークトポロジを利用して、前記通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを備えた
    　ことを特徴とする通信制御システム。
  2. 　隣接ドメイン特定手段は、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケットを送信し、前記隣接確認パケットを受信したときに当該隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケットを返信し、前記隣接応答パケットを受信して隣接するコントローラドメインを特定する
    　請求項１記載の通信制御システム。
  3. 　ループ解決手段は、スパニングツリーアルゴリズムに基づいて、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する
    　請求項１または請求項２記載の通信制御システム。
  4. 　ループ解決手段は、隣接するコントローラドメイン間の通信経路中のポートに対して、パケット転送を禁止するフローエントリを設定することにより、ループ構成を回避する通信ツリーを作成する
    　請求項１から請求項３のうちのいずれか１項に記載の通信制御システム。
  5. 　通信制御手段は、複数の経路を算出し、各オープンフロースイッチに接続される通信装置からの通信を前記複数の経路に負荷分散する制御を行う
    　請求項１から請求項４のうちのいずれか１項に記載の通信制御システム。
  6. 　各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、
    　複数のオープンフローコントローラと、
    　前記オープンフローコントローラからの通信が到達するように接続され、前記コントローラドメイン間の通信経路を示す通信ツリーを作成するトポロジマネージャとを備え、
    　前記オープンフローコントローラは、
    　自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、
    　特定した隣接するコントローラドメインを示す情報を、前記トポロジマネージャに送信する隣接ドメイン情報送信手段と、
    　前記トポロジマネージャが算出したネットワークトポロジに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを含み、
    　前記トポロジマネージャは、
    　前記オープンフローコントローラから受信した情報に基づいて、各コントローラドメイン間のネットワークトポロジを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する通信ツリー作成手段と、
    　作成した通信ツリーを前記オープンフローコントローラに配信するネットワークトポロジ配信手段とを含む
    　ことを特徴とする通信制御システム。
  7. 　各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御方法であって、
    　自コントローラドメインに隣接するコントローラドメインを特定し、
    　前記隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成し、
    　各コントローラドメイン間のネットワークトポロジを特定し、
    　前記ネットワークトポロジを利用して、前記通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する
    　ことを特徴とする通信制御方法。
  8. 　隣接ドメインを特定する際、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケットを送信し、前記隣接確認パケットを受信したときに当該隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケットを返信し、前記隣接応答パケットを受信して隣接するコントローラドメインを特定する
    　請求項７記載の通信制御方法。
  9. 　各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御するコンピュータに適用される通信制御プログラムであって、
    　前記コンピュータに、
    　自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定処理、
    　前記隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決処理、
    　各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定処理、および、
    　前記ネットワークトポロジを利用して、前記通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御処理
    　を実行させるための通信制御プログラム。
  10. 　コンピュータに、
    　隣接ドメイン特定処理で、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケットを送信させ、前記隣接確認パケットを受信したときに当該隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケットを返信させ、前記隣接応答パケットを受信して隣接するコントローラドメインを特定させる
    　請求項９記載の通信制御プログラム。
PCT/JP2015/000262 2014-02-05 2015-01-21 通信制御システム、通信制御方法および通信制御プログラム WO2015118822A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/111,082 US9998367B2 (en) 2014-02-05 2015-01-21 Communication control system, communication control method, and communication control program
EP15745896.9A EP3104561A4 (en) 2014-02-05 2015-01-21 Communication control system, communication control method, and communication control program
JP2015561200A JP6191703B2 (ja) 2014-02-05 2015-01-21 通信制御システム、通信制御方法および通信制御プログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-020390 2014-02-05
JP2014020390 2014-02-05

Publications (1)

Publication Number Publication Date
WO2015118822A1 true WO2015118822A1 (ja) 2015-08-13

Family

ID=53777637

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/000262 WO2015118822A1 (ja) 2014-02-05 2015-01-21 通信制御システム、通信制御方法および通信制御プログラム

Country Status (4)

Country Link
US (1) US9998367B2 (ja)
EP (1) EP3104561A4 (ja)
JP (1) JP6191703B2 (ja)
WO (1) WO2015118822A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108702326A (zh) * 2016-01-05 2018-10-23 瑞典爱立信有限公司 检测软件定义网络（sdn）中的控制平面循环的机制

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2016137124A (ru) * 2014-02-19 2018-03-22 Нек Корпорейшн Система связи, устройство управления, способ управления связью и программа
KR102117497B1 (ko) * 2017-06-29 2020-06-02 주식회사 케이티 네트워크 인프라 구축 시스템 및 네트워크 인프라 구축 방법
CN111277423B (zh) * 2018-12-04 2022-05-20 中兴通讯股份有限公司 数据中心流量互通方法、装置、设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008505531A (ja) * 2004-06-30 2008-02-21 テレフオンアクチーボラゲット エル エム エリクソン（パブル） マルチドメイン仮想プライベートネットワークにおける接続経路の高速判定方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6556541B1 (en) * 1999-01-11 2003-04-29 Hewlett-Packard Development Company, L.P. MAC address learning and propagation in load balancing switch protocols
EP1847071A4 (en) * 2005-01-26 2010-10-20 Internet Broadcasting Corp B V MULTI-DIFFUSION IN LAYERS AND EXACT ATTRIBUTION OF BANDWIDTH AND PRIORIZATION OF PACKETS
JP5393686B2 (ja) 2007-09-26 2014-01-22 ニシラ， インコーポレイテッド ネットワークを管理する及び安全にするためのネットワークオペレーティングシステム
US20120250496A1 (en) 2009-11-26 2012-10-04 Takeshi Kato Load distribution system, load distribution method, and program
US10244500B2 (en) * 2011-03-30 2019-03-26 Wei Lu Open wireless architecture (OWA) mobile cloud infrastructure and method
US9204207B2 (en) 2011-11-01 2015-12-01 Plexxi Inc. Hierarchy of control in a data center network
US9337931B2 (en) * 2011-11-01 2016-05-10 Plexxi Inc. Control and provisioning in a data center network with at least one central controller
US9306800B2 (en) * 2013-05-10 2016-04-05 Telefonaktiebolaget L M Ericsson (Publ) Inter-domain fast reroute methods and network devices

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008505531A (ja) * 2004-06-30 2008-02-21 テレフオンアクチーボラゲット エル エム エリクソン（パブル） マルチドメイン仮想プライベートネットワークにおける接続経路の高速判定方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
NOBUHIKO ITO ET AL.: "An Efficient Calculation of Passive Type Loop Detection Method and it's Implimentation on OpenFlow-based Network", IEICE TECHNICAL REPORT, vol. 109, no. 448, 25 February 2010 (2010-02-25), pages 31 - 36, XP055219409 *
See also references of EP3104561A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108702326A (zh) * 2016-01-05 2018-10-23 瑞典爱立信有限公司 检测软件定义网络（sdn）中的控制平面循环的机制
CN108702326B (zh) * 2016-01-05 2021-03-19 瑞典爱立信有限公司 检测sdn控制平面循环的方法、设备和非暂时性机器可读介质

Also Published As

Publication number Publication date
US9998367B2 (en) 2018-06-12
US20160344625A1 (en) 2016-11-24
EP3104561A4 (en) 2017-10-18
EP3104561A1 (en) 2016-12-14
JPWO2015118822A1 (ja) 2017-03-23
JP6191703B2 (ja) 2017-09-06

Similar Documents

Publication Publication Date Title
US10230577B2 (en) Packet broadcast mechanism in a split architecture network
EP3474502B1 (en) Reduced configuration for multi-stage network fabrics
US9379975B2 (en) Communication control system, control server, forwarding node, communication control method, and communication control program
US9225641B2 (en) Communication between hetrogenous networks
US20160269289A1 (en) Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
CN110971441B (zh) 多级网络结构的简化配置
US20130322460A1 (en) End-to-end multipathing through network having switching devices compatible with different protocols
JP6191703B2 (ja) 通信制御システム、通信制御方法および通信制御プログラム
WO2017084448A1 (zh) 一种网络系统及网络运行方法
CN102437967B (zh) 报文转发方法和装置
CN105262686B (zh) 一种网络连通性验证方法和装置
US10171306B2 (en) Automatic discovery and provisioning of multi-chassis etherchannel peers
US20150036508A1 (en) Method and Apparatus For Gateway Selection In Multilevel SPB Network
WO2014126094A1 (ja) 通信システム、通信方法、制御装置、制御装置の制御方法及びプログラム
US10574481B2 (en) Heterogeneous capabilities in an overlay fabric
JP2017175522A (ja) ネットワークシステム、制御装置、方法およびプログラム

Legal Events

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

Ref document number: 15745896

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015561200

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15111082

Country of ref document: US

REEP Request for entry into the european phase

Ref document number: 2015745896

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015745896

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE