WO2017068618A1 - Routing control device and network - Google Patents

Abstract

This routing control device is provided with a network control unit for setting the route of a packet in a software defined network (SDN) having a connection relation with other networks, and further provided with a direct flow connection unit for reconstructing the route of a packet so that a packet inputted from another network to the SND network and having had a route set along which the packet is transmitted via a network appliance from an input place where the packet is inputted to the SDN network to an output place where the packet is outputted from the SDN network is transmitted directly from the input place to the output place without going via the network appliance. This configuration allows settings to be changed to a route that does not go via the network appliance, and makes it possible to construct a network using a network appliance which is inexpensive and the processing capacity of which is not high.

Description

Route control apparatus and network

The present invention relates to a route control device and a network for controlling a route of a packet in the network.

In a network system capable of establishing a connection path based on connection identification information such as OpenFlow® (for example, Non-Patent Document 1), a method is known in which a control device (controller) that manages the network system performs this connection path control. Yes. In recent years, this control device has been used in an architecture called SDN (Software Defined Network).

SDN (Software Defined Network) differs from the existing IP (Internet Protocol) network in terms of device configuration and operational management characteristics. The safest approach is to replace the department or build a new one and connect it to an existing IP network and identify each characteristic before developing. In this case, a request to connect the existing IP network and the SDN is generated, and the existing IP network and the SDN must be able to cooperate particularly in an interface and a device redundancy function. On the other hand, it is desired that IP addresses can be managed in units of systems, departments, etc. as in the past.

FIG. 37 shows a configuration example of an existing redundant IP network. This is often used in in-house data centers or bases composed of a plurality of buildings. Each IP network in which a plurality of L2 switches are connected with a router or L3 switch at the top is connected to the backbone switch. When applying SDN, it is the safest way to start by selecting and replacing places with less impact. This is shown in FIG. Here, a combination of SDN and a router is connected. With this configuration, it is possible to link an existing IP network with a redundant function and perform IP address management in an existing manner. There are some SDNs that can virtually configure L3 functions, but the number is small, and connection may not be successful due to differences in vendors between SDNs and existing IP networks. It is.

With this configuration, when normal communication is performed between a terminal (terminal A) ahead of the backbone network and a terminal (server B) in the SDN, the state of the connection path established in the SDN is shown in FIG. Shown in Since the routers 11 and 12 are external devices unrelated to the SDN, communication via the routers 11 and 12 once goes out of the SDN and then returns to the SDN. Therefore, two connection paths are established per communication session (a total of four round trips when counted in one direction). This is the same as the operation when each communication session passes through a network appliance pool in which one or more network appliances shown in Non-Patent Document 2 are arranged. FIG. 7 of Non-Patent Document 2 shows a state where an appliance pool is connected to the SDN. In this configuration, since the communication goes out of the SDN and follows the return path as shown in the right side of FIG. 4 of Non-Patent Document 2, the operation is the same as that shown in FIG.

The conventional network configuration is necessary for normal communication. However, communication packets are always input to the routers 11 and 12 in FIG. 39 and the network appliance in Non-Patent Document 2, which are conventional techniques. Therefore, it is impossible to apply an inexpensive router or network appliance with low performance. However, the development of SDN controllers in OSS (open source software) has progressed, and SDN switches are becoming cheaper, and the routers or network appliances to be applied are expensive. It can be a disturbing factor. In order to reduce the cost of the router or network appliance to be applied, the processing load is reduced by reducing packets passing through the router or network appliance, and it is possible to support routers or network appliances that do not have high processing capacity such as forwarding. It becomes a problem to have a simple network configuration.

The present invention has been made to solve the above-described problem, and reduces the processing load of the router or the network appliance by reducing packets passing through the router or the network appliance, and is inexpensive and does not have a high processing capacity. Another object is to construct a network that can be supported by a network appliance.

The path control device according to the present invention has a connection relationship with another network, and a network control unit that sets a packet path in SDN (Software Defined Network), is input to the SDN from another network, and the SDN A packet that is calculated in its own device through the first path that passes through the network appliance outside the SDN from the input location that is input to the output location that is output from the SDN to the network appliance. And a flow direct connection unit that constructs the second path so as to be transmitted through the second path from the input location to the output location without going through.

According to the present invention, it is possible to reduce the processing load of the router or the network appliance by reducing packets passing through the router or the network appliance, and to construct a network that can be handled by an inexpensive router or network appliance having a low processing capacity. Can do.

The figure which shows the exchange of the routing protocol in the existing IP network. The physical block diagram at the time of connecting SDN to the existing IP network. The logical block diagram of SDN which has a virtual router function. The block diagram which connects SDN in cooperation with the redundancy function of the existing IP network. The block diagram which installed the router which supports an original protocol inside SDN. The logical block diagram of the network comprised by the existing IP network and SDN. The operation | movement figure when the request of a connection is transmitted in the network comprised by the existing IP network and SDN. The network block diagram to which the flow direct connection part 110 in Embodiment 1 of this invention is applied. The figure which shows the flow direct connection function of the flow direct connection part 110 in Embodiment 1 of this invention. The block diagram at the time of replacing the high speed router in Embodiment 1 of this invention with the existing router. The figure which shows operation | movement of the flow direct connection part 110 in Embodiment 1 of this invention. The processing flow which sets the MAC address of the exclusive router in Embodiment 1 of this invention to the flow direct connection part 110. FIG. The figure which shows operation | movement when a communication packet is transmitted from the terminal in the existing IP network in Embodiment 1 of this invention. The processing flow performed with the SDN controller in Embodiment 1 of this invention. The function block diagram of the route control apparatus 120 in Embodiment 1 of this invention. The processing flow performed in the flow direct connection part 110 in Embodiment 1 of this invention. The “post-flow” processing flow performed in the flow direct connection unit 110 according to Embodiment 1 of the present invention. Flow setting information set in each SDN switch IDn in the first embodiment of the present invention. The figure which shows the flow after the direct connection in SDN in Embodiment 1 of this invention. The block diagram in case the SDN controller and the flow direct connection part 110 in Embodiment 1 of this invention are comprised by software, and are operate | moving in the same CPU. The block diagram when the SDN controller in Embodiment 1 of this invention is operate | moving on a different computer. The function block diagram of the route control apparatus 120 in Embodiment 2 of this invention. The figure which shows the processing flow in the flow direct connection part 110 in Embodiment 2 of this invention. The process flow regarding PACKET_IN of the “after” flow performed in the flow direct connection unit 110 according to the second embodiment of the present invention. The function block diagram of the path | route control apparatus 120 in Embodiment 3 of this invention. The figure which shows the processing flow in the flow direct connection part 110 in Embodiment 3 of this invention. The figure which shows the mode of the establishment of the direct connection flow of each of the outward path and the inbound path in Embodiment 3 of this invention. The figure which shows the reconstruction flow in Embodiment 3 of this invention. The processing flow in the bidirectional | two-way direct connection process part 171 of the flow direct connection part 110 in Embodiment 3 of this invention. Each flow setting information of the outward path in Embodiment 4 of this invention. Each flow setting information of the return path in Embodiment 4 of this invention. The block diagram at the time of mounting the flow direct connection part 110 on the computer physically different from the SDN controller in Embodiment 4 of this invention. The process flow in the “after” flow process part 155 in Embodiment 4 of this invention. The process flow which makes the log reception process part 180 the main body in Embodiment 4 of this invention. The function block diagram of the route control apparatus 120 in Embodiment 4 of this invention. The block diagram in the case of receiving a log via the communication interface in Embodiment 4 of this invention. The block diagram of the existing redundant IP network. The network block diagram which connected SDN and IP network. A state of constructing a connection path in the prior art.

Embodiment 1 FIG.
Embodiment 1 of the present invention will be described below.

First, the background that led to the configuration of the present invention will be described. FIG. 37 shows an example of a physical configuration of redundant connection in an existing IP (Internet Protocol) network. In FIG. 37, a total of two devices are prepared, one for each device in the same position, and these are mainly connected in a square shape to constitute a network. Terminals are normally managed in units of IP subnets, and are connected in units of departments, floors, bases, etc. starting from a router / L3 (Layer 3) switch. The L2 switch in the center of FIG. 37 constitutes a backbone network and connects each floor and base. Here, a routing table is constructed by developing the IP subnet information formed by each router and L3 switch by using a dynamic routing protocol. The state of routing protocol exchange is shown in FIG. When each interface or L3 device goes down, the IP subnet information is not expanded from the device, so it is automatically excluded from the destination, and it is possible to avoid the operation of trying to transfer an IP packet to the down destination. . Further, by connecting in a stub shape, it is possible to prevent a phenomenon in which when a single device goes down, a plurality of normal devices adjacent thereto are not substantially used.

Next, FIG. 2 shows an example of a physical configuration when an SDN (Software Defined Network) is connected. In this example, two SDN switches (SW00, SW01), which are positioned on an equal basis, are connected like a pavement from the backbone device. As an SDN, interface and equipment redundancy can be handled without any problems. Here, in the SDN, if the IP address management of the connected server or terminal is performed in the same manner as the existing IP network, the L3 functions such as the router and the L3 switch are also used as the backbone as in the existing IP network of each base. Need to be placed between. For this reason, some SDNs have a virtual router function, and this virtual router function can achieve the purpose of arranging the L3 function. The logical configuration of the SDN having this virtual router function is shown in FIG. FIG. 3 shows a logical configuration, and the physical configuration of the SDN is the same as FIG. Here, a case where there is only one connection with the existing IP network is shown, but a configuration with a plurality of connections is also possible. Since the virtual router is a function that is virtually realized by the SDN controller which is a network control unit, a dynamic routing protocol or the like that operates therein is mounted on the SDN controller. Therefore, as shown in FIG. 3, the virtual router function operating on the SDN controller exchanges IP subnet information with the router / L3 switch of the existing IP network by a dynamic routing protocol, and stores a routing table in the SDN controller. Once constructed, the virtual router can perform IP forwarding processing. Here, the state of the SDN virtual router includes the following.
(A1) Virtual router function not supported (A2) Virtual router function supported but dynamic routing protocol not supported (A3) Virtual router function and standard dynamic routing protocol supported OSS (Open Source Software) There is no particular trend of SDN controllers and vendors from each project. There are some in the SDN controller provided by the vendor in the state (A2). In that case, forwarding is performed by a static routing protocol, and a redundant configuration cannot be supported. However, there is an aspect that the user expects to independently develop addition of a dynamic routing function using OSS. Actually, the SDN controller product in the state (A3) includes an SDN controller in the state (A1) added with OSS router software. In any case, the SDN controller in the state (A1) and the state (A2) applies the virtual router function that has been developed and supported the dynamic routing protocol as the configuration of the state (A3). Connect to the network. As a result, it becomes possible to link and maintain the existing IP network and the redundant function.

Here, the following is particularly applicable as a standard dynamic routing protocol. These are currently IPv6 compatible as RIPng and OSPFv3, respectively.
(a) RIP (IETF RFC2453-Routing Information Protocol Version 2)
(b) OSPF (IETF RFC2328-Open Shortest Path First Version 2)
In particular, there is EIGRP, which is expected to be widely used due to the large share of equipment in corporate IP networks.
(c) EIGRP (IETF draft-Enhanced Interior Gateway Routing Protocol)
The above (c) is essentially a public specification because a development vendor submitted a draft to the Internet Engineering Task Force (IETF) in 2013, but at this time software other than the development vendor provides the protocol. It does not hold, and it seems that the situation of the original protocol has not changed. Therefore, in the prior art, it is assumed that the existing IP network uses the above (a) or (b). However, many vendor routers to which a unique protocol is applied support the standard protocol, and can be linked by setting both protocols in the router. As a result, it is possible to connect the SDN while linking with the redundancy function of the existing IP network. This is shown in FIG.

In addition to this, it is conceivable to enable communication by installing a vendor router that supports a unique protocol inside the SDN. Here, the SDN virtual router is unnecessary. An example of the configuration is shown in FIG. In this figure, two routers 101 and 102, which are one form of network appliance, are installed for redundancy support, and the two interfaces are connected to different SDN switches. Further, each interface is a trunk connection of two VLANs (Virtual Local Area Network), and each interface is connected to a VLAN on the existing IP network side and a VLAN on the terminal server side in the SDN. The logical configuration of the network is shown in FIG. A description of the logical configuration of FIG. 6 will be described later. Also, in order to cope with high-speed and large-volume communication such as communication between servers in the SDN, the router applied here must be high-speed. It is desirable to be able to perform forwarding by hardware while maintaining the functionality of a router as performed by an SDN switch.

As described above, the SDN controller state (A3) in the configuration of FIG. 4 or the SDN controller states (A1), (A2) and (A3) in the configuration of FIG. It is possible to connect the existing IP network and the SDN while maintaining the redundant configuration. However, the configuration of FIG. 4 has the following problems.
(i) Since it is also an application of a function that is not often performed, such as changing the setting of an existing router and converting the routing protocol, prior verification is required.
(ii) Construction with network outage is required to change the above settings.
(ii) can be handled without any problems if the procedure is followed.However, the verification of (i) can be done by considering the test items, building the verification environment, and other factors such as the required man-hours and period. And a service company (system integrator, SIer) in charge of operation.

In the configuration of FIG. 5, which is another solution, setting change is not necessary, but there is the following problem.
(iii) Since all communications go through a general router that has nothing to do with SDN, and in particular does not have a function to cooperate with, there is a possibility that the application of functions unique to SDN may be hindered.
(iv) At least, there are many requests for high-speed transfer in the SDN, so the router is also required to be high-speed, and it is necessary to apply an expensive router.
Comparing the cost of verifying that there is no problem and the cost of purchasing a new device provided by a vendor, the cost of purchasing the device is generally likely to be lower. Therefore, although the configuration of FIG. 5 is more convenient than the configuration shown in FIG. 4, the problems (iii) and (iv) occur as described above.

Here, since it is necessary as a premise for the following description, the procedure for establishing the SDN connection path in the configuration of FIG. First, FIG. 6 which is an example in which FIG. 5 is replaced with a logical configuration will be described. The high-speed router shown in FIG. 6 has a configuration in which each high-speed router connects the IP subnet of the terminal / server group directly below the SDN and the backbone subnet, similarly to the virtual router shown in FIG. Each interface of the high-speed router is a trunk connection of two VLANs, one is connected to the VLAN on the existing IP network side, and the other is connected to the VLAN of the terminal / server accommodated by the SDN. This is because, in the case of a minimum configuration with two router interfaces to be applied, the primary failure (one interface or one device is down) causes other active interfaces or devices to be practical. This is a configuration for preventing the system from being used in the future. For example, even if IF-1 of the router 102 is down, the router 102 can perform the forwarding function because it is connected to the backbone network and the terminal / server in the SDN by IF-2. Even when the router 101 goes down, the router 102 is connected to each VLAN (VLAN 311, VLAN 312, VLAN 331, and VLAN 332) through the IF-1 and IF-2 trunk connections without any problem in the IP network configuration. Therefore, it is possible to transfer packets between the VLANs, and the transfer environment is necessary and sufficient. If each high-speed router has four or more interfaces, there is no necessity for trunk connection, and the connection configuration is not limited to that shown in this example. When there are more than two VLANs on the existing IP network side or on the terminal side directly accommodated by the SDN, the basic configuration is to increase the number of trunk VLANs of each interface and connect them. When the number of interfaces of the high-speed router is larger than 2, this is not limited, and it is appropriate to design for a more effective redundant configuration and traffic distribution.

From the configuration of FIG. 6, when a terminal / server in the existing IP network and a terminal / server in the SDN communicate, it always passes through one of the two high-speed routers. Therefore, the communication between the terminal / server in the existing IP network and the terminal / server directly under the SDN always passes through the SDN twice through the high-speed router. Therefore, two connection paths are established for one communication connection between these (a total of four connection paths in one direction).

This is shown in FIG. For simplicity, only one direction is shown here. This is an operation when the terminal A transmits a connection request (for example, TCP-SYN) to the server B. When the request packet transmitted from the terminal A arrives at the router 100, the router 100 searches the routing table held by itself for the IP address of the packet destination, and obtains the IF-1 of the router 102 as the next destination as a result. (IP forwarding process). Here, the next transfer destination candidates for the IP address of the router 100 are IF-1 and IF-2 of the router 101, and IF-1 and IF-2 of the router 102, but connection information (here, TCP / Generally, the load is distributed according to a certain algorithm using (IP header information). In this load distribution function, the same transfer destination is always selected for a packet of one connection so that the order of the packets is not changed. In FIG. 7, IF-2 of the router 102 is selected as a result of the selection. In the SDN of FIG. 7, it is assumed that the VLAN on the existing IP network side of IF-2 of the router 102 is connected to IF-1 of the SDN switch SDNS211. Therefore, when the router 100 transfers to the IF-2 of the router 102, the data is input to the IF-1 of the SDNS 211 that is one of the entrances to the SDN. The SDN switch SDNS 211 searches the input packet in the connection path table, and if there is no hit, notifies the SDN controller SDNC that a connection packet having no entry has been input. In response to this, the SDNC searches the connection destination interface of the destination MAC (Media Access Control) address and calculates the route, finds that the destination is the IF-1 of the SDN switch SDNS 222, and each SDN switch in the SDN. The connection path is set, the connection path 103 shown in FIG. 7 is constructed, and the request packet is transferred to IF-2 of the router 102. Subsequently, as a result of subjecting the request packet to the IP forwarding process, the router 102 has found that the destination IP address is in the same subnet as the IP address of the IF-1 of the router 102. Send from. Since the destination IP address is that of IF-1 of server B, the request packet arrives safely at IF-1 of server B. The SDN switch SDNS 221 searches the connection path table for the packet input from IF-1, and notifies the SDN controller SDNC to that effect because it does not hit. The SDNC searches the connection destination interface of the destination MAC address of the packet and calculates the route, finds out that it is connected to IF-1 of the SDN switch SDNS231, and connects the connection path to each SDN switch in the SDN. Settings are made, the connection path 104 shown in FIG. 7 is constructed, and the packet is transferred to IF-1 of server B. In this way, the SDN controller SDNC always constructs two connection paths and passes through the SDN. This flow is the same in communication between a terminal and a server having different IP subnets in the SDN. Note that the router interface is a VLAN trunk connection, and the existing IP network and server interfaces are not. Therefore, the VLAN tag is added in S1 and the VLAN tag is deleted in S2, using the SDN switch on each route. It is set as follows. In addition, this is an example when a connection establishment request is made from a terminal in an existing IP network to a server under SDN, but in the reverse case, the order and direction only change, as described here, It is the same that two connection paths (flows) per one direction and a total of four connection paths per TCP / IP 1 connection (bidirectional) are built in the SDN. Here, two connection paths are entered through the network appliance outside the SDN from the IF-1 of the SDNS 211 that is one of the entrances to the SDN to the output location that is output from the SDN. The path constructed by these two connection paths is called the first path.

In the end, the configuration shown in FIG. 5 solves the problem of connecting the existing IP network and the SDN with the redundant function in any state of the above-mentioned (A1) to (A3). Can do. Therefore, it is the most effective approach. Therefore, the following is applied as means for solving the problem in the configuration of FIG.
Instead of a high-speed router, a dedicated router for dynamic routing processing, which is inexpensive and supports a dynamic routing protocol as a function but has a low IP forward processing capability, is arranged.
b. Directly connect the connection paths established via the high-speed router immediately after establishment, thereby avoiding the data packet forwarding processing at the router for exclusive use of dynamic routing.
Problem (iv) can be solved by applying means a and b. Since the problem (iii) is eventually replaced with the communication closed to the SDN, it is possible to apply the function unique to the SDN. That is, both (iii) and (iv) are solved.

Summarized below, the application of a. And b. Above makes it possible to solve the problems and fulfill the purpose in any of the states (A1) to (A3) indicating the mounting status of the SDN controller.

FIG. 8 shows a state in which the connection path direct connection function unit (hereinafter, flow direct connection unit) 110 is applied. FIG. 8 illustrates a configuration in which the route control device 120 includes an SDN controller that is a network control unit and a flow (connection path) direct connection unit 110. In the configuration shown in FIG. 8, it is possible to link with a redundant function of an existing IP network not only by the vendor but also by a dynamic routing protocol as well as a standard, and a router as one form of network appliance is inexpensive and the existing IP network side There is no need to change the setting and no test evaluation is required. The flow direct connection unit 110 is applied as a part of the function of the SDN controller. However, if possible, the process itself is in the same network appliance (or computer / PC) as the SDN controller through an API (Application Programming Interface). May be on other network appliances. This is up to the implementation. Here, the dedicated router for dynamic routing processing is a low-cost router that does not have high forwarding processing capability and supports the dynamic routing protocol at a minimum. The packet forwarding process is only required to forward two or three packets at the time of establishing the connection path without delay. There is a possibility that the price can be reduced by one or two digits compared to a high-speed router.

Here, the outline of the flow direct connection part 110 is shown. As shown in FIG. 7, a packet transmitted from a terminal in an existing IP network to a server in the SDN is relayed by a dedicated router for dynamic routing processing and reaches a server in the destination SDN. Therefore, in order to once go out of the SDN and input again to the SDN, two one-way connection paths (flows) are constructed as shown in FIG. At this time, the flow direct connection unit 110 includes an input location to the SDN (SDN switch SDNS 211 and its interface IF-1) of a connection path (first connection path: “previous” flow) addressed to the dedicated router for dynamic routing processing, A connection path (the SDN switch SDNS 231 and its interface IF-1) output from the SDN of the connection path (second connection path: “after” flow) from the router to the server is captured and the connection path connecting them is shown in FIG. Build as shown in). At this time, since the router rewrites the MAC address of the packet, one of the SDN switches on the connection path in FIG. 9B performs connection path setting including the rewriting. In general, the connection path to be rewritten is set at the first or last SDN switch on the route, and it is preferable to fix to either of them when mounting. Here, as shown in FIG. 9 (a), the route that once passes through the network appliance outside the SDN from the input location input to the SDN to the output location output from the SDN is defined as the first route. In contrast, a route from the input location to the output location without going through the network appliance as shown in FIG. 9B is referred to as a second route.

Furthermore, the following method is specifically applied to identify a connection path having a “previous relationship” passing through a router. First, the connection paths in the “previous relationship” have the following relationship.
(B1) The TCPUDP / IP header information is the same, but the MAC address is different.
This is because the dedicated router for dynamic routing processes performs IP forwarding processing on communication packets, so even if the L2 transmission / reception address (MAC address) changes, the transmission / reception address information of the L3 and higher layers does not change. That is, since the dedicated router for dynamic routing processing is a connection relayed by IP, the following conditions are satisfied for the IP address and the MAC address.
(B2) The IP address of the router dedicated to dynamic routing is not included in the transmission / reception IP address.
(B3) Either the sending or receiving MAC address is for a router dedicated to dynamic routing,
"Front" connection path: destination MAC address "Back" connection path: source MAC address.

The information to be confirmed in the above (B1) to (B3) is all packet header information, and is information that can be acquired by the SDN controller in the existing SDN. Therefore, the identification can be performed by the SDN controller, and there is no function required for the SDN switch, and no function addition to the SDN switch is required.

Thus, the most basic equipment and functional configuration of the first embodiment are shown in FIG. The configuration is characterized in that the route control device 120 includes an SDN controller which is a network control unit and a flow (connection path) direct connection unit 110. Other than this, the SDN, the devices constituting the existing IP network, and the dedicated router for dynamic routing processing (hereinafter referred to as a dedicated router) are existing. The logical configuration in this case is shown in FIG. FIG. 10 is obtained by replacing the high-speed router of FIG. 6 with an existing router (a dedicated router for dynamic routing processing). In addition, the SDN controller itself, an OSS or a commercially available one added with a function using a public software API (Application Programming Interface) is included. The two interfaces of each dedicated router are set as VLAN trunks as shown in FIG. 10, and are connected to the VLANs of terminals and servers directly accommodated by the existing IP network and SDN. This is a minimum configuration in which one down does not involve another device or interface in each of the interface down and the device down.

First, a router is placed in the SDN, and each router in the existing IP network, the terminal / server that the SDN accommodates, ARP (Address Resolution Protocol), DHCP (Dynamic Host 、 Configurable Protocol), and other basic IP procedures You need to be able to communicate. This can be dealt with by the basic function of SDN. Although it may be necessary to change the default settings of the SDN, no new functionality needs to be added for this purpose. If it is physically connected and logically configured as shown in FIG. 10 and the router setting (IP address, dynamic routing protocol, etc.) is performed normally, the redundant function by dynamic routing of the existing IP is achieved. A corresponding network is established and communication is possible. Up to this point, existing technologies can be used. However, if the flow direct connection unit 110 is not operating, the dedicated router performs IP forwarding of all packets, and a large processing load is applied, and if the number of communication requests increases, the network breaks down.

Subsequently, an operation of the flow direct connection unit 110, which is a feature of the present embodiment, will be described. The function will be described with reference to FIG. FIG. 11 shows a state in which communication is performed between a terminal and a server at the end of an existing IP network. When a packet is transferred from the terminal to the server, a configuration in which there is an SDN before and after the dedicated router Shown along the flow. The gray background indicates that these are one SDN and is folded back into one SDN before and after the dedicated router. The interface connected to the dedicated router corresponds to a total of four black thin lines drawn from the router 111 and the router 112 which are one form of the network appliance of FIG. Thus, it is not always physically different. The SDN controller is equipped with a connection path direct connection function.

First, the flow direct connection unit 110 has two types of information that are set automatically or manually. One of the information is the priority of the flow set by the flow direct connection unit 110. If about 10000 is set as a default, there is no problem. For the other information, the following two settings are possible.
(C1) IP address and MAC address of each relay interface of the dedicated router
(C2) The ID and interface number of the SDN switch that the dedicated router directly accommodates each relay interface, and the IP address of each relay interface of the dedicated router

The correspondence of each information is shown in FIG. For implementation, it is necessary to adopt at least one of them. Both are good. Although it is considered difficult to automatically register an IP address, the corresponding MAC address or SDN connection location can be automatically registered by referring to information held by the SDN controller. . That is, the IP address is manually registered, and the corresponding MAC address or accommodation location (SDN switch ID and interface number) is automatically registered. In particular, an OSS (Open Source Software) SDN controller often has a corresponding API. In the following description, (C1) is adopted and all the registration means are manual.

First, the MAC address of the router is obtained from the console of the dedicated router and others, and is set in the flow direct connection unit 110 together with the IP address set for the corresponding interface. In setting, the IP address and the MAC address may not be associated. The setting method depends on the implementation, and there are means such as setting from a dedicated console, setting on a dedicated Web page, or writing in a setting file that the flow direct connection unit 110 refers to when starting itself. This completes the basic preparation. FIG. 12 shows a processing flow when setting in the flow direct connection unit 110. The flow direct connection unit 110 first reads the IP address of the interface used for relaying the dedicated router from the flow direct connection function setting file and stores it inside (S1201), inquires the SDN controller using the IP address as a key, and corresponding MAC An address is acquired and stored internally (S1202).

Subsequently, an operation when a TCP (Transmission Control Protocol) / IP or UDP (User Datagram Protocol) / IP communication packet is actually transmitted from a terminal in the existing IP network will be described with reference to FIG. The procedure is the same for both TCP and UDP, but it is shown as a widely used TCP / IP packet. The following description is based on the assumption that OpenFlow, which is currently most used as an interface specification between the SDN controller and the SDN switch. Therefore, unless otherwise specified, the SDN switch corresponds to an “OpenFlow switch”, the SDN controller corresponds to an “OpenFlow controller”, and the connection path corresponds to an “OpenFlow” flow.

First, the communication packet arrives at one interface (SDNS 211, IF-1) of one SDN switch of the SDN. The SDN switch searches its own flow table, and if it hits, processes it accordingly, but if it does not hit, generates a PACKET_IN message in which the packet is posted and transfers it to the SDN controller (S1). In the SDN controller, the SDN switch and interface of the output destination are specified from the input SDN switch and interface number indicated in the PACKET_IN message and the destination information of the packet, and the FLOW_MOD message is constructed and transmitted to the necessary SDN switch. The flow is set (S2). Then, the communication packet generated by generating the PACKET_OUT message is transferred to the output destination of the SDN (S3). This process is the same in the flow construction after passing through the router, and S1, S2, and S3 correspond to S4, S5, and S6, respectively. FIG. 14 shows a processing flow performed by this SDN controller. In the SDN controller, when PACKET_IN arrives, normal processing by the SDN controller is performed. Of the flows in the “front-rear relationship”, S1 to S3 correspond to “front” and S4 to S6 correspond to “rear”. Note that it is difficult for the SDN controller and the flow direct connection unit 110 to know from the beginning whether the PACKET_IN is one of the “before and after” flows. Therefore, the implementation of the flow direct connection unit 110 is a process in which processing for determining which PACKET_IN is used is interwoven as necessary. In the following, processing contents that do not assume whether the PACKET_IN is S1 or S4 in FIG. 13 are shown. Therefore, this can be considered as an example of the processing content of the flow direct connection unit 110 as it is.

FIG. 15 is a functional configuration diagram of the flow direct connection unit 110, the SDN controller, and the path control device 120 including the flow direct connection unit 110 and the SDN controller according to the first embodiment. Further, FIG. 16 shows processing performed in the flow direct connection unit 110 of the first embodiment, and FIG. 17 shows “after” flow processing performed in the flow direct connection unit 110. When the flow direct coupling unit 110 receives the PACKET_IN (corresponding to S1 or S4 in FIG. 13) or the constructed flow information (corresponding to PACKET_IN) copied by the SDN controller in the PACKET_IN receiving unit 150, it is posted in the PACKET_IN. The transmission / reception IP address of the communication packet is extracted (S1601). Further, it is checked whether the transmission / reception IP address of the input packet matches the IP address of the dedicated router registered in the setting information 152 set by the flow direct connection function setting processing unit 151 (S1602). If there is a match, the process is canceled because it is not subject to direct flow connection. If there is no match, the transmission / reception MAC address of the communication packet posted in PACKET_IN is extracted (S1603). Whether the extracted MAC address matches that of the dedicated router registered in the setting information 152 is checked in the order of the destination MAC address and the source MAC address (S1604, S1605). If it is not the target, the process is canceled. In the case of the flow direct connection processing target, the processing contents are different as shown below depending on whether the MAC address matching the dedicated router is the destination MAC address or the source MAC address of the input packet.
When the destination MAC address matches the dedicated router Since it corresponds to “previous” in the “previous” and “previous” relationships, “front” of the flow direct connection unit 110
The process is completed by registering in the previous flow entry table 154 which is a list of “previous” flows held by the flow processing unit 153 (S1606). The contents to be registered include TCP / UDP / IP / MAC header information for later retrieval and the SDN switch I input to the SDN.
D and interface number.
When the source MAC address matches the dedicated router Since the flow corresponds to “after” among the flows having the “before / after” relationship, the “after” flow processing unit 155
Searches for the corresponding "previous" flow in the previous flow entry table 154, and if found, extracts the entry, deletes it from the previous flow entry table 154, enters the direct processing, and if not found, completes the processing there To do. Since the MAC address match is confirmed in the order of destination and source, the processing may be completed here.
When searching the previous flow entry table, information necessary for identifying the TCP / IP connection is used. Specifically: The following are all the same in the flow in the “previous relationship”.
Frame type (= 0x0800), send / receive IP address,
IP protocol (= 6: TCP or 17: UDP), transmission / reception L4 port number (L4:
(TCP or UDP)
The direct connection process is the easiest to construct a new one rather than modifying the already constructed "before and after" flow. In fact, since the physical configuration is as shown in FIG. 8, the SDN switches immediately before and immediately after the dedicated router in FIG. 13 are not necessarily the same. If they are the same SDN switch, it is only necessary to change the flow in the SDN switch. However, if the SDN switch is different, the flow becomes complicated, and a problem such as an excessive increase of relayed SDN switches occurs. Therefore, it is easier to reconstruct the flow connecting the entrance from the terminal to the SDN and the exit to the server. This is also convenient for recalculation in connection with functions such as QOS and load distribution provided separately from the flow direct connection unit 110 by the SDN controller.

Here, the procedure after searching the previous flow entry table and finding a match is shown. This is processing related to PACKET_IN of the “after” flow. FIG. 17 shows a processing flow related to PACKET_IN of the “after” flow performed in the flow direct connection unit 110. The flow direct connection unit 110 first searches the previous flow entry table with the TCP / IP header information (S1701). If there is information (PACKET_IN message) of the “previous” flow that has been searched and hit (S1702), the matched entry information is extracted and the entry is deleted from the table (S1703). Then, the input SDN switch ID and interface number are extracted from the matched entry information (S1704), and the destination MAC address is extracted from PACKET_IN of the subsequent flow (S1705). Further, the output destination inquiry processing unit 156 makes an inquiry to the SDN controller by using the destination information (MAC address) of the packet posted in the PACKET_IN that is currently processed as a key, and outputs the SDN switch ID and the interface. A number is acquired (S1706). If unsuccessful, the process ends here (S1707). Here, the following functions relating to the inquiry and PACKET_IN are functions essential to the SDN controller. The flow direct connection unit 110 uses the API of the corresponding function.
(D1) SDN switch ID and interface number of PACKET_IN message In the PACKET_IN message, the SDN switch ID and interface number entered in the packet included in the message are defined as required fields.
(D2) Obtain SDN switch ID and interface number with destination MAC address as key SDN controller MAC address and SDN switch ID / interface number of terminal (any device) directly connected to SDN managed by itself The table is held. This is also the basic function of the SDN switch as an L2 switch, and without this, a flow cannot be constructed. In mounting, flow direct connection part 1
It is also possible that 10 retrieves a correspondence list of MAC addresses, SDN switch IDs, and interface numbers.
(D3) Calculate the route in the SDN from the SDN switch ID and interface number at both ends. SDN switch ID and input interface number that the communication packet has input to the SDN.
And the output destination SDN searched by the function (D2) from the destination information of the communication packet.
The route is calculated from the switch ID and output interface number information, and the SD on the route is calculated.
It is possible to obtain the N switch and the interface number that becomes the entrance and exit of each.
This is also an essential function for building a flow.
When the flow direct connection unit 110 succeeds in acquiring the output destination switch ID and interface number in S1706 (S1707), the input SDN switch ID and interface of the “previous” flow are input locations, and the output SDN switch ID and interface of the “rear” flow are input. Is output to the SDN controller from the route inquiry processing unit 157 (S1708), and when the inquiry is successful (S1709), each SDN switch on the route is referred to based on the acquired route and flow information. Flow setting is performed via the flow setting transmission unit 158 and the SDN controller (S1710). Since all the routes have been found through such processing, a flow is set for each SDN switch on the route. That is, a route is calculated in the route control device 120, and finally, each SDN switch is set based on the calculated route.

Basically, the following list is obtained as a result of the above (D3). The subscript n below is an integer from 1 to N, which indicates the nth SDN switch on the path.
SDN switch IDn, input interface number n, output interface number n
Here, since the communication packet actually passes through the router, it is necessary to rewrite the transmission / reception MAC address on the way. It is not essential to include the MAC address as matching information when setting a flow, but it is better to include it when considering multi-tenant. Here, it is assumed that the SDN switch at the most downstream position on the route is rewritten. In this case, the flow set for each SDN switch IDn is as shown in FIG. In FIG. 18, “interface” is expressed as “IF”.

Here, the order of setting change is performed from the downstream. When this is set from upstream, the next input communication packet is hit there and the SDN switch forwards according to the flow. However, depending on the timing of the packet, the setting is completed for all SDN switches on the route. However, in this case, a meaningless PACKET_IN is transmitted from the SDN switch on the route. If the setting is made from the downstream, there is basically no influence on others, and even if a hit occurs in the middle of the setting, it is safely transferred to the destination. Here, the matching information other than the input interface is rewritten as follows.
Frame type (= 0x0800), send / receive MAC address, send / receive IP address,
IP protocol (= 6: TCP or 17: UDP),
Transmission / reception L4 port number (L4: TCP or UDP)

Since other than the sending / receiving MAC address does not change in the flow before and after, it is common from the beginning to the end as described above, but the sending / receiving MAC address is converted from the communication packet (A) in FIG. 13 to (D). That is the rewriting of the MAC address performed at the most downstream. Generalizing the header conversion performed here is that the header of the communication packet (A) may be changed to the header information of (D) by the processing in the flow direct connection unit 110. This includes, for example, when the VLAN tag is on one side and not on the other, or the value changes. As described above, since the headers of L3 and higher do not change, the L2 header including the VLAN tag and the like is converted from the communication packet (A) to (D).

In addition, I will touch on the priority of flows. It is possible to define the priority for matching for each flow, and the flow that the SDN controller dynamically sets itself, such as the setting of “before and after” flow, is usually higher than the fixed one. A flow in which an external function that is not an SDN controller such as the current flow direct connection unit 110 is set anew is generally set to a higher priority in order to make it hit here. The flow direct connection unit 110 also needs to have a higher priority than that dynamically set by the SDN controller, including the reasons described later. The priority is an integer value of 16 bits, and the priority of the dynamic flow is generally the first half value. If the flow direct connection part 110 is set to a value of 10,000 or more, it is considered that there is usually no problem. Since this is due to the implementation of the SDN controller, confirmation is required at the time of setting.

By the above, the flow in SDN shown in FIG. 19 is finally constructed. This is a flow that does not pass through a dedicated router and is consistent with the IP network. Note that the “before” and “after” flows constructed by the SDN controller itself shown in FIG. 13 are not used when the flow in FIG. 19 is constructed, and each SDN switch is deleted after a certain time-out. For example, the SDNS 211 is sure to hit both the “previous” flow and the direct connection flow of FIG. 19 in the flow entry search when the corresponding communication packet is input, but the direct connection flow has higher priority as described above. Therefore, the search result is always a direct connection flow. Therefore, the “previous” flow is not used, and the SDN switch itself deletes after a timeout.

The flow direct connection unit 110 is a software program and is usually stored in a nonvolatile memory such as an external storage device. Then, under an appropriate OS, the CPU reads the program from the external storage device and develops the program on a RAM (Random Access Memory), and the operation is started as a process. When the operation is started, the setting file saved in the external storage device is read, and settings are made for the flow direct connection unit 110 itself. The setting includes IP address information, MAC address information, and priority of the dedicated router. The setting file is, for example, a text editor generally attached to the OS, manually edited via an input / output device, and saved in the external device. Each table handled by the flow direct connection unit 110 is normally developed on the RAM to ensure the maximum processing speed.

FIG. 20 shows a configuration when the SDN controller is also configured by software and is operating within the same CPU 190. The SDN controller and the flow direct connection unit 110 send and receive information such as commands via the API / OS (Operating System) in the CPU 190. The program of the present invention is stored in the RAM 191. FIG. 21 shows a case where the SDN controller is a network appliance but is running on a different computer. In this case, the API is connected to the OS and further to the SDN controller 201 via the communication interface 200, and sends and receives information such as commands.

In this embodiment, although described as an IP router, this embodiment can be applied to any gateway-type network appliance (a method of transferring between devices while rewriting the MAC address) that can fulfill its purpose in the early stages of communication. Is possible. Since the FW (Firewall) has the most general configuration in which the FW processing is completed when a packet is passed, the embodiment shown here can be applied as it is. If it is necessary to determine that transmission is possible only after a complicated filtering process that requires exchange of several packets, PACKET_IN processing is performed, but FW log information (indicating completion of transmission processing, (Including connection information) as a trigger of the flow direct connection unit 110. In order for the flow direct connection unit 110 to receive the log, the system in which the flow direct connection unit 110 operates is specified as the destination of the syslog function normally provided by the FW device, and the flow direct connection unit 110 reads the syslog message. The following means are applicable.

Each unit in the flow direct connection unit 110 shown in FIG. 15 is also called a CPU (Central Processing Unit, a central processing unit, a processing unit, a processing unit, a microprocessor, a microcomputer, a processor, and a DSP that executes a program stored in a memory. ). Here, the flow direct connection unit 110 includes a receiving device, a processing circuit, and a memory. The function of each unit in the flow direct connection unit 110 is realized by software, firmware, or a combination of software and firmware. Software and firmware are described as programs and stored in a memory. The processing circuit reads out and executes the program stored in the memory, thereby realizing the function of each unit. These programs can also be said to cause a computer to execute the functions of the respective units in the flow direct connection unit 110. Here, the memory corresponds to, for example, a nonvolatile or volatile semiconductor memory such as RAM, ROM, flash memory, EPROM, or EEPROM, a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, a DVD, or the like. To do.

As described above, the route control device according to the present embodiment has a connection relationship with another network, and is input to the SDN from the network control unit that sets the route of the packet in the SDN (Software Defined Network) and the other network. In addition, there is a packet in which the first route that once passes through the network appliance outside the SDN from the input location input to the SDN to the output location output from the SDN is calculated in the own device. And a flow direct connection unit 110 for constructing the second route so as to be transmitted through the second route from the input location to the output location without going through the network appliance. . With this configuration, it is possible to reduce the processing load on the router or the network appliance, and it is possible to configure a network that can be handled by a router or network appliance that is inexpensive and does not have a high processing capacity.

In the route control device according to the present embodiment, the SDN may not have a virtual router function. With this configuration, even when the virtual router function is not provided, appropriate route setting can be performed at low cost.

In addition, the network control unit calculates the first route and sets the first route for the SDN, and the flow direct connection unit 110 sets the second route instead of the first route for the SDN. It is characterized by setting. In this way, for the route constructed by the network control unit, the flow direct connection unit 110 is configured to reset the necessary route, and by adding the flow control unit to the conventional network control unit, It is possible to smoothly incorporate the flow direct connection function.

In the present embodiment, the case where the routers 111 and 112, which are one form of network appliances, are mainly described. However, if the network appliance is an L3 switch, a router, or an FW (FireWall), Similar effects of the invention can be obtained.

Further, in the present embodiment, the flow direct coupling unit 110 identifies whether or not the input packet input to the SDN is a target packet for constructing the second route, based on the header information of the input packet. It is characterized by that. With this configuration, packets that pass through the network appliance can be extracted from the input packets, and it is possible to perform processing efficiently by performing reconfiguration processing only on packets that require reconfiguration. Become. At that time, by using a MAC (Media Access Control) address as header information, it is possible to accurately grasp packets passing through the network appliance and efficiently extract packets that need to be reconfigured. .

Further, in the present embodiment, the flow direct connection unit 110 does not match a transmission / reception IP (Internet Protocol) address included in the input packet with an IP address of a router included in the network appliance, and the destination MAC included in the input packet. (Media | Access | Control) address matches the MAC address of the router contained in the said network appliance, and the transmission origin MAC address which the said input packet has when the input packet is again input into SDN via the said network appliance is said network When the MAC address of the router included in the appliance matches, it is determined that the input packet is a target packet for constructing the second route. As described above, by using the IP address and the MAC address, it is possible to efficiently extract a packet passing through the network appliance.

Further, in the present embodiment, the flow direct connection unit 110 outputs the header information that the target packet for constructing the second route has before reaching the network appliance, and the target packet for constructing the second route outputs the header information. It is characterized in that rewriting is performed using header information that is included when output from a location. With such a configuration, a route passing through the network appliance can be smoothly changed to a direct connection flow.

Further, the present embodiment includes a network to which this routing control device is applied. By using this network configuration, it is possible to reduce the processing load on the router or the network appliance, and it is possible to configure a network that can be handled by a router or network appliance that is inexpensive and does not have a high processing capacity.

Embodiment 2. FIG.
The basic configuration of the second embodiment is the same as that of the first embodiment, but the processing procedure in the flow direct connection unit 110 and the response to PACKET_IN in the SDN controller are different from the first embodiment.

First, the processing of the SDN controller for PACKET_IN will be described. In the first embodiment, normal processing is performed by the SDN controller in parallel with passing PACKET_IN to the flow direct coupling unit 110, but here, the flow direct coupling unit 110 completely intercepts and the SDN controller performs processing of PACKET_IN. The configuration cannot be implemented. For this reason, the “before and after” flow construction performed by the SDN controller is not performed. Specifically, steps S2 and S5 are not performed in the flow of FIG. In this case, the flow direct connection unit 110 needs the following functions.
(E1) Operation when PACKET_IN communication packet is not subject to direct flow processing The simplest procedure is to return the PACKET_IN message again to the processing location that has been intercepted from the SDN. Subsequent processing can be completely delegated to the SDN controller. There is an SDN controller that provides an API for receiving PACKET_IN, which is synonymous with passing this API.
(E2) Acquisition of output destination SDN switch interface and generation / transmission of PACKET_OUT When the flow direct connection processing target is executed, each process of the flow direct connection unit 110 is performed, and then P
The packet listed in ACKET_IN must be transferred to the output destination SDN switch and interface, and a procedure for generating a PACKET_OUT message and transmitting it to the SDN switch is required. This needs to be added to both the "before" and "after" flow processes. On the other hand, the acquisition of the output destination SDN switch and interface is performed in the last processing procedure of the “after” flow.
Also add to the end of the flow process. PACKET_OUT message is PACKET
Replace the communication packet listed in _IN as it is, specify the output destination SDN switch and interface, and send it to the SDN switch.

By applying these differences, the flow shown in FIG. 19 can be constructed without actually constructing the “before and after” flows. FIG. 22 is a functional configuration diagram of the flow direct connection unit 110, the SDN controller, and the path control device 120 including the flow direct connection unit 110 and the SDN controller according to the second embodiment. FIG. 23 shows a processing flow in the flow direct connection unit 110 in the second embodiment. In FIG. 23, processes S2201, S2202, S2203, S2204, and S2205 are newly inserted into the process flow of FIG. 16 of the first embodiment. Specifically, when the destination MAC address matches that of the dedicated router (S1604), the PACKET_IN receiving / returning unit 160 extracts the destination MAC address from the PACKET_IN information (S2201), and uses the MAC address as a key to the SDN controller. The inquiry and output destination SDN switch and interface are acquired (S2202). If the acquisition is successful (S2203), the PACKET_OUT transmission unit 161 generates PACKET_OUT and transmits it to the output destination SDN switch (S2204), and registers the PACKET_IN information in the previous flow entry table (S1606). On the other hand, if it is determined as a result of the determination in S1602 and S1605 that it is not a processing target, the PACKET_IN is returned to the SDN controller before returning to the event waiting state (S2205).

FIG. 24 shows a processing flow related to PACKET_IN of the “after” flow performed in the flow direct connection unit 110 of the second embodiment. In FIG. 24, process S2301 is newly added to the process flow of FIG. 17 of the first embodiment. Specifically, the SDN controller is inquired about the path using the input SDN switch ID and interface of the “before” flow as the input location and the output SDN switch ID and interface of the “after” flow as the output location (S1708), and the output SDN switch If the interface is successfully acquired (S1709), PACKET_OUT is generated and transmitted to the output destination SDN switch (S2301), and the flow setting is performed for each SDN switch on the path based on the acquired path and flow information. Implement (S1710).

Although it is necessary to add the procedures (E1) and (E2) described above, since the flow is constructed once, the following efficiency can be achieved.
Route calculation: 3 times in total ⇒ 1 time Flow setting: 3 flows in total ⇒ Because there is a part that overlaps 1 flow, it does not become 1/3, but it is considered to be about 1/2 at the maximum, but both are calculated Since the amount of processing is large, it is effective in reducing the processing load of the SDN controller.

In the second embodiment, the flow setting to the SDN switch becomes slow, and the terminal may retransmit the connection request before the flow setting. In that case, the same two are registered in the previous flow entry table and one is used, but the other is deleted by timeout, or the same flow setting request is sent to the SDN switch, The flow setting request is replied to the SDN switch, so that the user can safely settle down. In any case, there is no situation where the flow is not set in the SDN switch or the resources of the flow direct connection unit 110 are used up.

Thus, the second embodiment is characterized in that the route control device 120 sets the second route without setting the first route for the SDN. With this configuration, the network can be notified in a single process, and the processing load on the SDN controller can be reduced.

Embodiment 3 FIG.
The third embodiment is a further improvement of the second embodiment, and constructs a bidirectional flow including not only the forward path but also the return path at the same time on the same path. Here, “outward” indicates a route within the SDN of a packet transmitted from the first end user to the second end user in a network having a part of the SDN, and “return” indicates from the second end user. The path | route in SDN of the packet transmitted to a 1st end user is shown.

FIG. 25 shows a functional configuration diagram of the flow direct connection unit 110, the SDN controller, and the route control device 120 including the flow direct connection unit 110 and the SDN controller according to the third embodiment. In the third embodiment, neither the “front and back” flows are constructed. In the second embodiment, the directly connected flow processed entry table 170 is added, and the directly connected flows that are in the opposite direction to each other are searched. Then, when it is found, the route search is performed using the first input portion to the SDN as both ends of the input / output of the flow, and the interval between them is set as a bidirectional flow. In general, TCP (Transmission Control 通信 Protocol) communication starts with TCP-SYN (Synchronous) and TCP-SYN-ACK (Acknowledgement) is immediately sent as a response, so bidirectional flow direct connection processing is performed in the shortest procedure. It will be. It is shown below again.

In the third embodiment, the procedure shown in the second embodiment is performed for PACKET_IN, and when the flow direct connection processing is performed, the transmission of PACKET_OUT is performed, but the route acquisition and the flow setting to the SDN switch are performed. Shall not be implemented. Instead, the flow directly connected entry table 170 held in the flow directly connected unit 110 is searched with header information in the reverse direction to the directly connected flow that is the current processing target. The reverse direction is a state in which TCP / IP or UDP / IP send / receive addresses are reversed. Therefore, the following conversion is performed for searching.
Source IP address ⇔ Destination IP address Source L4 port number 宛 先 Destination L4 port number

Of course, since the frame type and the IP protocol number are not related to the direction, conversion is not necessary. Also, since the MAC address may be different, it is not used as a search field. If there is no match in the search, the directly connected flow is registered as a new entry in the flow directly connected entry table 170, PACKET_OUT of the “after” flow is output, and the process ends. The process flow in the flow direct connection part 110 relevant to FIG. 26 is shown. In FIG. 26, processes S2501 to S2503 are newly inserted into the process flow of FIG. 24 of the second embodiment, and the route acquisition procedures S1708 and S1709 and the flow setting procedure S1710 are deleted. Specifically, when acquisition of the interface with the output destination SDN switch succeeds (S1707), the flow directly connected entry table 170 is searched with the header information in the direction opposite to the TCP / UDP / IP header of the flow (S2501), If there is no match (S2502), the [directly connected] flow is registered as a new entry in the flow directly connected entry table 170 (S2503). Here, each entry in the directly connected entry table 170 has the following field configuration.
Frame type (= 0x0800), send / receive IP address,
IP protocol (= 6: TCP or 17: UDP),
Transmission / reception L4 port number (L4: TCP or UDP), transmission / reception MAC address before rewriting,
Input SDN switch ID and interface number to SDN

The above SDN switch and interface are the SDN switch ID and interface number listed in the PACKET_IN of the “previous” flow, and the output destination and route are not required. The transmission / reception MAC address before rewriting is necessary as flow setting information, but is not used in the search.

If there is a match as a result of the search, the entry is extracted from the table and deleted from the table. Then, an inquiry is made to the SDN controller using the input SDN switch ID and interface of the directly connected flow that is the current processing target as the output location, and the input SDN switch and interface of the matched entry as the input location, and the route calculation result is acquired. The relationship of the processing flow on the physical configuration is shown in FIGS. FIG. 27 shows a state of establishing a direct connection flow for each of the outward path and the inbound path as seen from the terminal. Although the SDN switch and the dedicated router are written as different in the forward and return paths, each SDN switch and the dedicated router in the same row may be the same. The interface may also be the same. It is rare that a plurality of interfaces are connected from a terminal, but this is because there is an existing IP network between the SDN switch and the terminal, and the SDN and the existing IP network are connected by a plurality of interfaces. Is based on inclusion. It is as the configuration diagram (FIG. 7 etc.) shown so far. In any case, since the route calculation is performed separately for each of the outbound route and the inbound route, and the flow setting is performed, all devices on the route may be different from each other. Here, the input location of each flow indicated by an asterisk is extracted, and the route between them is inquired to the SDN controller using the input / output SDN switch and the interface. Then, the flow is set according to the obtained route, a bidirectional flow is constructed, and finally, the generation and output of PACKET_OUT of the “after” flow is performed, and the processing is terminated.

FIG. 29 shows a processing flow in the bidirectional direct connection processing unit 171 of the flow direct connection unit 110 related to FIG. First, the flow direct connection unit 110 extracts matched entry information, deletes the entry from the table (S2801), and extracts an input SDN switch ID and interface number from the matched entry information (S2802). Next, the SDN controller is queried with the input SDN switch ID and IF number extracted from the matched entry as the input location and the input SDN switch ID and IF number of the directly connected flow that is the current processing target as the output location (S2803). When the acquisition is successful (S2804), a bidirectional flow setting is performed for each SDN switch on the route based on the acquired route and flow information (S2805). PACKET_OUT of the “after” flow of a directly connected flow is generated and transmitted to the output destination SDN switch (S2806). At this time, it should be noted that the MAC address (L2 header) needs to be rewritten on both the forward and backward paths. The procedure for constructing a new flow using the input location of each forward / return flow as the end point of the new flow used here is aggregated into the same bi-directional flow when the forward route and the return route pass through different routes. It is effective as a procedure.

Subsequently, a flow setting procedure will be described. As shown in the basic embodiment shown first, as a result of the route calculation, the following list is obtained with the subscript n as an integer from 1 to N.
SDN switch IDn, input IF number n, output IF number n
Here, the MAC address of the outbound packet before being relayed by the dedicated router is the source outbound MAC address, the destination outbound MAC address,
On the other hand, the MAC address of the return packet before being relayed by the dedicated router is set as the source return MAC address and the destination return MAC address, and the forward TCP / IP header information is set to the frame type (= 0x0800),
Source IP address: Terminal IP address, Destination IP address: Server IP address IP protocol (= 6: TCP),
Assuming that the transmission source L4 port number is the terminal side L4 port number and the destination L4 port number is the server side L4 port number, the forward and backward flow setting information is as shown in FIGS. 30 and 31, respectively.

First, the MAC address of the rewrite destination of the forward path is the reverse of the MAC address of the return path. On the return path, the matching and action interfaces must be swapped because the directions are reversed. The header information of matching communication packets must also be reversed at the same time. Since the SDN switch N is the first and the last is the first in the packet flow, the rewriting is performed last, and the MAC address of the rewriting destination is the same as the outgoing route, but the sending and receiving of the outgoing MAC address are switched. ing.

By this application, the route calculation is performed in each round trip in the second embodiment, and the number that is twice is reduced to one. The number of times of flow setting itself does not change because it is set back and forth. In any case, since the route calculation amount is halved and the forward route and the return route are the same route, there are administrative advantages such as fault isolation.

In addition, as shown in FIG. 32, the flow direct connection unit 110 can be mounted on a computer physically different from the SDN controller, and may have this configuration. Furthermore, in each embodiment, the message protocol between the SDN controller and the SDN switch is shown as OpenFlow (especially after OpenFlow 1.1 or later). However, it is considered that the architecture does not change significantly except for OpenFlow. The invention is not limited to OpenFlow.

In the implementation, two tables, the previous flow entry table and the flow table that has been directly connected to the flow, are defined, and the entry is registered in each. Here, since the process is such that the search is performed later and the entry is taken out (deleted from the table) when it hits, there is a possibility that it will remain indefinitely without being hit. For this, it is effective to record the time when the entry is registered as one of the entry information and add a process of deleting it after a few tens of seconds. Since this process does not require much precision, it is only necessary to check the timeout once every few seconds and delete entries exceeding the specified number of seconds. Checking the timeout is very simple. The time is acquired when the process is executed, and the entry time is subtracted and compared with the specified number of seconds for the timeout. The entry is deleted when the following conditions are met.
Processing execution (start) time-entry registration time> timeout specified seconds The value of the time is the time acquisition function provided by a normal OS, such as Epoch seconds (seconds elapsed since January 1, 1970). The returned value can be used as it is. Also, in the flow setting, when TCP communication is assumed, it may be more effective to set the round trip at the same time. TCP communication definitely requires a return flow, and the processing load of the SDN controller will be reduced by almost half if the route is the same on the way back and forth. Even in such a configuration, as in the second and third embodiments, setting the flow for the first time at the last stage saves the computing resources of the SDN controller and suppresses the temporary increase in consumption of the flow. It is effective for.

Finally, I will touch on multicast communication. Rather than dynamically constructing a flow as in normal communication, multicast is a method of reconfiguring routes and output destination interface groups each time IGMP is registered as a multicast destination. Is the most appropriate. At this time, a part of the interface goes through a dedicated router, so one or more of the registered interfaces in the output destination interface group is an interface to which the SDN switch connects the dedicated router. One way of thinking is to apply a means that directly connects this to the flow forwarded by the dedicated router. However, if it corresponds to a multicast protocol such as IGMP or MLD, the tenant needs to be held as a logical configuration, but it is easiest to connect them all directly in the SDN regardless of the VLAN configuration. Therefore, it is considered unsuitable for dealing with the flow direct connection unit 110.

As described above, in the third embodiment, the flow direct coupling unit 110 transmits a packet transmitted from the first end user to the second end user and the second end user transmitted to the first end user. The same route is used for transmitting packets within the SDN. With this configuration, the route calculation of the SDN controller can be further reduced as compared with the second embodiment.

Embodiment 4 FIG.
In the fourth embodiment, an example of a system for receiving a trigger for performing direct connection by another means will be described. As a trigger, it is possible to use a log describing information indicating connection (TCP / UDP / IP header information, etc.) output from the network appliance and processing contents for the information. Here, most of the first embodiment is applied as it is, but the procedure for performing the last flow setting in the “after” flow processing is changed.

The difference from Embodiment 1 is shown in Embodiment 4 below. 33 and 34 show a processing flow in the flow direct connection unit 110 related to the fourth embodiment. FIG. 35 shows a functional configuration diagram of the flow direct coupling unit 110, the SDN controller, and the path control device 120 including the flow direct coupling unit 110 and the SDN controller according to the fourth embodiment. In the fourth embodiment, the flow setting is not performed, and all the information for the flow setting (FIG. 18) is registered in the directly connected flow setting entry table (S3001), and the process ends. On the other hand, when the log monitoring process is activated and a log indicating that the filter processing is completed is received, whether there is a corresponding directly connected flow in the directly connected flow setting entry table is searched (S3101) and hit. If there is something (3102), it reads out the hit entry from the table while deleting it from the table (S3103). Then, the flow is set according to the contents of the entry. Thereby, a direct connection flow is constructed. When the log is received, the direct connection flow corresponding to the log is prepared for both the forward path and the return path, so the search is performed in both directions, and the flow setting corresponding to each direction is performed (S3104, S3105, S3106, S3107). The log reception process is a part of the flow direct connection unit 110, and only one process to be started is added. However, when the log is received by the network appliance, the network appliance is generally a device different from the SDN controller. Therefore, the log is received via the communication interface as shown in FIG. In this case as well, the processing performance of the network appliance 202 can be suppressed to a very low level, and as a result, functions can be provided at low cost.

As described above, in the fourth embodiment, the flow direct connection unit 110 sets the second route for the SDN using a specific signal such as log information as a trigger after the preparation for the second route construction is completed. It is characterized by that. With this configuration, the second route can be set at an appropriate timing based on log information and the like.

11, 12, 100: router, 101, 102: high-speed router, 103, 104: connection path, 110: flow direct connection unit, 111, 112: router, 120: route control device, 150: PACKET_IN reception unit, 151: flow direct connection Function setting processing unit, 152: setting information, 153: “before” flow processing unit, 154: previous flow entry table, 155: “after” flow processing unit, 156: output destination inquiry processing unit, 157: route inquiry processing unit, 158: Flow setting transmission unit, 160: PACKET_IN reception / return unit, 161: PACKET_OUT transmission unit, 170: Flow direct connection entry table, 171: Bidirectional direct connection processing unit, 190: CPU, 191: RAM, 200: Communication interface, 201: SDN controller, 202: network Appliance, 211, 221, 222, 231: SDN switch, 311, 312, 331, 332: VLAN

Claims (12)

1. A network control unit having a connection relationship with other networks and setting a packet path in an SDN (Software Defined Network);
   There is a first path that is input to the SDN from another network and that once passes through the network appliance outside the SDN from the input location that is input to the SDN to the output location that is output from the SDN. A flow direct connection unit that constructs the second path so that a packet calculated in its own device is transmitted through the second path from the input location to the output location without going through the network appliance;
   A path control device comprising:
2. The route control apparatus according to claim 1, wherein the SDN does not have a virtual router function.
3. The network control unit calculates the first route and sets the first route for the SDN.
   The path control device according to claim 1, wherein the flow direct connection unit constructs the second path instead of the first path with respect to the SDN.
4. The path control device according to claim 1 or 2, wherein the second path is set without setting the first path for the SDN.
5. The path control device according to any one of claims 1 to 4, wherein the network appliance includes an L3 switch, a router, or an FW (FireWall).
6. The flow direct connection unit is configured to identify whether or not an input packet input to the SDN is a target packet for constructing the second route based on header information of the input packet. Item 6. The route control device according to any one of Items 1 to 5.
7. The route control device according to claim 6, wherein the header information is a MAC (Media Access Control) address.
8. In the flow direct connection unit, a transmission / reception IP (Internet Protocol) address of the input packet does not match an IP address of a device included in the network appliance, and a destination MAC (Media Access Control) address of the input packet is Of a device that matches a MAC address of a router included in the network appliance and that has a source MAC address included in the network appliance when the input packet is input again to the SDN via the network appliance The path control device according to claim 6 or 7, wherein when the MAC address matches, the input packet is determined to be a target packet for constructing the second path.
9. The flow direct connection unit has header information that the target packet for constructing the second route has before it reaches the network appliance, and the target packet for constructing the second route is output from the output location. The route control device according to claim 1, wherein rewriting is performed using header information included in the route control device.
10. The flow direct connection unit is a path through which a packet transmitted from the first end user to the second end user and a packet transmitted from the second end user to the first end user are transmitted in the SDN. The path control device according to claim 1, wherein the path control devices are the same.
11. 11. The flow direct connection unit sets the second route for the SDN using a specific signal as a trigger after preparation for the construction of the second route is completed. The path control device according to Item.
12. A network to which the route control device according to any one of claims 1 to 11 is applied.

Images