KR101931543B1 - Method and computer program for handling trouble using flow-mod message in software defined networking environment - Google Patents

Abstract

The present invention relates to a method for handling a network fault that may occur upon network interface bonding using a flow-mode message generated by a controller in a software-defined networking environment and a computer program thereof. According to the present invention, a fault handling method of a controller that manages a host to which a network interface is bonded in a software-defined networking environment includes: a step of generating a message including an action of changing a first ARP request packet including a predetermined first logical address to one of an ARP response packet, a GARP packet or a second ARP request packet and an action of outputting the changed packet to an input port; and a step of transmitting the flow-mode message to a network equipment connected to the host at a predetermined cycle, wherein the flow-mode message is set to disappear from a flow table of the network equipment after a predetermined time has elapsed. According to the present invention, when a network interface of a terminal is bonded in a software-defined networking environment, faults occurring between the network equipment and the controller can be easily detected.

Description

[0001] METHOD AND COMPUTER PROGRAM FOR HANDLING [0002] METHOD AND PROGRAM FOR DEFINED NETWORKING ENVIRONMENT [

The present invention relates to a method for handling faults in a software defined networking environment, and more particularly to a method for handling network faults that may occur upon network interface bonding using flow-mode messages generated by a controller in a software defined networking environment, Program.

Software Defined Networking (SDN) is a technology that manages all the network devices in the network by an intelligent central management system. In the SDN technology, a controller provided in a form of software can perform processing instead of a control operation related to the packet processing performed by itself in a conventional hardware type network device, so that various functions can be developed and given over the existing network structure. The SDN system generally comprises a controller server for controlling the entire network, a plurality of open flow switches controlled by the controller server for processing packets, and a host corresponding to a lower layer of the open flow switch. Here, the open flow switch is only responsible for transmitting and receiving packets, and routing, management, and control of the packets are all performed in the controller server. In other words, separating the data planes and control planes that form the network equipment is the basic structure of the SDN system.

Network bonding is a technique for preparing a network interface failure or link disconnection by grouping a plurality of network interfaces into a fault tolerant system or a load balance implementation in a legacy network .

When bonding is performed to one or more network interfaces configured in an arbitrary terminal, the computer periodically transmits an ARP request to a predetermined arbitrary IP (hereinafter, referred to as a target IP) through an activated network interface And if the ARP packet related to the target IP is not received within a predetermined time, the unused interface is set to the bonding interface to overcome the failure situation. (See Fig. 1)

However, in a software defined networking environment (hereinafter referred to as SDN environment), there is a limitation in detecting a failure by a conventional method. In SDN environments, not only failures of links or switches, but also the management network disturbances between the controller and network equipment must be detected. When the link between the switch and the controller connected to the active bonding interface of the server is broken as shown in FIG. 2, according to the conventional method, such a link disconnection is not detected and a problem may arise. Therefore, when bonding the network interface of the terminal in the SDN environment, a method of detecting a failure occurring in the network is required.

It is an object of the present invention to provide a method for easily detecting a failure occurring between a network device and a controller when a network interface of a terminal is bonded in a software defined networking environment .

Another object of the present invention is to allow a terminal to bond a network interface in a software defined networking environment, thereby enabling more stable network management.

It is another object of the present invention to provide a fault handling method and a computer program capable of minimizing the load imposed on the network and minimizing the processing time of the network equipment for fault handling, thereby enabling fast fault handling.

According to an aspect of the present invention, there is provided a fault handling method for a controller that manages a host to which a network interface is bonded in a software defined networking environment, the method comprising: receiving a first ARP request packet including a first logical address, Generating a flow-mode message including an action of changing a response packet, a response packet, a GARP packet, or a second ARP request packet, and an action of outputting the changed packet to an input port, Wherein the flow mode message is set to disappear from the flow table of the network device after a predetermined time has elapsed.

According to the present invention, when a network interface of a terminal is bonded in a software defined networking environment, faults occurring between the network equipment and the controller can be easily detected.

In addition, according to the present invention, a terminal can bond a network interface even in a software-defined networking environment, thereby enabling more stable network management.

In addition, according to the present invention, it is possible to minimize the load on the network in the bonding failure processing in the software defined networking environment and to improve the processing speed of the network equipment for the failure processing.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram for explaining a failure handling method in a network interface bonding in a legacy network,
2 is a diagram illustrating the limitations of prior art applications in a software defined networking environment;
3 is a diagram for explaining another embodiment of a fault handling method that occurs when a network interface of a terminal is bonded in a software defined networking environment of the present invention;
4 is a diagram for explaining a fault handling method using a flow-mode message according to an embodiment of the present invention.

The above and other objects, features, and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings, which are not intended to limit the scope of the present invention. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the drawings, the same reference numerals are used to designate the same or similar components, and all combinations described in the specification and claims can be combined in any manner. It is to be understood that, unless the context requires otherwise, references to singular forms may include more than one, and references to singular forms may also include plural forms.

2 is a diagram for explaining a failure occurrence situation in a software defined networking environment. Referring to FIG. 2, a software defined networking environment may include a controller 100, network equipment 200, and a host 300. The network device 200 and the host 300 may be referred to as a node, and a link may denote a connection between two nodes.

The controller 100 manages the network equipment 200 and centrally manages and controls the plurality of network equipment 200. Specifically, the controller 100 is an application (software) that performs functions such as topology management, path management related to packet processing, link discovery, packet flow in flow management, Can be implemented. Unless otherwise specified herein, each step of the fault handling that controller 100 executes may be understood to be performed by an application.

The network equipment 200 functions to process packets under the control of the controller 100. The switch 200 shown in the figure can be exchanged with a network device such as a mobile communication base station, a base station controller, a gateway device, a router, etc. for packet processing. For convenience of explanation, a network device is a switch 200, and a switch 200 according to an embodiment of the present invention will be described with reference to an open flow switch 200.

In the software defined networking environment, the controller 100 and the open flow switch 200 must exchange information with each other. An open flow protocol is widely used as a protocol for this. That is, the open flow protocol is a standard that allows the controller 100 and the open flow switch 200 to communicate with each other.

More specifically, the open flow switch 200 is largely divided into a software layer and a hardware layer. The software layer exchanges information with the controller 100 through a secure channel. The secure channel is a communication channel between the open flow switch 200 and the remote controller 100. Information exchanged between the controller 100 and the open flow switch 200 is encrypted.

The hardware layer has a flow table that defines and processes packets and includes statistical information related to the packets. The flow table includes a flow rule that defines packet processing. The flow rule is generated by a flow mode message (Flow-Mode Message) generated by the controller 100 and transmitted to the open flow switch 200 Added, modified or deleted. The open flow switch 200 processes the packet with reference to the flow table. Each row constituting the flow table is referred to as a flow entry. The flow entry can largely include three pieces of information: packet header information (Rule) defining a flow, operation information (Action) defining processing of a packet, and stat information (Stats) per flow.

The host 300 means a terminal or the like corresponding to a lower layer of the open flow switch 200, and can be used to mean a client and a server. The host 300 may generate a packet to be sent to another host in a software defined networking environment and transmit the packet to the open flow switch 200 through a port of the network interface. In this specification, a failure handling method when the network interface of the host 300 is bonded is disclosed. Thus, in each of the embodiments described herein, the host 300 may have one or more network cards, and one or more network cards may be understood to be bonded.

2, in a software defined networking environment according to an exemplary embodiment of the present invention, a host 300 to which a network interface is connected periodically transmits an ARP request packet having a predetermined logical address as a target address to an open flow switch 200). This is for determining whether to maintain the bonding interface. If the host 300 does not receive the packet corresponding to the ARP request packet, the host 300 switches the active interface.

For example, the host 300 may periodically transmit an ARP request packet to the target IP (10.0.0.1) using a configuration such as " bond-arp-ip-target 10.0.0.1 ". Assume that NIC 1 and NIC 2 in FIG. 2 are bonded and the current packet is being transmitted and received through NIC 1. In this case, the host 300 may change the bonding interface from NIC 1 to NIC 2 if a response corresponding to the ARP request packet continuously transmitted via NIC 1 is not received. Therefore, the data transmitted from the host 300 or input to the host 300 thereafter is transmitted and received via the NIC 2.

The ARP request packet is transmitted by targeting the IP address of the corresponding node (target address in the Target IP address field) in order to know the MAC address of the counterpart host or router. In general, the ARP packet includes an Ethernet header field ARP request or response payload, a padding field, and a CRC field. The ARP request or response payload may include a hardware type, a protocol type, A hardware address length, a protocol address length, an operation code, a source hardware address, a source protocol address, a target (destination) physical address (Targer hardware address), and a target (destination) logical address.

On the other hand, when the open flow switch 200 receives an arbitrary packet and the flow table defining the processing of the packet exists, the open flow switch 200 processes the packet according to the regulation. However, when there is no flow table related to the packet in the open flow switch 200, the open flow switch 200 transmits a packet-in message informing the controller 100 of the packet flow. The controller 100 generates a flow table for specifying the processing of the packet according to an operator's policy or a preset algorithm and transmits the flow table to the open flow switch 200. The open flow switch 200 receives the flow table To process the packet.

3 to 4, when a network interface of an arbitrary host 300 is bonded in a software defined network environment according to an embodiment of the present invention, the controller 100 transmits a flow- Will be described.

The controller 100 includes an action of changing a first ARP request packet including a predetermined first logical address to one of an ARP response packet, a GARP packet, or a second ARP request packet, and an action of outputting a changed packet to an input port A flow-mode message (Flow-Mode Message) may be generated (S500). Here, the predetermined first logical address may be preset or promised as a logical address for verifying the validity of the bonding network interface in the present networking environment.

The flow-mode message is a message for changing the flow table stored in the open flow switch 200 or adding a flow rule, as described above.

Next, the controller 100 may transmit the generated flow-mode message to one or more network devices connected to the host at a predetermined cycle (S600). A flow-mode message may be sent to all of the network equipment (200A, 200B) connected to each of the bonded network interfaces.

On the other hand, the flow-mode message may be set to disappear from the flow table of the network equipment after a predetermined time. For example, a hard-timeout may be set in a flow-mode message. If a non-zero value is inserted in the hard-timeout field, the flow rule will take a specified time, regardless of the number of matching packets Remove flow entries after flow.

Therefore, when a fault occurs between the controller 100 and the open flow switch 200A, the flow-mode message for adding a new flow rule is not received after the flow rule disappears. Therefore, the open flow switch 200A sends an ARP request packet Even if it is received, it can not take an action corresponding thereto. As a result, the host 300 can not receive the ARP packet associated with the promised target IP (10.0.0.1) within a predetermined time, and the activated bonding interface (NIC 1) (NIC 2). Since the flow-mode message is also periodically transmitted to the open-flow switch 200B after the switching of the bonding interface, the host 300 transmits and receives the packet using the link connecting the open-flow switch 200B and the NIC 2 And the transmission of the ARP request packet and the reception of the corresponding ARP packet can also be maintained between the bonding network interface (NIC) of the host 300 and the open flow switch 200B.

According to this embodiment using the flow-mode message, it is not necessary to send the packet-in message continuously to the controller 100 at intervals of several seconds, so that the load on the controller 100 can be reduced. In addition, using the flow-mode message, the open flow switch 200 only has to modify the header field value of the ARP request packet according to the set-field action of the message. Therefore, the open flow switch 200 uses the CPU of the open flow switch 200 The reaction speed is very fast because there is no need.

The detailed embodiment will be described with reference to FIG.

(1) a flow-mode message transmission that changes an ARP request packet to an ARP response packet (D)

For example, assume that the host 300 periodically transmits an ARP request packet, such as Table 1, to the open flow switch 200. In each field, ETH_SRC is a source physical address included in an Ethernet header field, ETH_DST is a destination physical address included in an Ethernet header field, ARP_OP is an operation code, ARP_SHA is a source physical address, ARP_SPA is a source logical address, ARP_THA is a destination physical address, ARP_TPA means the destination logical address.

The ARP request packet of Table 1 is transmitted from the host 300 having the logical address of 10.0.0.5 and the physical address of 11: 22: 33: 44: 55: 66, and the destination logical address is 10.0.0.1. Here, the destination logical address 10.0.0.1 may be an actual host, but it may be any logical address previously promised for handling the bonding failure in the software defined network environment according to the present invention. Since the ARP request packet is a packet for knowing the physical address of an arbitrary host, the destination physical address is set to a broadcast address such as FF: FF: FF: FF.

When the ARP request packet is received by the open flow switch 200A, the controller 100 can periodically and continuously transmit the flow rule for changing the packet to the ARP response packet D to the open flow switch 200A. Table 1 is a flow-mode message transmitted to the open-flow switch 200A. It is temporarily stored in the flow table of the open-flow switch 200A for 2 seconds, and the packet received by the open- .

The flow rule of Table 1 allows the open flow switch 200A to perform the action inserted in the action field for the packet when the packet received is the ARP request packet.

The action to change an ARP request packet to an ARP reply packet is as follows. First, the operation field ARP_OP of the ARP request packet is modified to '2' corresponding to the ARP response packet (action 1), and the source physical address (eth_src) of the Ethernet header field is set to a predetermined first logical address 10.0.0.1 (6c: 3b: e5: 5a: 6c: 1c) corresponding to the first physical address (Action 2). Next, the destination physical address (eth_dst) included in the Ethernet header field of the ARP request packet can be set to the physical address (11:22:33:44:55:66) of the host 300 (action 3). Then, the source physical address (arp_sha) of the ARP request packet is set to the first physical address 6c (3b: e5: 5a: 6c: 1c) (action 4) It can be set to a logical address (10.0.0.1) (action 5).

(Action 6), and changes the destination logical address (arp_tpa) of the ARP request packet to the host logical address (arp_tpa) of the ARP request packet by changing the destination physical address (arp_tha) of the ARP request packet to the physical address (11:22:33:44:55:66) (Action 7), the ARP request packet is changed to the ARP response packet. The open flow switch 200A changes the ARP response packet according to the last action (action 8) in [Table 2] Can be output to the input port.

(2) a flow-mode message transmission that changes an ARP request packet to a GARP packet (E)

When the ARP request packet is received by the open flow switch 200A, the controller 100 can periodically and continuously transmit the flow rule for changing the packet to the GARP packet (E) to the open flow switch 200A. Table 3 is a flow-mode message transmitted to the open flow switch 200A. It is stored temporarily (2 seconds) in the flow table of the open flow switch 200A to process the packet received by the open flow switch 200A do.

The action to change an ARP request packet to a GARP packet is as follows. The source physical address (eth_src) included in the Ethernet header field of the first ARP request packet can be set to the first physical address 6c: 3b: e5: 5a: 6c: 1c corresponding to the first logical address ). The operation code (arp_op) can be changed to 2 corresponding to the ARP response packet before the first action. However, since the GARP packet is not defined by the operation code value, modification of the operation code is not essential.

Next, the destination physical address (eth_dst) included in the Ethernet header field of the ARP request packet can be set as a broadcast address (FF: FF: FF: FF: FF: FF) (action 2). (Action 3) and sets the source physical address (arp_sha) of the ARP request packet to the physical address (6c: 3b: e5: 5a: 6c: 1c) 0.1) (action 4), the change to the GARP packet of the ARP request packet is completed. The open flow switch 200A can transmit the GARP packet to the host 300 by outputting the changed GARP packet to the input port (action 5) according to the last action of [Table 3].

GARP is a packet whose destination is its IP address, and the destination logical address (ARP_TPA) of the ARP request packet is already set to 10.0.0.1, so that the corresponding field is not required to be modified.

(3) a flow-mode message transmission that changes the first ARP request packet to a second ARP request packet (F)

When the ARP request packet is received by the open flow switch 200A, the controller 100 periodically and continuously transmits a flow rule for changing the packet to the second ARP request packet F to the open flow switch 200A . Table 4 is a flow-mode message transmitted to the open-flow switch 200A. It is stored temporarily (2 seconds) in the flow table of the open-flow switch 200A to process the packet received by the open-flow switch 200A do.

The action of changing the ARP request packet to the second ARP request packet F is to change the source physical address (eth_src) included in the Ethernet header field of the first ARP request packet to the physical address of the host (11:22:33:44:55 : 66), and outputs the changed second ARP request packet to the input port so that the host 300 receives the second ARP request packet.

In other words, when the controller 100 transmits a flow-mode message such as the embodiment of (1) to (3) to the open flow switch 200A, the open flow switch 200A transmits the flow And processes the received first ARP request packet according to the rule. According to the flow rule, the first ARP request packet is modified into an ARP response packet, a GARP packet, and a second ARP request packet, and output to the input port.

As a result, the ARP response packet, the GARP packet, and the second ARP request packet are transmitted to the host 300, and if any one of the ARP response packet, the GARP packet, or the second ARP request packet is not received within a predetermined time, The host 300 configured to switch the connected bonding interface can determine whether or not the packet is received according to whether or not the packets are received.

Meanwhile, the above-described failure handling method can be implemented in the controller 100 through the failure handling application program stored in the computer-readable medium for executing any one of the embodiments.

Some embodiments omitted in this specification are equally applicable if their implementation subject is the same. It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory and are intended to be exemplary and explanatory only and are not restrictive of the invention, The present invention is not limited to the drawings.

100: controller
200: Switch
300: Host (terminal)

Claims (6)

A fault handling method of a controller for managing a host in which a network interface is bonded in a software defined networking environment,
A flow-mode message including an action of changing a first ARP request packet including a predetermined first logical address to one of an ARP response packet, a GARP packet, or a second ARP request packet, and an action of outputting the changed packet to an input port ≪ / RTI > And
And sending the flow-mode message to one or more network devices connected to the host at a predetermined period,
Wherein the flow mode message is set to expire in a flow table of the network device after a predetermined time,
Wherein the action of changing the first ARP request packet to the GARP packet comprises:
A first action to set a source physical address included in an Ethernet header field of the first ARP request packet to a first physical address corresponding to the first logical address;
A second action for setting a destination physical address included in an Ethernet header field of the first ARP request packet as a broadcast address;
A third action to set a source physical address of the first ARP request packet to the first physical address;
And setting a source logical address of the first ARP request packet to the first logical address.
The method according to claim 1,
The action of changing the first ARP request packet to the ARP response packet
A first action to set an operation field of the first ARP request packet to a value corresponding to an ARP response packet;
A second action for setting a source physical address included in an Ethernet header field of the first ARP request packet to a first physical address corresponding to the first logical address;
A third action for setting a destination physical address included in an Ethernet header field of the first ARP request packet as a physical address of the host;
A fourth action to set a source physical address of the first ARP request packet to the first physical address;
A fifth action to set a source logical address of the first ARP request packet to the first logical address;
A sixth action for setting a destination physical address of the first ARP request packet to a physical address of the host;
A seventh action for setting a destination logical address of the first ARP request packet to a logical address of the host;
≪ / RTI >
delete The method according to claim 1,
The action of changing the first ARP request packet to the second ARP request packet
And a first action for setting a source physical address included in an Ethernet header field of the first ARP request packet different from a physical address of the host.
The method according to claim 1,
Wherein the host is configured to switch the activated bonding interface if either the ARP response packet, the GARP packet, or the second ARP request packet is not received within a predetermined time.
A controller application program stored on a computer readable medium for executing the method of any one of claims 1, 2, 4 and 5.

Images