WO2017131285A1 - Container network management system and container networking method - Google Patents

Abstract

The present invention relates to a software defined network (SDN)-based container network management system and a container networking method of a container network, the container network management system and the container networking method enabling an L2/L3 network between containers, enabling unnecessary multicast and broadcast traffics to be reduced, and enabling a flexible network operation. The management system can comprise: a real network interface connected to a legacy network; an SDN-based virtual switch for transmitting/receiving a packet to/from the legacy network through the real network interface; a host control unit for generating the virtual switch; a container bridge generated by the host control unit, virtually network-coupled to the virtual switch through a bridge-switch network interface (NI), and having a bridge identifier for identifying itself; and a first host generated by the host control unit, allowing a unique IP address to be allocated on the basis of the bridge net information, and comprising a plurality of containers virtually network-coupled to the container bridge.

Description

Container Network Management System and Container Networking Methods

The present invention relates to a software defined network (SDN) -based container network management system and a container networking method of a container network, to enable L2 / L3 networks between containers, to reduce unnecessary multicast and broadcast traffic, The present invention relates to a management system and a networking method for enabling flexible network operation and enabling packet flow between a legacy network and an SDN network.

With the explosion of mobile device and server virtualization and the advent of cloud services, network demand has increased. SDN is a basic network infrastructure abstracted from the application, logically centralized network intelligence, and separated from the control plane and data plane.

Open flow separates high speed packet delivery and high level routing decision functions. The packet forwarding plane is still involved in the switch stage, while high-level routing decisions are involved in separate controllers, which communicate through open flow protocols.

However, as a transitional transition from existing networks to SDN, there is a need for software defined networks that interact with existing protocols and devices. The equipment constituting the hybrid SDN network consumes less computing resources or networking resources and needs to have a simple structure.

Lightweight containers, which are different from existing virtual machines, are used instead of virtual machines. Containers do not have network management, and all containers are in the same L2 domain. This makes it difficult to manage the policy of the network and makes it difficult to manage network functions by services. In addition, there was no service providing interworking between containers and external networks. In the case of the existing cloud-based service, management of frontend / backend networks for each service is required. Only the front end is accessible from the public network, and the rest of the computing work is done only on the back end network, which is private. Containers do not have such a network management mechanism, which makes it difficult to manage the network.

<Preceding technical literature>

Non-Patent Document 1. OpenFlow Switch Specification version 1.4.0 (Wire Protocol 0x05), October 14, 2013 [https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow -spec-v1.4.0.pdf]

Non-Patent Document 2: Software-Defined Networking: The New Norm for Netwrks, ONF White Paper, April 13, 2012 [https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp -sdn-newnorm.pdf]

Non-Patent Document 3: ETSI GS NFV 002 v1.1.1 (2013-10)

[http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf]

SUMMARY OF THE INVENTION An object of the present invention is to provide a network environment for enabling container management of a container, to provide a network environment for enabling L2 / L3 networks, and to enable a private network separate from an external network under container operation. To provide.

In addition, another object of the present invention is to provide a system and method for supporting a legacy network in an SDN-based container network.

The container network management system according to the present invention includes a real network interface connected to a legacy network; A software defined network (SDN) -based virtual switch that exchanges packets with a legacy network through the real network interface; A host controller generating the virtual switch; A container bridge generated by the host controller and virtually network coupled with the virtual switch through a bridge-switch network interface (NI), the container bridge having a bridge identifier identifying itself; A database for storing network subnet information and gateway information using the actual network interface as a gateway based on the bridge identifier as bridge net information; And a first host generated by the host controller, assigned with a unique IP address based on the bridge net information, and having a plurality of containers virtually network coupled to the container bridge.

The host according to the present invention comprises a real network interface connected to a legacy network; A software defined network (SDN) based virtual switch controlled by an external controller to exchange packets with a legacy network through the actual network interface; A host controller generating the virtual switch; A container bridge generated by the host controller and virtually network coupled with the virtual switch through a bridge-switch network interface (NI), the container bridge having a bridge identifier identifying itself; A database for storing network subnet information and gateway information using the actual network interface as a gateway based on the bridge identifier as bridge net information; And a plurality of containers generated by the host controller, assigned a unique IP address based on the bridge net information, and virtually network-coupled to the container bridge.

A container networking method of a container network according to the present invention includes: creating a container and creating a virtual switch based on a software defined network (SDN) in a host connected to a legacy network through an actual network interface; Networking the virtual switch with the real network interface; When the host receives a container container bridge creation request including a bridge identifier for distinguishing a network environment, gateway information using the virtual switch as a gateway, and network subnet information, generating a container bridge; Network coupling the container bridge and the virtual switch such that packets having all the same domain identifiers pass between the container bridge and the virtual switch; When the host receives a container creation request including a first container identifier having a bridge identifier as a key and a first same domain identifier, generating a first container having the first container identifier; Assigning an IP address to the first container based on network subnet information associated with the bridge identifier; And a bridge of the container bridge coupled to the container such that the container bridge and the first container are network coupled and only packets with a first domain tag associated with the first same domain identifier are delivered to the first container. And assigning the first domain tag to a container network interface (NI).

According to the present invention, it is possible to manage a network of containers in an SDN-based container network, to provide L2 / L3 networking between containers, to be separated into a public network and a private network in which a service is operated, and to communicate with a legacy network. This allows existing legacy network equipment to be used as is.

1 is a structural diagram of an SDN network system;

FIG. 2 is a block diagram of a controller of the network system of FIG. 1;

3 is a block diagram of a switch of the network system of FIG.

4 is an operation table indicating a field table of a flow entry and an operation type according to the flow entry;

5 is a field table of a group and a meter table,

6 is a block diagram of a network system including an integrated routing system according to an embodiment of the present invention;

7 is a block diagram of a virtualized network of the network system of FIG.

8 is a block diagram of an SDN controller according to another embodiment of the present invention;

9 is a block diagram of a legacy routing container according to an embodiment of the present invention;

FIG. 10 is a flowchart illustrating a method of determining legacy routing for a flow of the controller of FIG. 6.

11 is a signal flow diagram according to an integrated routing method according to an embodiment of the present invention;

12 is a signal flow diagram according to an integrated routing method according to another embodiment of the present invention;

13 is a flow table according to an embodiment of the present invention;

14 is a structural diagram showing a container network management system according to an embodiment of the present invention;

FIG. 15 is a block diagram of a host mainly showing the internal structure of the host of FIG.

16 is a flow chart of a container creation method according to an embodiment of the present invention;

17 is a structural diagram showing another host internal structure of FIG. 14;

18 is a structural diagram briefly showing FIG. 14;

19 is a network structure diagram of FIG. 18 converted to a legacy virtual router, and

20 through 23 are signal flow diagrams for packet flows from one container to another.

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

Terms such as first and second 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 the second component, and similarly, the second component may also be referred to as the first component. The term and / or includes a combination of a plurality of related items or any item of a plurality of related items.

When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between. In addition, when the first component and the second component on the network are connected or connected, it means that data can be exchanged between the first component and the second component by wire or wirelessly.

In addition, the suffixes "module" and "unit" for the components used in the following description are merely given in consideration of ease of preparation of the present specification, and do not give particular meanings or roles by themselves. Therefore, the "module" and "unit" may be used interchangeably.

Such components may be configured by combining two or more components into one component, or by dividing one or more components into two or more components as necessary when implemented in an actual application. The same reference numerals are given to the same or similar components throughout the drawings, and detailed descriptions of the components having the same reference numerals may be omitted by replacing the descriptions of the aforementioned components.

SDN is a separate concept from the data plane that carries packets and the control plane that controls the flow of packets. When a packet occurs in the SDN, the network equipment asks the SDN control software (controller) where to forward the packet and reflects the result to determine the path and method of transmitting the packet. SDN is a theoretical concept, and Openflow has emerged for practical application. In other words, OpenFlow is a standard interface established to implement SDN. Openflow is composed of an openflow controller and an openflow switch to control flow information to determine the delivery path and method of the packet. Throughout this specification, openflow and SDN may be used interchangeably or in the same sense.

A flow may refer to a packet flow of a specific path according to a combination of a series of packets or multiple flow entries of multiple switches that share a value of at least one header field from one switch perspective. Openflow networks can perform path control, failover, load balancing and optimization on a flow-by-flow basis.

Certain terms herein may be defined by the following description or may have a meaning other than the original meaning. "Flow" may mean the packet itself to be processed by the switch. "Flow" may also include a packet to be processed by the corresponding switch and metadata (an inlet port entered by the packet, an inlet port of the other switch when the packet comes in from another switch, etc.). The “flow processing information” is information for processing a packet introduced from a switch, and may mean information necessary for modifying a packet or metadata of a packet and / or a specific network interface (port) through which the packet is leaked. 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. "Flow processing" may mean that the switch processes a packet or a flow based on the flow processing information.

1 is a block diagram of an SDN network system, FIG. 2 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. An operation table showing the operation type according to the field table and the flow entry, FIG. 5 is a field table of the group and meter table.

Referring to FIG. 1A, 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 point of view, the network device 30 may be a PC, a client terminal, a server, a workstation, a supercomputer, a mobile communication terminal, a smartphone, a smart pad, or the like. 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, antivirus, antispam, security services, access management services, firewalls, load balancing, QoS, video optimization, etc. It may include. This network function can be virtualized.

A virtualized network function is the Network Function Virtualization (NFV) defined in the NFV white paper (see Non-Patent Document 3) issued by the ETSI (European Telecommunication Standards Association). Network function (NF) can be used interchangeably with network function virtualization (NFV) herein. NFV dynamically creates the necessary L4-7 service connections per tenant to provide the necessary network functions, or in the case of DDoS attacks, quickly provides the necessary firewall, IPS, and DPI features through a series of service chaining. Can be. In addition, NFV can easily turn on or off firewalls or IDS / IPS and automatically provision them. NFV can also reduce the need for over-provisioning.

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

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

The storage unit 190 may store a program for processing and controlling the controller 100. The storage unit 190 may perform a function for temporarily storing input or output data (packets, messages, etc.). The storage unit 190 may include an entry database (DB) 191 that stores flow entries.

The controller 100 may control the overall operations of the controller 10 by controlling the operations of the respective units. The controller 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 controller 100, or may be configured in software separate from the controller 100.

The topology management module 120 may construct and manage network topology information based on a 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 190.

The path calculation module 125 may obtain a data path of a packet received through the switch communication unit 110 and an action string to be executed in the switch on the data path based on the network topology information constructed by the topology management module 120.

The entry management module 135 may register with the entry DB 191 as an entry such as a flow table, a group table, and a meter table based on a result calculated by the route calculation module 125, a policy such as QoS, a user indication, and the like. Can be. The entry management module 135 may allow an entry of each table to be registered in advance in the switch 20, or may be responsive to a request for adding or updating an entry from the switch 20. The entry management module 135 may change or delete an entry of the entry DB 191 as necessary or by an entry destruction message of the switch 10.

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

The switch 20 may be a physical switch or a virtual switch that supports the OpenFlow protocol. The switch 20 may process the received packet to relay the flow between the network devices 30. To this end, the switch 20 may be provided with one flow table or multiple flow tables for pipeline processing described in Non-Patent Document 1.

The flow table may include a flow entry that defines a rule of how to process the flow of the network device 30.

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

Referring to FIG. 3, the switch 20 includes a port unit 205 for communicating with another switch and / or a network device, a controller communication unit 210 for communicating with the controller 10, a switch control unit 200, and a storage unit ( 290).

The port portion 205 may have a plurality of pairs of ports connected to a switch or a network device. The pair of ports may 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. The table 230 or entries in the table may be added, modified, or deleted based on the message of the controller 10. The table entry can be discarded by itself by the switch 20.

Flow tables can be composed of multiple flow tables to handle the pipeline of OpenFlow. Referring to FIG. 4, a flow entry of a flow table includes match fields describing the conditions (control rules) matching packets, priority, counters updated when there is a match, Instructions, which are a set of various actions that occur when a packet is matched in a flow entry, timeouts describing the time to be discarded from the switch, and an opaque type selected by the controller. And may be used to filter flow statistics, flow changes, and flow deletions, and may include tuples such as cookies that are not used in packet processing.

Instructions can alter pipeline processing, such as forwarding packets to another flow table. Instructions can also include a set of actions that add an action to an action set, or a list of actions to apply directly to a packet. An action may mean an operation of modifying a packet such as transmitting a packet to a specific port or decreasing a TTL field. An action may belong to an action bucket associated with a group entry or part of a set of instructions associated with a flow entry. An action set means a set of accumulated actions indicated in each table. An action set can be performed when no table matches. 5 illustrates various packet processing by flow entries.

Pipeline means a series of packet processing between packet and flow table. When a packet enters the switch 20, the switch 20 searches for a flow entry matching the packet in the order of high priority of the first flow table. If a match is found, the instruction of the entry is executed. Instructions are executed immediately after a match (apply-action), clear-action (write-action), metadata modification (write-metadata), specified There are goto-tables that move packets with metadata into tables. If there is no flow entry matching the packet, the packet may be dropped or sent to the controller 10 in a packet-in message according to the table setting.

The group table may include group entries. The group table may be indicated by the flow entry to suggest additional forwarding methods. Referring to FIG. 5A, a group entry of a group table may include the following fields. A group identifier that identifies the group entry, a group type that specifies a rule as to whether to perform some or all of the action buckets defined in the group entry, a counter of the flow entry Counters for statistics, and action buckets, which are a set of actions associated with parameters defined for a group.

The meter table consists of meter entries and defines per-flow meters. Per flow meter can allow openflow to apply 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, meter bands indicating a speed designated in a band and a packet operation method, and a packet. It consists of counter fields that are updated when running on the meter. Meter bands are band types that indicate how packets are processed, the rate used to select the meter band by the meter, and counters that are updated when packets are processed by the meter band. ), And fields such as type specific arguments, which are bad types with optional arguments.

The switch controller 200 may typically control the operations of the units to control the overall operation of the switch 20. The switch controller 200 may include a table management module 240, a flow search module 220, a flow processing module 230, and a packet processing module 235 that manage the table 291. Each module may be configured in hardware in the controller 200, or may be configured in software separate from the controller 200.

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

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

The flow processing module 230 may process an action such as outputting, dropping, or modifying a specific header field to a specific port or multiple ports according to the procedure described in the entry retrieved by the flow retrieval module 220. have.

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

The packet processing module 235 may actually output the packet processed by the flow processing module 230 to one or two 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 may create, change, and delete virtual network devices, virtual switches, and the like. When the orchestrator 1 creates a virtual network device, the orchestrator 1 identifies the switch to which the virtual network will connect, the port identification to the switch, the MAC address, the IP address, and the tenant identification. Information of the network device such as information and network identification information can be provided to the controller 10.

The controller 10 and the switch 20 communicate with the orchestrator 1 via a separate interface, or the orchestrator 1 through the switch communication unit 110 of the controller 10 and the controller communication unit 210 of the switch 20. ) Can be communicated with. The switch 20 may exchange messages with the orchestrator 1 through the controller 10.

The controller 10 and the switch 20 exchange various information, which is called an openflow protocol message. Such open flow messages include types such as controller-to-switch messages, asynchronous messages, and symmetric messages. Each message may have a 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, and is mainly used to manage or check the state of the switch 20. The controller-switch message may be generated by the controller 100 of the controller 10, in particular the message management module 130.

Controller-switch messages include features for querying the capabilities of the switch, configurations for querying and setting settings for the configuration parameters of the switch 20, flows / groups / meters in the OpenFlow table. A modify state message for adding / deleting / modifying entries, a packet-out message for sending a packet received from the switch to a particular port on the switch via a packet-in message, and the like. There is this. Status change messages include modify flow table messages, modify flow entry messages, modify group entry messages, port modification messages, and meter entry changes. Message (meter modification message).

The asynchronous message is a message generated by the switch 20 and used to update the state of the switch, network events, and the like in the controller 10. The asynchronous message may be generated by the control unit 200 of the switch 20, in particular the flow retrieval 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 take control of the packet. The packet-in message includes all or part of a received packet or copy thereof sent from the openflow switch 20 to the controller 10 to request a data path when the switch 20 receives an unknown packet. Is a message. Packet-in messages are also used when the action of an entry associated with an incoming packet is destined to be sent to the controller. The deleted flow-removed message is used to convey to the controller 10 the flow entry information to be deleted in the flow table. This message occurs in the flow expiry process where the controller 10 has requested the switch 20 to delete the corresponding flow entry or because of a flow timeout.

Symmetric messages are generated by both the controller 10 and the switch 20, and are transmitted without the request of the other party. Hello used to initiate a connection between the controller and the switch, an echo to ensure that there is no problem with the connection between the controller and the switch, and an error message used by the controller or switch to notify the other side of the problem (error message) and the like. Error messages are mostly used in switches to indicate failures in response to requests initiated by the controller.

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 block diagram of the network system of FIG. 6, and FIG. 8 is a diagram illustrating another embodiment of the present invention. 9 is a block diagram of a legacy routing agent according to an embodiment of the present invention.

The network shown in FIG. 6 includes an SDN-based network including a controller 10 for controlling the flow of an open flow switch among a switch group consisting of a plurality of switches SW1-SW5, and first to third legacy routers R1-1. The legacy network of R3) is mixed. In the present specification, the SDN-based network means an independent network composed of only an open flow switch or 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 SDN-based network is composed of an open flow switch disposed at an edge of the network domain.

Referring to FIG. 6, the SDN-based integrated routing system according to the present invention may include a switch group including first to fifth switches SW1 to SW5, a controller 10, and a legacy routing agent 300. have. Detailed descriptions of the same or similar components refer to FIGS. 1 to 5.

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

In the present 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 a 32nd and 33rd port 32. port 33 is an edge switch connected 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.

Referring to FIG. 8, the controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190 communicating with the switch 20.

The controller 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 controller 100, or may be configured in software separate from the controller 100. Description of elements of the same reference numerals is made with reference to FIG. 2.

When the switch group is configured only with the openflow switch, the functions of the topology management module 120 and the path calculation module 125 are the same as those described with reference to FIGS. 1 to 5. When the switch group is composed of an open flow switch and an existing legacy switch, the topology management module 120 may obtain connection information with the legacy switch through the open flow switch.

The legacy interface module 145 can 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 relationship 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 cannot generate the processing rule of the flow included in the flow query message received from the open flow switch, the message management module 130 may transmit the flow to the legacy routing agent 300 through the legacy interface module 145. have. The flow may include a packet received by the open flow switch and port information of the switch that received the packet. When the processing rule of the flow cannot be generated, there may be a case in which the received packet is configured by the legacy protocol and cannot be interpreted, and the path calculation module 125 cannot calculate the path for the legacy packet.

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

The SDN interface module 345 can 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. The legacy interface module 145 and the SDN interface module 345 may communicate in a specific protocol or in a specific language. The legacy interface module 145 and the SDN interface module 345 may translate or interpret messages exchanged between the controller 10 and the legacy routing agent 300.

The virtual router generation unit 320 may generate and manage the virtual router 340 by using topology information of the switch group received through the SDN interface module 345. Through the virtual router 340, a switch group may be treated as a legacy router in an external legacy network, that is, the first to third routers R1 to R3.

The virtual router generation unit 320 may generate a plurality of virtual routers 340. FIG. 7 (a) shows a case where a virtual legacy router v-R0 is one virtual router 340, and FIG. 7 (b) shows a case where multiple virtual legacy routers v-R1 and v- have multiple virtual routers 340. The case of R2) is shown.

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

The virtual router generator 320 may allow the virtual router 340 to have virtual router ports corresponding to edge ports of the switch group, that is, edge ports of the first and third edge switches SW1 and SW3. For example, as shown in FIG. 7A, ports of the v-R0 virtual legacy router are ports 11 of the first switch SW1 and ports 32 and 33 of the third switch SW3. The information of (port 32, port 33) can be used as it is.

The port of the virtual router 340 may be associated with 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 a mobile communication network. In this case, multiple virtual router ports can be created with one actual port of the OpenFlow edge switch. 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 physical ports (physical ports) on the edge switch, you are limited by the number of physical ports. However, this restriction is eliminated when associating with packet identification information. It can also behave similarly to the flow of legacy packets in legacy networks. You can also run a virtual legacy router for each user or group of users. The user or user group may be divided into packet identification information such as vLAN or tunnel ID. Referring to FIG. 7B, the switch group is virtualized into a plurality of virtual legacy routers v-R1 and v-R2, and each port vp 11 of the plurality of virtual legacy routers v-R1 and v-R2. 13 and vp 21 to 23 may be associated with identification information of the packet, respectively.

Referring to FIG. 7B, the connection between the plurality of virtual legacy routers v-R1 and v-R2 and the legacy router is connected to several sub-interfaces in which one physical interface of the first legacy router R1 is separated. Or like a second and a third legacy router (R2, R3) can be connected to a plurality of real interfaces.

The virtual router generation unit 320 may include an external network (vN) in which a plurality of network devices connected to the virtual router 340 are connected to a plurality of network devices connected to the first to fifth switches SW1 to SW5. Can be treated as). This allows legacy networks to access network devices in the OpenFlow Switch Group. In the case of FIG. 7A, the virtual router generation unit 320 generates a 0th port (port 0) in the 0th virtual legacy router v-R0. In the case of FIG. 7B, the virtual router generation 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. . Each generated port (port 0, vp 10, vp 20) may have information such as a plurality of network devices connected to the switch group. The external network vN may consist of all or 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, and vp 20-23) may have port information of the legacy router. For example, the port information for the virtual router may include the MAC address, IP address, port name, network address range to which it is connected, legacy router information, and further include vLAN range, tunnel ID range, and so on. As described above, the port information may inherit edge port information of the first and third edge switches SW1 and SW3 or may be designated by the virtual router generation unit 320.

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

The routing processor 330 may generate the routing table 335 when the virtual router 340 is generated. The routing table 335 is a table used for referencing routing in legacy routers. The routing table 335 may consist of some or all of RIB, FIB, and ARP tables. The routing table 335 may be modified or updated by the routing processor 330.

The routing processor 330 may generate a legacy routing path for the flow inquired by the controller 10. The routing processor 330 uses legacy packets by using some or all of the received packets received from the open flow switch included in the flow, port information into which the received packets are introduced, 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.

FIG. 10 is a flowchart illustrating a method of determining legacy routing for a flow of the controller of FIG. 6. Reference is made to FIGS. 6 to 9.

The legacy routing determination method for the flow means whether the controller 10 should perform general SDN control on the flow received from the open flow switch or should inquire the legacy routing agent 300 for flow control.

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

If the flow inlet port is an edge port, the controller 10 determines whether the packet of the flow can be interpreted (S520). If the packet cannot be interpreted, the controller 10 may transfer the flow to the legacy routing agent 300 (S550). This is because, in case of a protocol message that a packet uses only in a legacy network, the SDN-based general controller cannot interpret the packet.

If the received packet is a legacy packet such as transmitted from the first legacy network to the second legacy network, the SDN-based controller 10 cannot calculate the routing path of the incoming legacy packet. Therefore, if the controller 10 cannot calculate the path, such as legacy packets, the controller 10 should send the legacy packet to the legacy routing agent 300. However, knowing the edge port to be leaked of the legacy packet and the final processing method of the legacy packet, the controller 10 can process the legacy packet through the flow modification. When the packet can be interpreted, the controller 10 searches for the flow path such as whether the path of the flow can be calculated or whether an entry exists in the entry table (S530). If the path cannot be retrieved, the controller 10 may transfer the flow to the legacy routing agent 300 (S550). If the path can be retrieved, 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 inquiring the packet (S540). A detailed example thereof will be described later with reference to FIGS. 11 and 12.

11 is a signal flow diagram according to the integrated routing method according to an embodiment of the present invention, FIG. 12 is a signal flow diagram according to the integrated routing method according to another embodiment of the present invention, and FIG. 13 is according to an embodiment of the present invention. Flow table. Reference is made to FIGS. 6 to 10.

11 illustrates a flow of processing legacy protocol messages in an SDN-based network to which the present invention is applied. FIG. 11 illustrates an example of receiving a hello message of an Open Shortest Path First (OSPF) protocol from the first edge switch SW1.

This example assumes that the open flow switch group is virtualized by the controller 10 and the legacy routing agent 300 as shown in FIG.

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. It may be (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 an unknown packet. (S420). The packet-in message preferably includes a flow having a Hello1 packet and incoming port (port 11) information.

The message management module 130 of the controller 10 may determine whether to generate a processing rule for the flow (S430). See FIG. 10 for details of the determination method. In this example, since the OSPF protocol message is a packet that cannot be interpreted by the controller 10, the controller 10 may transfer the flow to the legacy routing agent 300 (S440).

The SDN interface module 345 of the legacy routing agent 300 may transmit the Hello1 packet received from the controller 10 and the virtual router 340 corresponding to the inlet port port 11 of the first edge switch SW1 provided in the flow. Can be sent to port 11v. When the virtual router 340 receives the Hello1 packet, the routing processor 330 may generate legacy routing information of the Hello1 packet based on the routing table 335 (S450). In this embodiment, the routing processing unit 330 generates a Hello2 message corresponding to the Hello1 message, and designates a routing path for designating an output port as the 11v port so as to transmit the Hello2 packet to the first legacy router R1. Can be generated. The Hello2 message has a destination that is the first legacy router R1 and a predetermined virtual router identifier. The legacy routing information may include a Hello2 packet and an output port which is an eleventh port. In the present embodiment, the Hello1 packet is introduced into the virtual router 340, but the present invention is not limited thereto. The routing processor 330 may generate legacy routing information using the information of the virtual router 340.

The SDN interface module 345 may transfer the generated legacy routing information to the legacy interface module 145 of the controller 10 (S460). Any one of the SDN interface module 345 and the legacy interface module 145 may convert the eleventh port port 11v, which is an output port, into an eleventh port 11 of the first edge switch SW1. Alternatively, port conversion may be omitted by making the names of the eleventh port and the eleventh port the same.

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

The message management module 130 generates a packet-out message for outputting the Hello2 packet to port 11, which is an incoming port, by using the established route and legacy routing information, and transmits the packet-out message to the first legacy router R1. It may be (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 that is 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 openflow switch in a packet-out message. In addition, the present embodiment can be implemented by setting the OpenFlow switch to follow the instruction of the packet-out message even for a packet-out message that does not correspond to the packet-in message.

FIG. 12 illustrates 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 by receiving a legacy packet P1 whose destination IP address does not belong to the openflow switch group from the first legacy router R1 (S610).

Since the first edge switch SW1 has no flow entry for the packet P1, the first edge switch SW1 may transmit the packet P1 to the controller 10 and inquire of a flow process (packet-in message) (S620).

The message management module 130 of the controller 10 may determine whether SDN control of the flow is possible (S630). In this example, the packet P1 is interpretable but directed towards the legacy network, so the controller 10 cannot create a path for the packet P1. Accordingly, the controller 10 may transmit the packet P1 and the eleventh port, which is an incoming port, to the legacy routing agent 300 through the legacy interface module 145 (S640).

The routing processing unit 330 of the legacy routing agent 300 generates the legacy routing information of the packet P1 with respect to the packet P1 received from the controller 10 based on the information of the virtual router 340 and the routing table 335. Can be (S650). In this example, it is assumed that packet P1 should be output to port 32v of the virtual router. In this case, the legacy routing information includes an output port that is a 32v port (port 32v) for the packet P1, a destination MAC address that is a MAC address of the second legacy router R2, and a source MAC that is a MAC address of the 32v port. May contain an address. This information is 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. Since the source and destination IP addresses are the same as the header information when the packet P1 is generated, they will be omitted in this description. The source MAC address of the packet P1 is the MAC address of the output port of the router R1. The destination MAC address of the packet P1 is the MAC address of the eleventh port port 11v of the virtual legacy router v-R0. If the existing router, the packet P1 'output to the 32v port (port 32v) of the virtual legacy router (v-R0) may 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 inlet port of the second legacy router. That is, part of the header information of the packet P1 is changed during legacy routing.

In order to correspond to the legacy routing, the routing processor 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 'which changes the header information of the packet P1. When the routing processor 330 adjusts the header information of the packet, the controller 10 or the legacy routing agent 300 must process the incoming packet for the same packet or a similar packet having the same destination address range each time. Therefore, the step of transforming the packet into the format after the existing routing is performed by the packet switch at the edge switch (in this example, the third edge switch SW3) which outputs the packet to the external legacy network rather than the legacy routing agent 300. It is preferable. To this end, the legacy routing information described above may include a source and a destination MAC address. The controller 10 may use the routing information to transmit a flow-mod message to change the header information of the packet P1 to the third edge switch.

The SDN interface module 345 may transfer 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 an edge port to be mapped.

The controller 10 may generate a flow processing rule inside the openflow switch group by using the legacy routing information received through the legacy interface module 145, in particular, the legacy path of the legacy routing information.

The path calculation module 125 of the controller 10 may calculate a path to be output from the first edge switch SW1 to the 32nd port of the third edge switch SW3 by using the legacy path (S670).

The message management module 130 transmits a packet-out message specifying an output port for the packet P1 to the first edge switch SW1 based on the calculated path (S680) and flows to the openflow switch of the corresponding path. A change (flow-Mod) change message may be transmitted (S690 and S700). The message management module 130 may also transmit a flow-mod message to define the processing for the same flow to the first edge switch SW1.

The flow entry according to the flow processing rule is preferably based on an identifier identifying that it is a data-packet corresponding to the flow managing the path of the packet P1. That is, the flow processing for the packet P1 is preferably performed based on the identifier for identifying the legacy flow. To this end, the packet-out message transmitted to the first edge switch SW1 includes a packet P1 to which a legacy ID is added, and the flow change message includes a flow entry for adding a legacy ID to the packet-out message. It can be included. See FIG. 13 for an example of a flow table of each switch. FIG. 13A is a flow table of the first edge switch SW1. For example, Table 0 of FIG. 13 (a) adds tunnel2 to the flow with a legacy identifier to the flow destined for the second legacy router R2 and moves the flow to Table 1. Legacy identifiers may be written in metafields or other fields. Table 1 has a flow entry for outputting the flow having tunnel2 to the 14th port (port information of the first switch SW1 connected to the fourth switch SW4). 13B is an example of a flow table of the fourth switch SW4. The table of FIG. 13 (b) allows the flow having the legacy identifier of tunnel2 to be output to port 43 connected to the third switch SW3. 13C is an example of a flow table of the third switch SW3. Table 0 of FIG. 13C removes the legacy identifier of the flow whose legacy identifier is tunnel2 and moves the flow to Table 1. FIG. Table 1 outputs the flow to the 32nd port. Using multiple tables in this way can reduce the number of cases. This enables quick searching and can reduce resource consumption such as memory.

The first edge switch SW1 may add a legacy ID (tunnel ID) to the packet P1 (S710) or transmit a packet to which the legacy ID (tunnel ID) is added to the core network (S720). The core network refers to a network composed of open flow switches SW2, SW4, and SW5, not 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 the 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 source MAC addresses of the packet P1.

14 is a structural diagram showing a container network management system according to an embodiment of the present invention, FIG. 15 is a block diagram of a host mainly showing the internal structure of the host of FIG. 14, and FIG. 16 is an embodiment of the present invention. 17 is a structural diagram illustrating another host internal structure of FIG. 14, FIG. 18 is a schematic diagram of FIG. 14, and FIG. 19 is a network structural diagram of FIG. 18 converted to a legacy virtual router. to be. See FIGS. 1 to 13.

Referring to FIG. 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 specify all).

The orchestrator 1 allows container creation / deletion to each host 800-1 and 800-2 according to a user request or policy, controls the internal network environment, and controls each host 800-1 and 800-2. Manage networks between containers. The orchestrator 1 may control each host 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 corresponding packet and transmit the packet to the controller 10. If necessary, the legacy routing agent 300 may generate legacy protocol conversion information for the packet to conform to the legacy protocol or convert the packet to conform to the legacy protocol. Legacy protocols include legacy routing protocols.

The generated routing information or protocol conversion information may be stored as a table in the controller 10 or each host 800-1 and 800-2, in which case the controller 10 processes the packet to the legacy routing agent 300. There is no need to contact.

The host 800 may provide an SDN-based virtual switch and container. The host 800 may be a server having a physically based computing function, but is not limited thereto. Referring to FIG. 15, the host 800 includes a host controller 810, an SDN-based virtual switch 820 (vSW), a container bridge 830, a container 840, a host storage unit 860 (DB), And real network interfaces 850 and 852.

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

The host controller 810 may control the operation of each element of the host 800 to control the overall operation of the host 800. The host controller 810 may generate a virtual switch 820, a container bridge 830, and a container 840. The host controller 810 may network couple the virtual switch 820, the container bridge 830, the container 840, and the like so that the network can be networked with each other.

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

The virtual switch 820 may correspond to the switch 20 of FIG. 1. The virtual switch 820 may correspond to an edge switch in particular of the switch group of FIG. 6. The virtual switch 820 may be virtually generated by the host controller 810. The virtual switch 820 may exchange a message with the controller 10 through the first physical network interface 850. The virtual switch 820 may exchange packets with the external network 5 through the second physical network interface 852. By the host controller 810, the second physical network interface 852 can operate like the network interface of the virtual switch 820. The virtual switch 820 may perform an L2 / L3 network between containers within the same host and / or between each container of another host.

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

Container bridge 830 may include routing between containers belonging to different domains (networks), networks with containers belonging to different hosts, when the destination of packets is associated with virtual switch 820, and / or incoming packets from containers. If there is no processing information, the incoming packet from the container may be transmitted to the virtual switch 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. The container bridge 830 may be network coupled with the virtual NI 841 of the container 840 via the bridge-container 831.

Container bridge 830 may have a bridge identifier that identifies itself. The bridge identifier may distinguish the sub network environment established by the container bridge 830 from other network environments. The bridge identifier may be connected 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 real network interface 852 connected with the external network 5 by default. Network subnet information and gateway information connected based on the bridge identifier may be DBized as bridge net information. The network subnet information may be provided with a plurality of pieces of information such that two or more sub networks are established. The plurality of network subnet information may be divided into domain tags to be described later.

The container 840 is a kind of virtual machine in which applications operate independently, but unlike the existing virtual machine, the container 840 is a kind of lightweight virtual machine that can operate lighter than the virtual machine by sharing an OS. The container 840 may provide one or more services.

The container 840 may establish an independent network environment on the OS, and configure a network topology through a virtual interface in the network environment. If the OS is Linux, an independent network environment can be implemented with namespace technology. The invention relates in particular 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 may be generated based on the bridge net information by a DHCP server (not shown). The DHCP server is preferably located outside the host 800. This is because you need to generate an IP address for other hosts. The DHCP server may be implemented virtually, in which case the DHCP server may be created inside the controller 10 and / or the legacy routing agent 300. Using the container identifier as a key, the IP address and the same domain identifier may be stored as a container net information list.

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

The container bridge 830 may tag a tag designated to the bridge-container NI 831 to which the packet flows in a packet flowing from the container 840. The domain tag may use packet fields such as vLAN, vxLAN, or metadata.

Container bridge 830 may leak the packet to a domain-tagged bridge-container NI 831 tagged with the packet. As a result, the container bridge 830 may provide container communication in the same host and the same network. As a result, unnecessary broadcast or multicast traffic can be reduced. Outgoing and / or outgoing packets at the bridge-switch NI 832 of the container bridge 830 may go in and out regardless of the domain tag of the outgoing packet.

Bridge-container NI 831 and bridge-switch NI 832 may each have an associated MAC address. The bridge-container NI 831 may 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 may be obtained from container net information previously stored as a member of the list. The bridge-switch NI 832 may have the MAC address of the gateway (the second physical network interface 852 or the virtual Mac address, described below), and the MAC address of a container belonging to the same domain of another host. Accordingly, the container bridge 830 may exit the incoming packet to the appropriate NI of the bridge-container NI 831 and the bridge-switch NI 832 through the destination MAC address of the incoming packet. If none of the bridge-container NI 831 and bridge-switch NI 832 is associated with the MAC address of the incoming packet, then the container bridge 830 may exit the incoming packet to the bridge-switch NI 832.

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

The host controller 810 may include the virtual switch 820 and the second physical network interface 852 so that the virtual switch 820 may exchange packets with the external network 5 through the second physical network interface 852. Can be connected (S905).

When the host controller 810 receives a message instructing generation of the container bridge from the orchestrator 1 or the controller 10, the host controller 810 may generate the container bridge 830 (S910). The container bridge creation message may include a bridge identifier, gateway information, and network subnet information. If there is an identical bridge identifier, the host controller 810 may transmit a failure message to the controller 10.

As described above, the network subnet information may establish sub-networks equal to or greater than the number of domain tags. The plurality of subnet information for constructing two or more sub-networks may be associated with a domain tag or the same domain identifier. Accordingly, the container bridge generation message may further include the same domain identifier (or domain tag) list. Elements of the domain tag list and each of the plurality of subnet information of the network subnet information are associated with each other.

The host controller 810 may network couple the virtual NI of each of the virtual switch 820 and the container bridge 830 (S915). The packet may be forwarded from the container bridge 830 to the virtual switch 820 regardless of its domain tag.

When the host controller 810 receives a message instructing container creation from the orchestrator 1 or the controller 10 (S925), the host controller 810 may generate a container 840 (S930). The container creation message may include a bridge identifier, a container identifier, and the same domain identifier. The host controller 810 may process an error when the same container identifier exists or the bridge identifier does not exist.

The host controller 810 may allocate 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 designate a 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 in an embodiment having various virtual switches and container bridges. Referring to FIG. 17, two container bridges may be provided in one virtual switch like the first host 800-3 or two virtual switches may be provided like the third host 800-5. The first and third hosts 800-3 and 800-5 may be treated like the second host 800-4. This may be implemented by configuring a connection structure between the bridge-switch NI 832 and the virtual NI 821 of the virtual switch 820 as a trunk structure or a plurality of subchannels. You can also control two or more hosts as if they were one host. Two or more hosts are connected to other external switches, such as the first host (800-3) and the second host (800-4), or the second host (800-4) and the third host (800-5) It can be connected through tunneling across other networks, such as: 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 of FIG. 17 may correspond to a switch constituting the core network of FIG. 6.

Hereinafter, for the sake of simplicity and description, it is assumed that the internal structure and the connection structure of the host of FIG. 14 according to an embodiment of the present invention are the same as those of FIG. 18. The first and second hosts h1 and h2 are connected through one 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 first to third containers ct1, ct2, and ct3, and the second host h2 includes a second virtual switch vSW2, a second container bridge CT.Br.2, and a fourth To fifth containers ct4 and ct5. The domain tag will use vLAN, and the first, second, and fourth containers ( ct 1, 2, 4) are connected to the bridge-container NI with vLAN 100, respectively, and the third and fifth containers (ct3). ct5) are each connected to a bridge-container NI with vLAN 200.

The first and second hosts h1 and h2 of FIG. 17 may be interpreted by the legacy routing agent 300 as a topology structure as shown in FIG. 19 in the legacy router R0. The first and second hosts h1 and h2 are virtual ports 1-0 and 2-0 virtual routers (vR.), Each of which has a physical network interface connected to the legacy router R0 as a virtual port, as shown in FIG. I.0, vR.II.0) or first-first, first-second, second-first, and second-second virtual routers generated by domain tags as shown in 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 of FIG. 7.

Virtual port information (P.vR.I.0, P.vR.) connected to the legacy router (R0) of the 1-0 and 2-0 virtual routers (vR.I.0, vR.II.0). II.0) preferably comprises the actual network interfaces (IP address and MAC address) of the first and second hosts h1 and h2, respectively.

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) connected to the router R0 has a virtual MAC address. It is preferable to have an IP address having the same network as the legacy router R0.

20 through 23 are signal flow diagrams for packet flows from one container to another. Reference is made to FIGS. 1 to 19, in particular FIGS. 14 to 19. Hereinafter, for simplicity of explanation, the network topology structure of FIG. 18 is assumed and described with reference to FIG. 19A. In addition, it is assumed that each container, container bridge, and / or virtual switch knows the MAC address of an ARP message or controller 10 (ctr) from another container belonging to the same domain, and assumes that the container has only one virtual port. do.

FIG. 20 illustrates a packet flow from a first container ct1 belonging to the same host and the same domain to a second container ct2. 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 the IP of the second container ct2 and the aerosols a2 and m2. Has the destination IP and MAC address.

The first container ct1 may transfer 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 beer yard m2, the first container bridge CT.Br.1 may directly transfer the first packet pk1 to the second container ct2 (S1020).

FIG. 21 illustrates packet flow from a first container ct1 belonging to the same host and a heterogeneous domain to a third container ct3. Since the first and third containers ct1 and ct3 belong to different domains, the first container ct1 converts the MAC address of the destination into a gateway address, that is, the MAC address of the actual network interface of the first host h1 (m. A second packet pk2 of h1) can be generated. The first container ct1 may transfer 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 to the vLAN field (S1115). The first container bridge CT.Br.1 is a second packet (pk2 [100]) having a vLAN of 100 to the first virtual switch vSW1 through the bridge-switch NI associated with the gateway, ie, m.h1. It may be delivered (S1120).

The first virtual switch vSW1 may 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 a 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 may generate 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 converts the destination and source MAC address from (m.h1 / m1) to (m2 / m. h1) (S1135). Step S1135 may be performed at the first virtual switch vSW1.

The second packet pk2 [200] having the MAC address and vLAN converted from the controller 10 to the first virtual switch vSW1 (S1140) and the first container bridge CT.Br at the first virtual switch vSW1. .1) and 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 transfer it to the second container ct2.

FIG. 22 illustrates a packet flow from a heterogeneous host and a first container ct1 belonging to the same domain to a fourth container ct4. Since the first and fourth containers ct1 and ct4 belong to the same domain, the first container ct1 receives the third packet pk3 whose MAC address of the destination is the MAC address m4 of the fourth container ct4. Can be generated. The first container ct1 may transfer 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 the MAC address m4 is bridged through the MAC address learning or information received from the controller 10. If the switch NI is specified, the outgoing port of the packet becomes the bridge-switch NI. Accordingly, the first container bridge CT.Br.1 transmits the third packet pk3 through the bridge-switch NI to the first virtual switch vSW1 with the third packet pk3 [100]. Can be delivered (S1215).

The first virtual switch vSW1 may 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 a 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 delivered to the external network 5, it is preferable to designate another vLAN even in the same domain. However, the third packet pk3 may maintain the original vLAN.

Since the third packet pk3 is to be delivered to the external network 5, the controller 10 determines whether there is legacy protocol conversion information of the third packet pk3, and if not, the controller 10 transmits the legacy packet to the legacy routing agent 300. 3 packets (pk3 [10]) can be delivered (S1230).

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

The converted third packet pk3 [10] may be delivered to the controller 10 and the first virtual switch vSW1 (S1240 and S1245), and may be delivered from the first virtual switch vSW1 to the legacy router R0. There is (S1250). The legacy router R0 connects the destination and source MAC address of the third packet pk3 with the MAC address m.h2 of the actual network interface of the second host h2 and the second host of the legacy router R0. Can be converted into the MAC address (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 is 100) associated with vLAN 10, which is the domain tag of the third packet pk3, and converts the destination / source MAC address from (m.h2 / m.R2) to ( m2 / m1) (S1265).

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

FIG. 23 illustrates a packet flow from a first container ct1 belonging to a heterogeneous host and a heterogeneous domain to a fifth container ct5. Since the first and fifth containers ct1 and ct5 belong to different domains, the first container ct1 converts the MAC address of the destination into a gateway address, that is, the MAC address of the actual network interface of the first host h1 (m. A fourth packet pk4 referred to as h1) can be generated. The first container ct1 may transfer 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 is a fourth packet (pk4 [100]) having a vLAN of 100 to the first virtual switch vSW1 through the bridge-switch NI associated with the gateway, ie, m.h1. Can be delivered (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 a fourth packet pk4 [100] to the controller 10 in order to request 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 delivered to the external network 5, it is preferable to designate another vLAN even in the same domain. It is also desirable to use domain tags to distinguish them from packets that are homogeneous hosts and homogeneous domains. For example, if the source container of the packet to the fifth container ct5 is in the same domain as the fifth container ct5, the vLAN value of the fourth packet pk4 is set to 20, and in the heterogeneous domain, the fourth packet pk4 is used. ) 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.

Since the third packet pk3 is to be delivered to the external network 5, 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] into the MAC address (m.R1) of the network interface of the legacy router R9 connected with the first host h1, and the source The MAC address may be converted into a MAC address (m.h1) of the actual network interface of the first host (S1335). This step may be performed in the controller 10 or the first virtual switch vSW1.

The converted fourth packet pk4 [21] may be delivered to the controller 10 and the first virtual switch vSW1 (S1340 and S1345), and may be delivered from the first virtual switch vSW1 to the legacy router R0. There is (S1350). The legacy router R0 may connect the destination and source MAC addresses of the fourth packet pk4 with the MAC address m.h2 of the actual network interface of the second host h2 and the second host of the legacy router R0. The MAC address of the interface (m.R2) can be converted (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 is 200) associated with vLAN 21, which is the domain tag of the fourth packet pk4, and converts the destination / source MAC address from (m.h2 / m.R2) to ( 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 through the second container bridge CT.Br.2 (S1370). S1375).

The present invention may be implemented in hardware or software. The invention may also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like, which are also implemented in the form of carrier waves (for example, transmission over the Internet). Include. The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. And functional programs, codes and code segments for implementing the present invention can be easily inferred by programmers in the art to which the present invention belongs.

Embodiments of the present invention may include a carrier wave having electronically readable control signals that may be operated with a programmable computer system on which one of the methods described herein is executed. Embodiments of the present invention may be implemented as a computer program product having a program code, the program code being operated to execute one of the methods when the computer program is run on a computer. The program code may for example be stored on a machine readable carrier. One embodiment of the invention may be a computer program having program code for executing one of the methods described herein when the computer program is run on a computer. The invention may include a computer, or a programmable logic device, for performing one of the methods described above. Programmable logic devices (eg, field programmable gate arrays, complementary metal oxide semiconductor based logic circuits) may be used to perform some or all of the functions described above.

In addition, although the preferred embodiment of the present invention has been shown and described above, the present invention is not limited to the specific embodiments described above, but the technical field to which the invention belongs without departing from the spirit of the invention claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or the prospect of the present invention.

<Description of the code>

10: controller 20: SDN switch

30: network device 100: control unit

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 unit

220: flow search module 230: flow processing module

235: packet processing module 240: table management module

300: Legacy Container Agent

800: host

Claims (22)

1. A physical network interface connected to the legacy network;

   A software defined network (SDN) -based virtual switch that exchanges packets with a legacy network through the real network interface;

   A host controller generating the virtual switch;

   A container bridge generated by the host controller and virtually network coupled with the virtual switch through a bridge-switch network interface (NI), the container bridge having a bridge identifier identifying itself;

   A database for storing network subnet information and gateway information using the actual network interface as a gateway based on the bridge identifier as bridge net information; And

   And a first host generated by the host controller, assigned with a unique IP address based on the bridge net information, and having a plurality of containers virtually network coupled to the container bridge.
2. The method of claim 1,

   The plurality of containers each have a container identifier,

   And the database stores a container identifier, an IP address, and an identical domain identifier of each of the plurality of containers as a container net information list.
3. The method of claim 2,

   The container bridge has a plurality of bridge-container NIs coupled with the plurality of containers,

   The container bridge assigns each domain tag corresponding to the same domain identifier to the plurality of bridge-containers IN based on the same domain identifier associated with the container identifier of the container net information list,

   The container bridge tags the designated domain tag in a first packet flowing from a first container of the plurality of containers to a first NI of the plurality of bridge-container NIs,

   Any one of the plurality of bridge-container NIs may leak the temporary storage packet only if a domain tag identical to a domain tag tagged to a packet temporarily stored in the container bridge is assigned.

   The bridge-switch NI is capable of outgoing and outgoing packets regardless of domain tags of outgoing and outgoing packets.
4. The method of claim 3, wherein

   A second NI of the plurality of bridge-containers has the same domain tag as the first NI,

   And the container bridge exits the first packet to the second NI if the destination of the first packet is associated with the second NI.
5. The method of claim 3, wherein

   The container bridge bridges the first packet to the bridge if the MAC address of the first packet is not in the MAC address list associated with the plurality of bridge-container NI or if the bridge-switch NI is associated with a destination of the first packet. -Leak to switch NI,

   Further comprising a controller for controlling the virtual switch,

   And when the virtual switch has no flow processing information of the packet flowing into the virtual switch, query the flow processing to the controller to obtain the flow processing information of the packet from the controller.
6. The method of claim 5,

   A third NI of the plurality of bridge-container NIs is different from the first NI and the designated domain tag,

   The controller, when the destination of the first packet is associated with the third NI, converts the domain tag of the first packet into a third domain tag assigned to the third NI or instructs the virtual switch to convert,

   The virtual switch forwards the packet tagged with the third domain tag to the container bridge.
7. The method of claim 5,

   Generate at least the legacy routing information among the legacy routing information of the packet and the legacy protocol conversion information for the packet to conform to the legacy routing protocol, and make the virtual switch included in the first host appear as a legacy router in the legacy network; A legacy routing agent configured to set a virtual switch of one host to send and receive packets with the legacy network,

   And a second second host connected to the first host and the legacy network and capable of creating a container.

   The controller forwards the first packet to the legacy routing agent if the destination of the first packet is associated with a container of the second host or if there are no destination MAC addresses in the plurality of bridge-container NIs.
8. The method of claim 7, wherein

   The first packet translates, by the legacy routing agent, a source MAC address into a MAC address associated with a real network interface of the first host when the destination of the first packet is a second container created on the second host. And a fourth domain tag associated with the same domain identifier associated with the domain to which the second container belongs by the controller is tagged and delivered by the virtual switch of the first host to the legacy network.
9. The method of claim 8,

   And the fourth domain tag has at least two values, wherein the at least two values are associated with whether the first container and the second container belong to the same domain.
10. The method of claim 8,

    The virtual switch of the first host receives a second packet from the legacy network,

    If the second packet is a packet of a legacy protocol that cannot be processed by the virtual switch of the first host, the second packet is converted into a packet of an openflow protocol by the legacy routing agent,

    If the domain tag of the second packet is associated with a domain tag of the first NI, the domain tag of the second packet is converted by the controller to a domain tag of the first NI.
11. The method of claim 7, wherein

    Further comprising a switch group based on the SDN to build an independent network that is distinct from the legacy network,

    The switch group includes at least one edge switch that is a virtual switch of the first host,

    The controller acquires information of the at least one edge switch,

    And the legacy routing agent creates at least one virtual router that allows the legacy network to treat at least a portion of the group of switches as a legacy router based on the information of at least one edge switch acquired by the controller.
12. The method of claim 11,

    The at least one virtual router has a port for the virtual router,

    The information of the port for the virtual router corresponds to the actual network interface information or is associated with a domain tag of a packet that flows in and out of the port for the virtual router.
13. The method of claim 11,

    The legacy routing agent is configured such that a network node connected to the switch bridge including the container bridge of the first host and the plurality of containers is treated as an external network connected to the at least one legacy router in the legacy network. To set up, the system.
14. A physical network interface connected to the legacy network;

    A software defined network (SDN) based virtual switch controlled by an external controller to exchange packets with a legacy network through the actual network interface;

    A host controller generating the virtual switch;

    A container bridge generated by the host controller and virtually network coupled with the virtual switch through a bridge-switch network interface (NI), the container bridge having a bridge identifier identifying itself;

    A database for storing network subnet information and gateway information using the actual network interface as a gateway based on the bridge identifier as bridge net information; And

    And a plurality of containers generated by the host controller, assigned with a unique IP address based on the bridge net information, and virtually network coupled to the container bridge.
15. Creating a software-defined network (SDN) -based virtual switch in a host that creates a container and is connected to the legacy network through an actual network interface;

    Networking the virtual switch with the real network interface;

    When the host receives a container container bridge creation request including a bridge identifier for distinguishing a network environment, gateway information using the virtual switch as a gateway, and network subnet information, generating a container bridge;

    Network coupling the container bridge and the virtual switch such that packets having all the same domain identifiers pass between the container bridge and the virtual switch;

    When the host receives a container creation request including a first container identifier having a bridge identifier as a key and a first same domain identifier, generating a first container having the first container identifier;

    Assigning an IP address to the first container based on network subnet information associated with the bridge identifier; And

    A bridge-container of the container bridge coupled to the container such that the container bridge and the first container are network coupled and only packets with a first domain tag associated with the first same domain identifier are delivered to the first container. Assigning the first domain tag to a network interface (NI).
16. The method of claim 15,

    Receiving, at the container bridge, a first packet from a first host that is a destination of a second container belonging to the same domain of the same host; And

    Leaking the first packet to a bridge-container NI associated with the MAC address of the first packet.
17. The method of claim 15,

    Tagging, at the container bridge, the first domain tag to a packet flowing from the first container to the container bridge;

    If the destination packet of the incoming packet does not have a destination MAC address of the incoming packet in a bridge-container NI other than the first bridge-container NI associated with the virtual switch or connected to the first container, the incoming packet is sent to the virtual switch. Delivering to;

    If there is no flow processing information on the received packet in the virtual switch, inquiring a flow processing of the packet to a controller that controls the virtual switch to obtain flow processing information; And

    Obtaining, at the controller, legacy routing information for a packet to be delivered to the legacy network to a legacy routing agent that generates legacy routing information for the packet if the packet should be delivered to the legacy network.
18. The method of claim 17,

    Receiving, at the container bridge, a second packet from the first container, the second packet being a destination of a third container belonging to another domain of the same host;

    Leaking the second packet to a bridge-switch NI associated with a gateway MAC address of the second packet;

    Receiving a packet converted from the first domain tag to a domain tag associated with a bridge-container NI coupled to the third container.
19. The method of claim 17,

    The fourth packet is a host different from the host to which the first container belongs,

    Receiving, at the container bridge, the fourth packet from the first container and forwarding the fourth packet to a virtual switch;

    Converts the MAC address of the source of the fourth packet to a MAC address of the real network interface of the host or a virtual MAC address associated with the same domain identifier, converts the MAC address of the destination to the MAC address of the next hop belonging to the legacy network; Converting a domain tag into a tag associated with a domain tag of a destination of the fourth packet; And

    In the virtual switch, forwarding the converted fourth packet to the legacy network.
20. The method of claim 19,

    And at least two tags associated with a domain tag of the fourth packet destination, wherein the at least two associated tags depend on whether the domain of the destination of the first container and the fourth packet is the same.
21. The method of claim 19,

    Receiving, at the virtual switch, a fifth packet through the legacy network from a fourth container belonging to another host;

    If the fifth packet is a packet of a legacy protocol that cannot be processed by the virtual switch or the controller, converting the fifth packet into an openflow protocol by the legacy routing agent; And

    When the fifth domain tag of the fifth packet is associated with the first domain tag, converts the domain tag of the fifth packet into the first domain tag, and converts a destination MAC address into a MAC address of the first container. The method further comprises a step.
22. The method of claim 21,

    In the virtual switch, converting the source MAC address of the fifth packet into the MAC address of the fourth container when the fifth domain tag indicates that the first and fourth containers belong to the same domain. Including, method.

Images