KR20190054224A - Machine learning based network automation system architecture - Google Patents

Abstract

The present invention relates to a method for automatic management in a software defined network (SDN)-based testbed environment formed of equipment different from each other. According to the present invention, a structure for a testbed automation system realizes an L2 network among different virtual private network hosts through network virtualization and interlocking, automatically manages various topologies and tests through the automation system. Accordingly, the present invention reduces unnecessary test repetition automates the test therethrough to discover a plurality of bugs, and allows a user to repeat various concept tests. Moreover, a setting database can be independently managed for each of various equipment through plug-in structuralization, thereby providing mutual compatibility with various kinds of equipment. According to the present invention, the structure comprises a machine learning-based network automation system framework, an agent, an event branching module, an action plugin, and network equipment.

Description

{MACHINE LEARNING BASED NETWORK AUTOMATION SYSTEM ARCHITECTURE}

The present invention relates to a machine learning and SDN (Software Defined Network) based network automation system, which can learn a variety of network operations based on machine learning and enable automation based reaction to problem situations, And more particularly to a system for providing sophisticated functions.

With the explosive growth of mobile devices and server virtualization and the emergence of cloud services, network demand has increased. SDN (Software-Defined Network) is a basic network infrastructure that is appraised in an application. It is logically centralized network intelligence. It is separated from the control plane and the data plane. SDN is an approach to computer networking that enables network administrators to manage network services through an abstraction of low-level functionality. This can be accomplished by separating the system (control plane) that determines where the traffic will be sent from the underlying system (data plane) that forwards the traffic to the selected destination.

Open flows separate high-speed packet delivery and high-level routing decision functions. The packet forwarding plane is still involved in the switch stage, while the high-level routing decisions are involved in a separate controller, which communicates through the open flow protocol, but as a transition from the existing network to the SDN, There is a need for a software defined network. Such a hybrid SDN network requires less computing resources and networking resources, and requires simple structure and operation.

In the existing network test, the user made a series of manual processes such as setting up the equipment by hands, testing and analyzing the results by hand, and it was necessary to repeatedly work every time development schedule change and new function development were done.

It is an object of the present invention to provide a system structure that provides an automatic test function of an SDN-based test bed system, enables a repeated function verification, and provides a test environment requiring a new function verification or a complicated topology There is.

Another object is to provide functional verification of a system interworking with an external router system to support a legacy network in an SDN-based private network.

A method for providing a testbed automation system based on SDN (Software Defined Network) according to the present invention includes: a controller for controlling a plurality of SDN-based switches; A virtual router for treating a switch group including at least some switches among the plurality of switches as a virtual router and generating routing information for a packet to be input to one of the switches; A virtual router for receiving a virtual router creation request message and allocating computing resources to create the virtual router using virtualization technology; An integrated testing framework for configuring devices in conjunction with a virtual router, an emulator for configuring a test topology with physical devices assigned to jobs from the framework; And a plug-in for setting the setting according to the setting method of each of the following devices.

According to the present invention, a user can dynamically provide a desired virtualized topology. The user can define a desired test case and periodically execute the test case. The user can be ported to actual equipment through mapping to existing physical equipment, Can be tested. In addition, the results of the test can be periodically monitored through log management of the automated integration testing framework.

1 is a structural diagram of a network automation system based on a machine learning;
FIG. 2 is a block diagram of the controller of the network system of FIG. 1;
FIG. 3 is a block diagram of a switch of the network system of FIG. 1,
4 is an operation table showing a field table of a flow entry and an operation type according to a flow entry,
5 is a block diagram of a network system including an integrated routing system according to an embodiment of the present invention;
Figure 6 is a block diagram of a legacy routing container according to an embodiment of the present invention;
7 is a block diagram of a network system including an operation virtual network support system through interworking with an external router according to an embodiment of the present invention.
FIG. 8 is a signal flow diagram according to an integrated routing method according to another embodiment of the present invention;
Figure 9 is a flow table according to an embodiment of the present invention,
10 is a structural diagram illustrating a network management system according to an embodiment of the present invention.

Hereinafter, the present invention will be described in more detail with reference to the drawings.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between. Also, the fact that the first component and the second component on the network are connected or connected means that data can be exchanged between the first component and the second component by wire or wirelessly.

In addition, suffixes " module " and " part " for the components used in the following description are given merely for convenience of description, and do not give special significance or role in themselves. Accordingly, the terms " module " and " part " may be used interchangeably.

When such components are implemented in practical applications, two or more components may be combined into one component, or one component may be divided into two or more components as necessary. The same reference numerals are given to the same or similar components throughout the drawings, and detailed descriptions of components having the same reference numerals can be omitted and replaced with descriptions of the above-described components.

SDN is a concept that separates the data plane that carries the packet and the control plane that controls the flow of the packet. When a packet occurs in the SDN, the network device asks the SDN control software (controller) where to transmit the packet, and determines the path and method for transmitting the packet based on the result. SDN is a theoretical concept, and Openflow has emerged to actually apply it. That is, Open Flow is a standard interface established to implement SDN. An open flow is composed of an open flow controller and an open flow switch, and controls the flow information to determine a delivery path and a method of a packet. Throughout this specification, open flows and SDNs may be used interchangeably or in combination.

A flow may refer to a packet flow of a particular path according to a series of packets sharing a value of at least one header field from a single switch or a combination of multiple flow entries of multiple switches. The open-flow network can perform path control, fault recovery, load balancing and optimization on a flow-by-flow basis.

In the present specification, a specific term may be defined by the following description or may have a meaning other than the original meaning. &Quot; Flow " may mean the packet itself to be processed by the switch. The " flow " may include a packet to be processed by the switch and meta data (an incoming port from which the packet is received, or an incoming port from the other switch when the packet is received from another switch). The " flow processing information " may be information for processing a packet received from the switch, information necessary for modifying the packet or the metadata of the packet, and / or a specific network interface (port) through which the packet will flow. The flow processing information may be the same as the content of the flow entry of the flow table or the content to be applied to the flow entry, and may mean the flow entry itself. The " flow processing " may mean processing the packet or flow in the switch based on the above flow processing information.

1 is a block diagram of a controller of the network system of FIG. 1, FIG. 3 is a block diagram of a switch of the network system of FIG. 1, and FIG. 4 Fig. 5 is a field table of the group and meter tables; Fig.

Referring to FIG. 1 (a), an SDN network system may include a controller 10, a plurality of switches 20, and a plurality of network devices 30.

The network device 30 may include a user terminal device for exchanging data or information, or a physical device or a virtual device for performing a specific function. From a hardware standpoint, the network device 30 may be a PC, a client terminal, a server, a workstation, a supercomputer, a mobile communication terminal, a smart phone, a smart pad, or the like. The network device 30 may also be a virtual machine (VM) created on a physical device.

The network device 30 may be referred to as a network function that performs various functions on the network. Network features include anti-DDoS, intrusion detection / blocking (IDS / IPS), integrated security services, virtual private network services, anti-virus, anti-spam, security services, access management services, firewalls, load balancing, . ≪ / RTI > These network functions can be virtualized.

A virtualized network function, published by the European Telecommunications Standards Institute (ETSI) There is a Network Function Virtualization (NFV) defined in the NFV related white paper (see Non-Patent Document 3). The network function (NF) may be used herein in combination with network function virtualization (NFV). NFV provides necessary network functions by dynamically generating necessary L4-7 service connection for each tenant, and provides firewall, IPS and DPI functions necessary for policy-based DDoS attacks quickly through a series of service chaining . NFVs can also easily turn on and off firewalls or IDS / IPS and provision them automatically. NFV can also reduce the need for overprovisioning.

A controller 10 is a kind of command computer that controls the SDN system and can perform various complex functions such as routing, policy declaration, and security check. The controller 10 can define the flow of packets occurring in the plurality of switches 20 in the lower layer. The controller 10 may calculate a path (data path) to be flowed by referring to a network topology or the like with respect to a flow allowed in the network policy, and then set an entry of the flow on a switch on the path. The controller 10 may communicate with the switch 20 using a specific protocol, e.g., an open flow protocol. The communication channel between the controller 10 and the switch 20 can be encrypted by SSL.

2, the controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190, which communicate with the switch 20.

The storage unit 190 may store a program for processing and controlling the control unit 100. [ The storage unit 190 may perform a function for temporarily storing input or output data (packet, message, etc.). The storage unit 190 may include an entry database (DB) 191 for storing flow entries.

The controller 100 may control the overall operation of the controller 10 by controlling the operations of the respective units. The control unit 100 may include a topology management module 120, a path calculation module 125, an entry management module 135, and a message management module 130. Each module may be configured in hardware in the control unit 100 and may be configured in software separate from the control unit 100. [

The topology management module 120 can construct and manage network topology information based on the connection relationship of the switches 20 collected through the switch communication unit 110. [ The network topology information may include a topology between switches and a topology of network devices connected to each switch. The topology information may be stored in the storage unit 190.

The path calculation module 125 can obtain the data path of the packet received through the switch communication unit 110 and the action column to be executed in the switch on the data path based on the network topology information established in the topology management module 120.

The entry management module 135 registers the entry in the entry DB 191 as an entry such as a flow table, a group table, and a meter table based on the result calculated by the route calculation module 125, a policy such as QoS, . The entry management module 135 may proactively register an entry in each table in the switch 20 and react to an addition or update request of an entry from the switch 20. [ The entry management module 135 may change or delete entries in the entry DB 191 as needed or in accordance with an entry disappearance message of the switch 10. [

The message management module 130 may interpret a message received through the switch communication unit 110 or may generate a controller-switch message to be transmitted to the switch through the switch communication unit 110, which will be described later. The status change message, which is one of the controller-switch messages, may be generated based on the entry generated by the entry management module 135 or the entry stored in the entry DB 191. [

The switch 20 may be a physical switch or a virtual switch supporting an open flow protocol. The switch 20 can process the received packet and relay the flow between the network devices 30. [ To this end, the switch 20 may comprise a single flow table or a multiple flow table for pipeline processing as described in non-patent document 1. [

The flow table may include a flow entry defining rules for how to handle the flow of network device 30. [

The switch 20 can be divided into a core switch between an ingress and egress edge switch and an edge switch between a flow according to the combination of multiple switches.

3, the switch 20 includes a port portion 205 for communicating with other switches and / or network devices, a controller communication portion 210 for communicating with the controller 10, a switch control portion 200, and a storage portion 290).

The port unit 205 may include a plurality of pairs of ports connected to a switch or a network device. A pair of ports can be implemented as one port.

The storage unit 290 may store a program for processing and controlling the switch control unit 200. [ The storage unit 290 may perform a function for temporarily storing input or output data (packets, messages, etc.). The storage unit 290 may include a table 291 such as a flow table, a group table, and a meter table. An entry in the table 230 or table may be added, modified or deleted based on the message of the controller 10. [ The table entry may be discarded by the switch 20 itself.

The flow table can be composed of multiple flow tables to handle the pipeline of open flows. 4, a flow entry of a flow table includes match fields describing conditions (matching rules) to match a packet, a priority, counters to be updated when there are packets to be matched, An instruction that is a set of various actions that occurs when there is a packet matched to a flow entry, timeouts that describe the time to be discarded in the switch, and an opaque type that is selected by the controller. Can be used to filter flow statistics, flow changes, and flow deletions, and can include tuples such as cookies that are not used in packet processing.

An instruction may change pipeline processing such as forwarding a packet to another flow table. The instructions may also include a collection of actions to add an action to an action set, or a list of actions to apply directly to a packet. An action can be an action that modifies a packet, such as sending a packet to a specific port, or decreasing the TTL field. The action may be part of an instruction set associated with the flow entry or belonging to an action bucket associated with the group entry. An action set is an aggregated set of actions indicated in each table. An action set can be performed when no table is matched. 5 illustrates various packet processing by a flow entry.

A pipeline is a sequence of packets between a packet and a flow table. When a packet is input to the switch 20, the switch 20 searches for a flow entry matching the packet in the order of higher priority of the first flow table. When the matching is performed, the instruction of the entry is executed. An instruction may be an apply-action that is immediately matched, a command to clear or add / modify an action set, a write-action, a write-metadata command, And a goto-table that moves packets along with metadata to a table. If there is no flow entry matched with the packet, the packet may be dropped according to the table setting, or the packet may be sent to the controller 10 in a packet-in message.

The group table may include group entries. The group table may be indicated by a flow entry to suggest additional forwarding methods. Referring to FIG. 5A, the group entry of the group table may include the following fields. A group identifier for identifying a group entry, a group type for specifying a rule for performing a select or all action buckets defined in the group entry, a counter for a flow entry , And action buckets, which are a set of actions associated with the parameters defined for the group.

A meter table is composed of meter entries and defines per-flow meters. The flow meter-party can allow open flows to be applied to various QoS operations. A meter is a kind of switch element that can measure and control the rate of packets. Referring to FIG. 5 (b), a meter table includes a meter identifier for identifying a meter, a rate specified in a band and meter bands indicating a method of packet operation, And counters fields that are updated when operated on the meter. Meter bands include a band type indicating how the packet is to be processed, a rate used to select the meter band by the meter, counters that are updated when the packets are processed by the meter band, ), And a type specific argument, which is a bad type with optional arguments.

The switch control unit 200 can control the overall operation of the switch 20 by controlling the operations of the respective units. The switch control unit 200 may include a table management module 240 that manages the table 291, a flow search module 220, a flow processing module 230, and a packet processing module 235. Each module may be configured in hardware in the control unit 200 and may be configured in software separate from the control unit 200. [

The table management module 240 may add the entry received from the controller 10 to the appropriate table through the controller communication unit 210 or periodically remove the time-out entry.

The flow search module 220 may extract flow information from the received packet as user traffic. The flow information includes identification information of an ingress port as a packet inflow port of the edge switch, identification information of an incoming port of the switch of the switch, packet header information (IP address of the source and destination, MAC address, port, And VLAN information, etc.), metadata, and the like. The metadata may be optionally added in the previous table or may be data added in another switch. The flow search module 220 can search the table 291 for a flow entry for a received packet by referring to the extracted flow information. The flow search module 220 may request the flow processing module 260 to process the received packet according to the retrieved flow entry, if a flow entry is found. If the flow entry search fails, the flow search module 220 may transmit the minimum data of the received packet or the received packet to the controller 10 via the controller communication unit 210.

The flow processing module 230 may process an action, such as outputting a packet to a specific port or multiple ports, dropping it, or modifying a specific header field, in accordance with the procedure described in the entry retrieved from the flow search module 220 have.

The flow processing module 230 may execute an action set to execute a pipeline process of a flow entry, execute an instruction to change an action, or execute a set of actions when it is no longer possible to go to the next table in a multi-flow table.

The packet processing module 235 may actually output the packet processed by the flow processing module 230 to one or more ports of the port unit 205 designated by the flow processing module 230. [

Referring to FIG. 1 (b), the SDN network system may further include an orchestrator 1. The orchestrator 1 can create, change and delete virtual network devices, virtual switches, and the like. When the virtual network device is created in the orchestrator 1, the orchestrator 1 identifies the switch to be connected to the virtual network, the port identification information connected to the switch, the MAC address, the IP address, the tenant identification Information of the network device such as information and network identification information to the controller 10. [

The controller 10 and the switch 20 communicate with each other through an interface different from the orchestrator 1 or through the controller communication unit 210 of the switch communication unit 110 and the switch 20 of the controller 10, ). ≪ / RTI > The switch 20 can send and receive messages to the orchestrator 1 via the controller 10.

The controller 10 and the switch 20 exchange various information, which is called an open flow protocol message. Such an open flow message may be of a type such as a controller-to-switch message, an asynchronous message, and a symmetric message. Each message may have a transaction identifier (transaction id; xid) in the header that identifies the entry.

The controller-switch message is a message generated by the controller 10 and transmitted to the switch 20, which is mainly used for managing or checking the state of the switch 20. [ The controller-switch message may be generated by the controller 100 of the controller 10, and in particular by the message management module 130.

The controller-switch message includes features inquiring about the capabilities of the switch, configuration for inquiring and setting the settings of the configuration parameters of the switch 20, flow / group / meter of the open flow table, A modify state message for adding / deleting / modifying entries, a packet-out message for transmitting a packet received from the switch through a packet-in message to a specific port on the switch, and the like . The state change message includes a modify flow table message, a modify flow entry message, a modify group entry message, a prot modification message, and a meter entry change message. Message (meter modification message).

The asynchronous message is a message generated by the switch 20, and is used to update the state of the switch, the network event, and the like in the controller 10. The asynchronous message may be generated by the control unit 200 of the switch 20, in particular by the flow search module 220.

Asynchronous messages include packet-in messages, flow-removed messages, and error messages. The packet-in message is used by the switch 20 to send a packet to the controller 10 to receive control of the packet. The packet-in message includes all or part of the received packet, or a copy thereof, sent from the open flow switch 20 to the controller 10 to request the data path when the switch 20 receives an unknown packet Message. A packet-in message is used even when the action of the entry associated with the incoming packet is determined to be sent to the controller. The deleted flow-removed message is used to forward the flow entry information to the controller 10 to be deleted from the flow table. This message occurs when the controller 10 requests the switch 20 to delete the corresponding flow entry or in a flow expiry process by a flow timeout.

The symmetric message is generated in both the controller 10 and the switch 20, and is transmitted even when there is no request from the other party. A hello used to initiate the connection between the controller and the switch, an echo to confirm that there is no abnormality in the connection between the controller and the switch, and an error message used by the controller or switch to inform the other side of the problem an error message, and the like. The error message is mostly used in the switch to indicate a failure in response to a request initiated by the controller.

FIG. 6 is a block diagram of a network system including an integrated routing system according to an embodiment of the present invention; FIG. 7 is a block diagram of a virtualized system of the network system of FIG. 6; and FIG. FIG. 9 is a block diagram of a legacy routing agent according to an embodiment of the present invention. Referring to FIG.

The network shown in Fig. 6 includes an SDN-based network including the controller 10 for controlling the flow of the open flow switch among the switch groups constituted by the plurality of switches SW1 to SW5 and the first to third legacy routers R1- R3 are mixed with each other. In this specification, the SDN-based network means only an open-flow switch, or an independent network composed of an open-flow switch and an existing switch. When the SDN-based network is composed of an open-flow switch and an existing switch, it is preferable that the open-flow switch is arranged at an edge of a network domain of the switch group.

Referring to FIG. 6, the SDN-based integrated routing system according to the present invention may include a switch group having first through fifth switches SW1-SW5, a controller 10, and a legacy routing agent 300 have. Reference is made to Figs. 1 to 5 for a detailed description of the same or similar components.

The first and third switches SW1 and SW5, which are the edge switches connected to the external network among the first to fifth switches SW1 to SW5, are open flow switches that support the open flow protocol. The open flow switch may be physical hardware, virtualized software, or a mixture of hardware and software.

In this embodiment, the first switch SW1 is an edge switch connected to the first legacy router R1 through the eleventh port (port 11), and the third switch SW3 is an edge switch connected to the 32nd port 33 , and port 33 to the second and third legacy routers R2 and R3. The switch group may further include a plurality of network devices (not shown) connected to the first to fifth switches.

8, the controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190, which communicate with the switch 20.

The control unit 100 of the controller includes a topology management module 120, a path calculation module 125, an entry management module 135, a message management module 130, a message determination module 140, and a legacy interface module 145 can do. Each module may be configured in hardware in the control unit 100 and may be configured in software separate from the control unit 100. [ Reference is made to Fig. 2 for a description of the components of the same reference numerals.

When the switch group is composed only of an open flow switch, the functions of the topology management module 120 and the path calculation module 125 are the same as those described in Figs. When the switch group is composed of the open flow switch and the existing legacy switch, the topology management module 120 can obtain the connection information with the legacy switch through the open flow switch.

The legacy interface module 145 may communicate with the legacy routing agent 300. The legacy interface module 145 may transmit the topology information of the switch group established by the topology management module 120 to the legacy routing agent 300. [ The topology information may include connection information of the first to fifth switches SW1 to SW5 and connection or connection information of a plurality of network devices connected to the first to fifth switches SW1 to SW5.

If the message management module 130 can not generate the processing rule of the flow included in the flow inquiry message received from the open flow switch, the message management module 130 can transmit the flow to the legacy routing agent 300 through the legacy interface module 145 have. The flow may include the packet received at the open flow switch and the port information of the switch receiving the packet. A case where the processing rule of the flow can not be generated, a case where the received packet is configured as a legacy protocol and can not be interpreted, and the case where the path calculation module 125 can not calculate the path to the legacy packet, and the like.

9, the legacy routing agent 300 may include an SDN interface module 345, a virtual router creation section 320, a virtual router 340, a routing processing section 330, and a routing table 335 have.

The SDN interface module 345 may communicate with the controller 10. Each of the legacy interface module 145 and the SDN interface module 345 may serve as an interface between the controller 10 and the legacy routing agent 300. Legacy interface module 145 and SDN interface module 345 may communicate in a particular protocol or in a particular language. The legacy interface module 145 and the SDN interface module 345 can translate or interpret the messages exchanged between the controller 10 and the legacy routing agent 300.

The virtual router creation unit 320 can create and manage the virtual router 340 using the topology information of the switch group received through the SDN interface module 345. [ Via the virtual router 340, the switch group in the external legacy networks, i.e., the first to third routers R1-R3, can be treated as a legacy router.

The virtual router generating unit 320 may generate a plurality of virtual routers 340. 7A shows a case where the virtual router 340 is a virtual legacy router v-R0 and FIG. 7B shows a case where the virtual router 340 has a plurality of virtual legacy routers v-R1, v- R2).

The virtual router creation unit 320 may allow the virtual router 340 to include a router identifier, for example, a lookback IP address.

The virtual router creation unit 320 may be configured such that the virtual router 340 has the ports for the virtual routers corresponding to the edge ports of the switch groups, that is, the edge ports of the first and third edge switches SW1 and SW3. For example, as in the case of FIG. 7A, the port of the v-R0 virtual legacy router is connected to the eleventh port (port 11) of the first switch SW1, and the port 32 of the third switch SW3 (port 32, port 33) can be used as it is.

The port of the virtual router 340 may be associated with the identification information of the packet. The identification information of the packet may be tag information such as vLAN information of the packet and a tunnel ID added to the packet when connected through the mobile communication network. In this case, one virtual port of the open flow edge switch can create multiple virtual router ports. The virtual router port associated with the identification information of the packet may contribute to allowing the virtual router 340 to operate as a plurality of virtual legacy routers. If you create a virtual router with only the physical ports (physical ports) of the edge switch, you will be limited by the number of physical ports. However, when associated with packet identification information, such constraints are eliminated. It can also be made to work similar to the flow of legacy packets in legacy networks. It can also drive virtual legacy routers per user or user group. The user or user group can be identified by packet identification information such as vLAN or tunnel ID. Referring to Fig. 7 (b), the switch group is virtualized into a plurality of virtual legacy routers v-R1 and v-R2, and each port vp11 of the plurality of virtual legacy routers v- 13, vp 21-23) may be associated with the identification information of the packet, respectively.

Referring to FIG. 7 (b), connection between a plurality of virtual legacy routers (v-R1, v-R2) and a legacy router is established by connecting a plurality of subinterfaces in which one real interface of the first legacy router Or may be connected to a plurality of physical interfaces, such as the second and third legacy routers R2 and R3.

The virtual router generating unit 320 generates a virtual router by connecting a plurality of network devices connected to the first to fifth switches SW1 to SW5 to the external network vN ). ≪ / RTI > This allows the legacy network to access the network devices of the open flow switch group. In the case of FIG. 7A, the virtual router creation unit 320 has created the 0th port (port 0) in the 0th virtual legacy router (v-R0). 7 (b), the virtual router generating unit 320 generates the tenth and twentieth ports vp 10 and vp 20 in the first and second virtual legacy routers v-R1 and v-R2 . The generated ports (port 0, vp 10, vp 20) may have the same information as a plurality of network devices connected to the switch group. The external network vN may be configured with all or a part of a plurality of network devices.

The information of the virtual router ports (port 0, por 11v, port 32v, port 33v, vp 10 ~ 13, vp 20 ~ 23) may have port information of the legacy router. For example, the port information for the virtual router includes MAC address, IP address, port name, connected network address range, and legacy router information of each virtual router port, and further includes a vLAN range, a tunnel ID range, The port information may be inherited by the edge port information of the first and third edge switches SW1 and SW3 or may be designated by the virtual router generating unit 320 as described above.

The data plane of the network of Fig. 6 by the virtual router 340 generated in the virtual router 340 can be virtualized as shown in Fig. 7 (a) or Fig. 7 (b). For example, in the case of FIG. 7A, the virtualized network is configured such that the first to fifth switches SW1 to SW5 are virtualized into the virtual legacy router v-R0, and the virtualized legacy router v- The 11th, 32v, and 33v ports (ports 11v, 32v, and 33v) are connected to the first to third legacy routers R1 to R3 and are connected to the 0th port of the 0th virtual legacy router (v- port 0) may be connected to an external network (vN) which is at least a part of a plurality of network devices.

The routing processor 330 may generate the routing table 335 when the virtual router 340 is created. The routing table 335 is a table used for reference to routing in a legacy router. The routing table 335 may comprise some or all of the RIB, FIB, and ARP tables. The routing table 335 may be modified or updated by the routing processing unit 330.

The routing processor 330 may generate a legacy routing path for the flow inquired by the controller 10. [ The routing processing unit 330 uses a part or all of the received packet received from the open flow switch in the flow, the port information into which the received packet is input, the virtual router 340 information, and the routing table 335, Information can be generated.

The routing processor 330 may include a third party routing protocol stack to determine legacy routing.

10 is a flowchart of a method of determining whether legacy routing is performed for the flow of the controller of FIG. 6 to 9.

The legacy routing decision method for the flow refers to whether the controller 10 should perform general SDN control or flow control to the legacy routing agent 300 for the flow received from the open flow switch.

Referring to FIG. 10, the controller 10 determines whether the flow-in port is an edge port (S510). If the flow-in port is not an edge port, the controller 10 may perform an SDN-based flow control by calculating a path to a general open flow packet (S590).

If the flow-in port is an edge port, the controller 10 determines whether packets of the flow can be interpreted (S520). If the packet can not be interpreted, the controller 10 may forward the flow to the legacy routing agent 300 (S550). In the case of a protocol message used only in a legacy network, a general SDN-based controller can not interpret a packet.

If the received packet is a legacy packet such as is transmitted from the first legacy network to the second legacy network, the SDN based controller 10 can not calculate the routing path of the imported legacy packet. Thus, if the controller 10 can not compute the path, such as a legacy packet, the controller 10 preferably sends the legacy packet to the legacy routing agent 300. However, knowing the final processing method of the edge port and the legacy packet to which the legacy packet will flow, the controller 10 can process the legacy packet through the flow modification. If the packet can be interpreted, the controller 10 searches the flow path such as whether the path of the flow can be calculated or whether there is an entry in the entry table (S530). If the path can not be retrieved, the controller 10 can forward the flow to the legacy routing agent 300 (S550). If the path can be searched, the controller 10 may generate a packet-out message specifying the output of the packet and transmit the packet-out message to the open flow switch of the packet inquiry (S540). A detailed example of this will be described later with reference to FIG. 11 and FIG.

FIG. 11 is a signal flow diagram according to an integrated routing method according to an embodiment of the present invention, FIG. 12 is a signal flow diagram according to an integrated routing method according to another embodiment of the present invention, and FIG. Flow table. Please refer to Figs. 6 to 10.

11 shows a flow of processing a legacy protocol message in an SDN-based network to which the present invention is applied. 11 shows a case where a hello message of OSPF (Open Shortest Path First) protocol is received by the first edge switch SW1.

In this example, it is assumed that the open-flow switch group is virtualized by the controller 10 and the legacy routing agent 300 as shown in Fig. 7 (a).

Referring to FIG. 11, when the first legacy router R1 and the first edge switch SW1 are connected, the first legacy router R1 transmits a hello message (Hello1) of the OSPF protocol to the first edge switch SW1 (S410).

Since there is no flow entry for the received packet in the table 291 of the first edge switch SW1, the first edge switch SW1 sends a packet-in message to the controller 10 informing of the unkown packet (S420). The packet-in message preferably comprises a flow comprising a Hello1 packet and an incoming port (port 11) information.

The message management module 130 of the controller 10 may determine whether the processing rule for the flow can be generated (S430). See Figure 10 for details of the determination method. In this example, since the OSPF protocol message is a packet that the controller 10 can not interpret, the controller 10 may forward the flow to the legacy routing agent 300 (S440).

The SDN interface module 345 of the legacy routing agent 300 transmits the Hello1 packet received from the controller 10 to the virtual router 340 corresponding to the port 11 of the first edge switch SW1 provided in the flow, Lt; / RTI > port (port 11v). When the virtual router 340 receives the Hello1 packet, the routing processor 330 can generate the legacy routing information of the Hello1 packet based on the routing table 335 (S450). In the present embodiment, the routing processor 330 generates a Hello2 message corresponding to the Hello1 message, and specifies a routing path for designating the output port as the 11v port (port 11v) so that the Hello2 packet is transmitted to the first legacy router R1 Can be generated. The Hello2 message has a destination which is the first legacy router R1 and a pre-designated virtual router identifier. The legacy routing information may include a Hello2 packet, and an output port that is an eleventh port. The routing processor 330 may generate the legacy routing information by using the information of the virtual router 340. However, the present invention is not limited thereto.

The SDN interface module 345 may forward the generated legacy routing information to the legacy interface module 145 of the controller 10 (S460). Either the SDN interface module 345 or the legacy interface module 145 may convert the 11v port (port 11v), which is the output port, to the 11th port (port 11) of the first edge switch SW1. Or the 11th port and the 11th port are the same, and port conversion can be omitted.

The path calculation module 125 of the controller 10 causes the Hello2 packet to be output to the eleventh port (port 11) of the first legacy router R1 by using the legacy routing information received through the legacy interface module 145 A path can be set (S470).

The message management module 130 generates a packet-out message to output the Hello2 packet to the 11th port (port 11), which is an incoming port, using the set path and the legacy routing information, and transmits the packet-out message to the first legacy router R1 (S480).

In the present embodiment, it is described as corresponding to the Hello message of the external legacy router, but is not limited thereto. For example, the legacy routing agent 300 may generate an OSPF hello message to be actively output to the edge port of the edge switch and send it to the controller 10. In this case, the controller 10 may transmit the hello packet to the open flow switch with a packet-out message. It is also possible to implement this embodiment by setting a packet-out message that does not correspond to a packet-in message such that the open-flow switch follows the packet-out message.

Fig. 12 shows a case where a general legacy packet is transmitted from the first edge switch SW1 to the third edge switch SW3.

The first edge switch SW1 starts receiving the legacy packet P1 whose destination IP address does not belong to the open flow switch group from the first legacy router R1 (S610).

Since there is no flow entry for packet P1, first edge switch SW1 may send packet P1 to controller 10 and inquire flow processing (packet-in message) (S620).

The message management module 130 of the controller 10 may determine whether SDN control for the flow is possible (S630). In this example, the packet P1 is resolvable but is directed to the legacy network, so that the controller 10 can not generate the path of the packet P1. The controller 10 can then forward the packet P1 and the eleventh port, which is an incoming port, to the legacy routing agent 300 via the legacy interface module 145 (S640).

The routing processor 330 of the legacy routing agent 300 generates the legacy routing information of the packet P1 based on the information of the virtual router 340 and the routing table 335 for the packet P1 received from the controller 10 (S650). In this example, it is assumed that the packet P1 is output to the 32v port (port 32v) of the virtual router. In this case, the legacy routing information includes an output port that is the 32v port (port 32v), a destination MAC address that is the MAC address of the second legacy router R2, and a source MAC Address. This information is the header information of the packet output from the legacy router. For example, when the first legacy router R1 reports the virtual legacy router v-R0 to the legacy router and transmits the packet P1, the header information of the packet P1 is as follows. The source and destination IP addresses are the same as the header information when the packet P1 is generated, and thus will be omitted from the description. The source MAC address of packet P1 is the MAC address of the output port of router R1. The destination MAC address of the packet P1 is the MAC address of the 11v port (port 11v) of the virtual legacy router (v-R0). In the existing router, the packet P1 'output to the port 32v of the virtual legacy router (v-R0) can have the following header information. The source MAC address of the packet P1 'is the MAC address of the 32v port (port 32v) of the virtual legacy router v-R0, and the destination MAC address is the MAC address of the incoming port of the second legacy router. That is, part of the header information of the packet P1 changes during the legacy routing.

In order to correspond to the legacy routing, the routing processing unit 330 may generate the packet P1 'in which the header information of the packet P1 is adjusted and include it in the legacy routing information.

However, it is more preferable that the routing processing unit 330 does not generate the packet P1 'that changes the header information of the packet P1. When adjusting the header information of a packet in the routing processor 330, the controller 10 or the legacy routing agent 300 must process the incoming packet every time the same packet or a similar packet having the same destination address range is processed. Therefore, the step of changing the packet to the format after the existing routing is performed by an edge switch (third edge switch SW3 in this example) that outputs the packet to the external legacy network than the legacy routing agent 300 . To this end, the legacy routing information described above may include source and destination MAC addresses. The controller 10 may use this routing information to send a flow-Mod message to the third edge switch to change the header information of packet P1.

The SDN interface module 345 may forward the generated legacy routing information to the legacy interface module 145 of the controller 10 (S660). In this step, the output port can be converted to the edge port to be mapped.

The controller 10 can generate the flow processing rule in the open flow switch group using the legacy routing information received through the legacy interface module 145, in particular, the legacy route of the legacy routing information.

The path calculation module 125 of the controller 10 may calculate the path to be output from the first edge switch SW1 to the 32th port of the third edge switch SW3 using the legacy path in operation S670.

The message management module 130 transmits a packet-out message designating an output port for the packet P1 to the first edge switch SW1 based on the calculated path (S680), and transmits the packet to the open- (Flow-mode) change message (S690, S700). The message management module 130 may also send a flow-Mod message to the first edge switch SW1 to define processing for the same flow.

The flow entry according to the flow processing rule is preferably based on an identifier that identifies the data-packet corresponding to the flow managing the path of the packet P1. That is, the flow process for the packet P1 is preferably based on an identifier that can identify the legacy flow. To this end, a packet P1 to which a legacy identifier (tunnel ID) is added is included in a packet-out message transmitted to the first edge switch SW1, and a flow entry for attaching a legacy identifier (tunnel ID) . An example of a flow table of each switch is shown in Fig. 13A is a flow table of the first edge switch SW1. For example, Table 0 in FIG. 13 (a) adds tunnel 2 as a legacy identifier to the flow towards the second legacy router R2 and causes the flow to move to Table 1. The legacy identifier may be entered in a meta field or other field. Table 1 has a flow entry in which the flow having the tunnel 2 is output to the 14th port (port information of the first switch SW1 connected to the fourth switch SW4). Fig. 13B is an example of a flow table of the fourth switch SW4. In the table of FIG. 13 (b), the flow whose legacy identifier is tunnel2 among the flow information is output to the 43rd port (port 43) connected to the third switch SW3. Fig. 13 (c) is an example of a flow table of the third switch SW3. Table 0 in FIG. 13 (c) removes the legacy identifier of the flow whose legacy identifier is tunnel2 and causes the flow to move to Table 1. Table 1 outputs the flow to port 32. By using multiple tables in this way, the number of cases can be reduced. This makes it possible to perform a quick search and reduce resource consumption of memory and the like.

The first edge switch SW1 adds a legacy identifier (tunnel ID) to the packet P1 (S710), and transmits a packet to which a legacy identifier (tunnel ID) is added to the core network (S720). The core network means a network composed of the open flow switches SW2, SW4 and SW5, not the edge switches SW1 and SW3.

The core network may transmit the flow to the third edge switch SW3 (S730). The third edge switch SW3 may remove the legacy identifier and output packet P1 to the designated port (S740). In this case, although not shown in the flow table of FIG. 13, the flow table of the third switch SW3 preferably includes a flow entry for changing the destination and the source MAC address of the packet P1.

FIG. 14 is a structural diagram illustrating a container network management system according to an embodiment of the present invention. FIG. 15 is a block diagram of a host that mainly shows the internal structure of the host of FIG. Fig. 17 is a structure diagram showing another host internal structure of Fig. 14, Fig. 18 is a schematic diagram of Fig. 14, Fig. 19 is a network structure diagram of Fig. to be. Please refer to Figs. 1 to 13.

14, the container network management system includes an orchestrator 1, a controller 10, a legacy routing agent 300, and a plurality of hosts 800-1 and 800-2 Or to designate the whole).

The orchestrator 1 controls the internal network environment to allow the hosts 800-1 and 800-2 to create / delete containers in accordance with a user request or a policy, The network between the containers can be managed. The orchestrator 1 can control each of the hosts 800-1 and 800-2 through the controller 10. [

When the legacy routing agent 300 receives a packet processing request from the controller 10, the legacy routing agent 300 may generate legacy routing information of the packet and transmit the legacy routing information to the controller 10. If necessary, the legacy routing agent 300 may generate legacy protocol conversion information to make the packet conform to the legacy protocol, or may convert the packet to conform to the legacy protocol. The legacy protocol includes a legacy routing protocol.

The generated routing information or protocol conversion information can be stored as a table in the controller 10 or each of the hosts 800-1 and 800-2. In this case, the controller 10 can process the packet with the legacy routing agent 300 There is no need to inquire.

The host 800 may provide SDN-based virtual switches and containers. The host 800 is preferably a server having a physical-based computing function. 15, the host 800 includes a host control unit 810, an SDN-based virtual switch 820 (vSW), a container bridge 830, a container 840, a host storage unit 860 (DB) And an actual network interface 850, 852.

The host storage unit 860 may store a program for processing and controlling the host control unit 810. The host storage unit 860 may store the bridge net information and the container net information, which will be described later, in a DB format list. The host storage unit 860 may store data necessary for the virtual switch 820 or may store various identifiers.

The host control unit 810 can control the operation of each element of the host 800 to control the overall operation of the host 800. [ The host control unit 810 can generate the virtual switch 820, the container bridge 830, and the container 840, and can network-couple with each other to enable networking with each other.

The host control unit 810 can exchange data with the controller 10 or the external public network 5 (for example, the 'Internet') through the first and second physical network interfaces 850 and 852. The first and second physical network interfaces 850 and 852 may be implemented as one network interface.

The virtual switch 820 may correspond to the switch 20 of FIG. The virtual switch 820 may correspond to an edge switch, in particular, of the switch group of FIG. The virtual switch 820 can be virtually created by the host control unit 810. [ The virtual switch 820 can exchange messages with the controller 10 via the first physical network interface 850. The virtual switch 820 can exchange packets with the external network 5 through the second physical network interface 852. [ The second real network interface 852 may be operated by the host control unit 810 as a network interface of the virtual switch 820. [ The virtual switch 820 can perform an L2 / L3 network between containers in the same host and / or between each container in another host.

The container bridge 830 is generated by the host control unit 810 and can serve as a bridge between containers in the same server (host). The container bridge 830 may act as a hub, bridge and / or switch among existing network equipment. The container bridge 830 can perform the L2 network function between the containers.

Container bridge 830 sends the incoming packets from the container to virtual switch (s) in the absence of processing information for routing between containers belonging to different domains (networks), networks with containers belonging to other hosts, (820).

The container bridge 830 may be virtually network coupled with the virtual NI 821 of the virtual switch 820 via a bridge-switch NI (Network Interface) 832. [ Container bridge 830 may be network coupled with virtual NI 841 of container 840 via bridge-container 831.

The container bridge 830 may have a bridge identifier that identifies itself. The bridge identifier can distinguish the subnetwork environment established by the container bridge 830 from other network environments. The bridge identifier may be associated with network subnet information and gateway information. Network subnet information is needed for the IP address to be assigned to the container 840, and gateway information is needed for routing. The gateway information may initially have information (IP address, Mac address, etc.) for the second physical network interface 852 connected to the external network 5 by default. The network subnet information and the gateway information connected based on the bridge identifier may be DBed with Bridgetnet information. The network subnet information may include a plurality of pieces of information so that two or more subnetworks are constructed. The plurality of network subnet information may be divided into domain tags to be described later.

Container 840 is a kind of lightweight virtual machine that can operate lightly compared to a virtual machine by sharing an OS unlike an existing virtual machine, although it is a kind of virtual machine in which applications are operated independently. The container 840 may provide one or more services.

The container 840 can establish an independent network environment on the OS and configure the network topology through the virtual interface in the network environment. If the OS is Linux, the independent network environment can be implemented with namespace technology. The present invention particularly relates to a method of networking between containers 840.

Container 840 has a container identifier. The container 840 may inherit the bridge identifier of the upper container bridge 830. The container 840 may have the same domain identifier indicating the same domain. The container 840 has an IP address, and the IP address can be generated based on the bridged net information by a DHCP server (not shown). With the container identifier as a key, the IP address and the same domain identifier can be stored in the container net information list.

Container bridge 830 may assign a domain tag corresponding to the same domain identifier to bridge-container NI 831 based on the same domain identifier of container 840. [ The same domain identifier and domain tag may be the same.

The container bridge 830 may tag the tag assigned to the bridge-container NI 831 into which the packet flows into the packet incoming from the container 840. The domain tag may be a packet field such as vLAN, vxLAN, or metadata.

Container bridge 830 may route the packet to the bridge-container NI 831 with the domain tag tagged in the packet. Thereby, the container bridge 830 can provide container communication in the same host and the same network. This can reduce unnecessary broadcast or multicast traffic. The packets flowing out and / or flowing in the bridge-switch NI 832 of the container bridge 830 can flow in and out regardless of the domain tag of the flow-in packet.

The bridge-container NI 831 and the bridge-switch NI 832 may each have an associated MAC address. The bridge-container NI 831 can use the ARP protocol or know the MAC address of each container from the information received from the controller 10. The MAC information received from the controller 10 can be acquired from the container net information stored in advance as a member of the list. The bridge-switch NI 832 may have a MAC address of the gateway (second physical network interface 852 or a virtual MAC address to be described later), and a MAC address of a container belonging to the same domain of another host. Accordingly, the container bridge 830 may route the incoming packet to the appropriate one of the bridge-container NI 831 and the bridge-switch NI 832 via the destination MAC address of the incoming packet. If there is no NI associated with the MAC address of the incoming packet among the bridge-container NI 831 and the bridge-switch NI 832, the container bridge 830 may route the incoming packet to the bridge-switch NI 832.

Referring to FIG. 16, the host controller 810 may generate the virtual switch 820 (S900). Generation of the virtual switch 820 may be generated when the host 800 is booted or may be generated upon receipt of a container creation message or a container bridge creation message from the orchestrator 1 or the controller 10. [

The host control unit 810 is connected to the virtual switch 820 and the second physical network interface 852 so that the virtual switch 820 can exchange packets with the external network 5 via the second physical network interface 852. [ (S905).

The host control unit 810 can generate the container bridge 830 when receiving a message instructing the container bridge generation from the orchestrator 1 or the controller 10 (S910). The container bridge creation message may include a bridge identifier, gateway information, and network subnet information. If there is the same bridge identifier, the host control unit 810 can send a failure message to the controller 10.

As described above, the network subnet information can be constructed with a number of subnetworks equal to or greater than the number of domain tags. A plurality of subnet information establishing two or more subnetworks may be associated with a domain tag or the same domain identifier. The container bridge creation message may further include a same domain identifier (or domain tag) list. The elements of the domain tag list and the plurality of subnet information of the network subnet information are associated with each other.

The host control unit 810 can network-couple the virtual NIs of the virtual switch 820 and the container bridge 830, respectively (S915). The packet may be delivered from the container bridge 830 to the virtual switch 820 regardless of its domain tag.

The host control unit 810 can generate the container 840 (S930) when receiving a message instructing the container creation from the orchestrator 1 or the controller 10 (S925). The container creation message may comprise a bridge identifier, a container identifier, and a same domain identifier. The host control unit 810 can perform error processing when the same container identifier exists or when the bridge identifier does not exist.

The host control unit 810 can assign a unique IP address to the container 840 using the DHCP function (S935). In addition, the host controller 810 may network-couple the container bridge 830 and the container 840 (S840).

The host controller 810 may assign the domain tag associated with the same domain identifier of the container 840 to the bridge-container NI 831 (S845).

The host 800 may be implemented as an embodiment having various virtual switches and container bridges. Referring to FIG. 17, one virtual switch may have two container bridges like the first host 800-3, or two virtual switches, such as the third host 800-5. The first and third hosts 800-3 and 800-5 can be treated like the second host 800-4. This can be implemented by configuring the connection structure of the bridge-switch NI 832 and the virtual NI 821 of the virtual switch 820 to a trunk structure or a plurality of sub-channels. You can also control two or more hosts as if they were a single host. Two or more hosts may be connected to other external switches such as the first host 800-3 and the second host 800-4 or may be connected to the second host 800-4 and the third host 800-5, Lt; RTI ID = 0.0 > and / or < / RTI > across other networks. The other network may be the same as the external network 5 connected to the second host 800-4. The virtual switch vSW not directly connected to the external network 5 in Fig. 17 can correspond to the switches constituting the core network in Fig.

Hereinafter, for the sake of simplicity and explanation, it is assumed that the internal structure and the connection structure of the host in Fig. 14 according to an embodiment of the present invention are as shown in Fig. The first and second hosts h1 and h2 are connected through a single legacy router R0 and the first host h1 is connected to the first virtual switch vSW1 and the first container bridge CT.Br.1 And the second host h2 comprises a second virtual switch vSW2, a second container bridge CT.Br.2, and a fourth container h1, To fifth containers (ct4, ct5). The first, second and fourth containers (ct 1, 2, 4) are connected to the bridge-container NI having the vLAN 100, respectively, and the third and fifth containers ct3 , ct5 are connected to the bridge-container NI having the vLAN 200, respectively.

The first and second hosts h1 and h2 of FIG. 17 can be interpreted by the legacy routing agent 300 as a topology roll-up structure as shown in FIG. 19 in the legacy router R0. The first and second hosts h1 and h2 are connected to the first-0 and the second-0 virtual routers vR and vR, respectively, which respectively have virtual network interfaces connected to the legacy router R0 as shown in Fig. I.0, vR.II.0) or the 1-1, 1-2, 2-1, and 2-2 virtual routers (FIG. 19 (b) vR.I.1, vR.I.2, vR.II.1, vR.II.2). The first to fifth containers ct1 to ct5 may correspond to the external network vN in Fig.

The virtual port information (P.v.I.0, P.v.R.) associated with the legacy router R0 of the first-0 and second-0 virtual routers (vR.I.0, vR.II.0). II.0) preferably include actual network interfaces (IP address and MAC address) of the first and second hosts h1 and h2, respectively.

The legacy of the 1-1, 1-2, 2-1, and 2-2 virtual routers (vR.I.1, vR.I.2, vR.II.1, vR.II.2) The virtual port information (P.vR.I.1, P.vR.I.2, P.vR.II.1, P.vR.II.2) associated with the router (R0) includes a virtual MAC address, It is preferable to provide each of the same domain identifiers and an IP address according to the network subnet information.

FIG. 20 is a flow chart of a method for changing a default gateway of a container, and FIGS. 20 to 23 are signal flow charts of packet flow from one container to another. 1 to 19, in particular, Figs. 14 to 19. Hereinafter, for the sake of simplicity of explanation, the network topology structure of FIG. 18 is assumed assuming FIG. 19 (a). It is also assumed that each container, container bridge, and / or virtual switch knows the MAC address of another container belonging to the same domain from the ARP message or controller 10, and the container has only one virtual port.

Fig. 20 shows the flow of packets from the first container ct1 to the second container ct2 belonging to the same host and the same domain. Since the first and second containers ct1 and ct2 belong to the same domain, the first packet pk1 generated by the first container ct1 is transmitted to the IP and MAC addresses a2 and m2 of the second container ct2, To the destination IP and MAC address.

The first container ct1 may transmit the first packet pk1 to the first container bridge CT.Br.1 (S1010). Since the first container bridge CT .BR 1 knows the bridge-container NI associated with the MAC address m 2, it can directly transmit the first packet pk 1 to the second container ct 2 (S 1020).

Figure 21 shows packet flows from a first container (ct1) to a third container (ct3) belonging to the same host and heterogeneous domain. Since the first and third containers ct1 and ct3 belong to different domains, the first container ct1 transmits the MAC address of the destination to the gateway address, that is, the MAC address m of the physical network interface of the first host h1. h1 in the second packet pk2. The first container ct1 may transmit the generated second packet pk2 to the first container bridge CT.Br.1 (S1110).

The first container bridge (CT.Br.1) may tag the domain tag (100) associated with the first container (ct1) in the vLAN field (S1115). The first container bridge CT.Br.1 transmits the second packet pk2 [100] having the vLAN of 100 to the first virtual switch vSW1 through the bridge-switch NI associated with the MAC address m.h1 serving as the gateway, (S1120).

The first virtual switch vSW1 can determine whether there is a flow entry of the destination IP address of the second packet pk2 [100]. If there is no flow entry, the first virtual switch vSW1 may transmit the second packet pk2 [100] to the controller 10 to request flow processing information (S1130).

Since the controller 10 knows the network information of the second container ct2, the controller 10 can generate the flow processing information of the second packet pk2. The controller 10 converts the vLAN of the second packet pk2 from 100 to the domain tag 200 to which the second container ct2 belongs and changes the destination and source MAC address from (m.h1 / m1) to (m2 / m. h1) (S1135). Step S1135 may be performed in the first virtual switch vSW1.

The MAC address and the vLAN-converted second packet pk2 [200] are transferred from the controller 10 to the first virtual switch vSW1 (S1140), from the first virtual switch vSW1 to the first container bridge (CT.Br (S1150), and from the first container bridge (CT.Br.1) to the second container (ct2) (S1160), respectively. The first container bridge CT.Br.1 may remove the vLAN information of the second packet pk2 and then forward the vLAN information to the second container ct2.

22 shows a packet flow from a first container ct1 to a fourth container ct4 belonging to the heterogeneous host and the same domain. Since the first and fourth containers ct1 and ct4 belong to the same domain, the first container ct1 transmits the third packet pk3 having the MAC address of the destination as the MAC address m4 of the fourth container ct4 Can be generated. The first container ct1 may transmit the generated third packet pk3 to the first container bridge CT.Br.1 (S1210).

The first container bridge (CT.Br.1) may tag the domain tag (100) associated with the first container (ct1) in the vLAN field. When the MAC address learning of the fourth container (ct4) is not performed in the first container bridge (CT.Br.1), or when the MAC address m4 is transmitted through the MAC address learning or the information received from the controller (10) - If the switch is designated as NI, the outgoing port of the packet becomes the bridge-switch NI. Therefore, the first container bridge CT.Br.1 transmits the third packet pk3 via the bridge-switch NI to the first virtual switch vSW1 as the third packet pk3 [100] having the vLAN of 100 (S1215).

The first virtual switch vSW1 can determine whether there is a flow entry of the destination IP address of the third packet pk3 [100]. If there is no flow entry, the first virtual switch vSW1 may transmit the third packet pk3 [100] to the controller 10 to request flow processing information (S1220).

The controller 10 knows the network information of the second container ct2. Accordingly, the controller 10 may convert the third packet pk3 into a domain tag associated with the domain identifier to which the second container belongs (S1225). Since the third packet pk3 will be transmitted to the external network 5, it is desirable to designate another vLAN even in the same domain. However, the third packet pk3 may retain the original vLAN.

The controller 10 determines whether there is legacy protocol conversion information of the third packet pk3 and if not, the third packet pk3 is transmitted to the legacy routing agent 300, pk3 [10]) (S1230).

The legacy routing agent 300 converts the destination MAC address of the third packet pk3 [10] to the MAC address m.R1 of the network interface of the legacy router R9 connected to the first host h1, The MAC address can be converted into the MAC address (m.h1) of the actual network interface of the first host (S 1235). This step can be performed in the controller 10 or the first virtual switch vSW1.

The converted third packet pk3 [10] is transferred to the controller 10 and the first virtual switch vSW1 (S1240 and S1245) and is transferred from the first virtual switch vSW1 to the legacy router R0 (S1250). The legacy router R0 transmits the destination and source MAC address of the third packet pk3 to the MAC address m.h2 of the physical network interface of the second host h2 and the MAC address m.h2 of the network interface of the legacy router R0, (M.R2) of the interface (S1255).

The legacy router R0 may transmit the third packet pk3 [10] to the second virtual switch vSW2 (S1260).

The second virtual switch vSW2 converts the domain tag (vLAN 100) associated with the vLAN 10, which is the domain tag of the third packet pk3, and converts the destination / source MAC address from (m.h2 / m.R2) m2 / m1) (S1265).

Thereafter, the converted third packet pk3 [100] may be transmitted from the second virtual switch vSW2 to the fourth container ct4 via the second container bridge CT.Br.2 (S1270, S1275).

Fig. 23 shows the flow of packets from the first container (ct1) to the fifth container (ct5) belonging to the heterogeneous host and heterogeneous domain. Since the first and fifth containers ct1 and ct5 belong to different domains, the first container ct1 transmits the MAC address of the destination to the gateway address, that is, the MAC address m of the physical network interface of the first host h1. h1) can be generated. The first container ct1 may transmit the generated fourth packet pk4 to the first container bridge CT.Br.1 (S1310).

The first container bridge (CT.Br.1) may tag the domain tag (100) associated with the first container (ct1) in the vLAN field. The first container bridge CT.Br.1 transmits the fourth packet pk4 [100] having the vLAN of 100 to the first virtual switch vSW1 through the bridge-switch NI associated with the MAC address m.h1 serving as the gateway, (S1315).

The first virtual switch vSW1 may determine whether there is a flow entry of the destination IP address of the fourth packet pk4 [100]. If there is no flow entry, the first virtual switch vSW1 may transmit the fourth packet pk4 [100] to the controller 10 to request the flow processing information (S1320).

The controller 10 knows the network information of the fifth container ct5. Accordingly, the controller 10 may convert the domain tag of the fourth packet pk4 into a domain tag associated with the domain identifier to which the fifth container ct5 belongs (S1325). Since the fourth packet pk4 will be transmitted to the external network 5, it is desirable to designate another vLAN even in the same domain. In addition, it is preferable to use a domain tag that distinguishes itself from a packet that is a homogeneous host and a homogeneous domain. For example, when the source container of the packet to the fifth container (ct5) is the same domain as the fifth container (ct5), the vLAN value of the fourth packet (pk4) is set to 20 and the fourth packet ) Can be set to 21. Since the first and fifth containers ct1 and ct5 are heterogeneous domains, the controller 10 may convert the domain tag of the fourth packet pk4 to 21.

The controller 10 determines whether there is legacy protocol conversion information of the third packet pk3 and if not, the third packet pk3 is transmitted to the legacy routing agent 300, pk3 [10]) (S1330).

The legacy routing agent 300 converts the destination MAC address of the third packet pk3 [10] to the MAC address m.R1 of the network interface of the legacy router R9 connected to the first host h1, The MAC address can be converted into the MAC address (m.h1) of the actual network interface of the first host (S1335). This step can be performed in the controller 10 or the first virtual switch vSW1.

The converted fourth packet pk4 [21] is forwarded to the controller 10 and the first virtual switch vSW1 (S1340 and S1345) and can be transferred from the first virtual switch vSW1 to the legacy router R0 (S1350). The legacy router R0 transmits the destination and source MAC address of the fourth packet pk4 to the MAC address m.h2 of the actual network interface of the second host h2 and the MAC address m.h2 of the real network interface of the legacy router R0, (M.R2) of the interface (S1355).

The legacy router R0 may transmit the fourth packet pk4 [21] to the second virtual switch vSW2 (S1360).

The second virtual switch vSW2 converts the domain tag (vLAN 200) associated with the vLAN 21, which is the domain tag of the fourth packet pk4, and converts the destination / source MAC address from (m.h2 / m.R2) m2 / m.h1) (S1365).

Thereafter, the converted fourth packet pk4 [200] may be transmitted from the second virtual switch vSW2 to the fifth container ct5 via the second container bridge CT.Br.2 (S1370, S1375).

The present invention can be implemented in hardware or software. The present invention can also be embodied as computer readable code on a computer readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and may be implemented in the form of a carrier wave (for example, transmission via the Internet) . The computer readable recording medium may also be distributed over a networked computer system so that computer readable code can be stored and executed in a distributed manner. And functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers skilled in the art to which the present invention pertains.

10: controller 20: SDN switch
30: Network device 100:
120: Topology management module 125: Path calculation module
130: Message management module 135: Entry management module
190: storage unit 200: switch control unit
205: port portion 210; Controller communication section
220: Flow Search Module 230: Flow Processing Module
235: Packet processing module 240: Table management module
300: Integrated testing framework
310: Emulator
320: Wrapper module
330: Platoon
800: Host

Claims (3)

Machine learning based network automation system framework;
An agent for injecting learning information through the automation framework;
An event branch module for branching and setting according to setting information of an actual equipment through an event of the agent;
An action plug-in connected to the event module to manage an action setting DB of an actual network automation;
A machine learning-based network automation system structure including network equipment to be controlled by the plug-in
The method according to claim 1,
The agent system is a machine learning based network automation system system structure that classifies according to an event situation set by an operator, and calls an event branching module through an API call accordingly.
The method according to claim 1,
The event module can call the corresponding event and action list through API call URL,
Based on the information received from the event module, each action list is checked, and each device is independently set based on the test-specific setting information received from the equipment emulator of the network,
After setting up the equipment, the framework of the network automation system structure based on machine learning that the framework builds the history based on this forwarding information.

Images