KR20180080787A - Method for controlling of pc power by aggregated routing based on sdn - Google Patents

Abstract

The present invention relates to a method of controlling a PC power supply by an integrated routing based on a software defined network (SDN) and a system thereof. The present invention enables unified routing to enable packet flow between an existing legacy network and an SDN network, enabling flexible network operation using a plurality of virtual routers. The present invention also relates to a method for supporting multi-tenancy through a plurality of routers and controlling the power of PCs belonging to a specific tenant according to a scheduling policy in a network supporting multi-tenants.

Description

[0001] METHOD FOR CONTROLLING OF PC POWER BY AGGREGATED ROUTING BASED ON SDN [0002]

The present invention relates to a method and system for controlling PC power by integrated routing based on SDN (Software Defined Network), and it is possible to perform integrated routing that enables packet flow between existing legacy network and SDN network, The present invention relates to a method of controlling a power of a PC belonging to a specific tenant according to a scheduling policy in a network supporting a multi-tenancy through a plurality of routers.

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

Open flows separate high-speed packet delivery and high-level routing decision functions. The packet forwarding plane is still involved in the switch stage, while the high level routing decisions are involved in a separate controller, which communicates through the open flow protocol.

However, as a transition from an existing network to an SDN, there is a need for a software defined network that interacts with existing protocols and devices. Such a hybrid SDN network requires less computing resources and networking resources, and requires simple structure and operation.

In the case of existing virtual routers, the control plane and the data plane coexist, and the existing routers are often moved to the virtual machine form. It is dependent on virtualization technology and has a lower performance than existing hardware routers. In the case of existing routers, individual routers must be managed separately, and they are not actively responding to changes in network requirements.

In an existing cloud environment, network management through DHCP handling takes place in the cloud control node. When the cloud environment is operated on the SDN network, it is difficult to manage the cloud environment by distributing the information of the SDN controller managing the existing SDN network and the DHCP information managing the cloud internal network.

Also, noh hard service has become widespread for the unified management of existing large scale PCs. It is a service for easy management of a large number of PCs in common use such as a PC room, a campus PC room, and an in-house PC room. The NoHard service automatically resets the PC according to the initial settings, which can not be performed dynamically in general. In addition, there is a difficulty for the agency to work on the update. In addition, it was difficult to provide a computer running environment in different states depending on the class time, such as a campus or a PC room in a school.

1. Registration Patent Publication No. 10-1493936 (Feb. 2. Registration patent publication No. 10-1438212 (2014.09.04) 3. Published Japanese Patent Application No. 10-2014-0102398 (Aug. 21, 2014)

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] 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] 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]

An object of the present invention is to provide boot image scheduling by remote management of PC power management and dynamic management of network and to manage power of PC using SDN protocol so as to achieve IP dynamic allocation of DHCP server to provide multi- .

A method of providing an IP address of a multi-tenant supporting network system based on SDN (Software Defined Network) according to the present invention includes: a controller for controlling a plurality of SDN-based switches; A virtual router for treating a switch group including at least some switches among the plurality of switches as a virtual router and generating routing information for a packet to be input to one of the switches; A virtual routing application that, when receiving a virtual router creation request message, allocates computing resources to create the virtual router using virtualization technology; And a PC power control application for controlling a power of a PC connected to an edge switch among the plurality of switches, wherein the virtual routing application includes a slicing identifier which is specific information based on a packet that is input to the plurality of switches The method comprising: generating a plurality of virtual routers based on a plurality of switches, wherein the slicing identifier is an IP address providing method by the system corresponding to a tenant among a plurality of tenants connected to the plurality of switches, Transmitting a remote power switching signal over the network; Switching the power of the PC to an on state when receiving the remote power switching signal when the PC is in an off state; Receiving a Dynamic Host Configuration Protocol (DHCP) request packet transmitted by the virtual router from the PC; Transmitting, by the virtual DHCP server, a DHCP response packet having the IP address and the boot image identifier to the PC corresponding to the DHCP request packet; And transmitting the boot image request packet to the edge switch based on the boot image identifier of the DHCP response packet received by the PC.

In addition, the plurality of virtual routers may form an isolated network from each other.

In addition, the virtual routing application may assign network information to the virtual router having a namespace identifier associated with the slicing identifier of the packet.

The virtual routing application may further include extracting a slicing identifier in the received DHCP request packet and delivering the DHCP request packet to a virtual router having a namespace identifier corresponding to the extracted slicing identifier have.

The PC power control application may further include modifying a boot image identifier of the DHCP server of the virtual router according to a predetermined scheduling policy.

Transmitting the boot image request packet to a load control application that controls load of a plurality of image servers storing a boot image; And transmitting the boot image request packet to a specific image server based on a predetermined load balancing policy of the image server group having the boot image identifier included in the boot image request packet among the plurality of image servers As shown in FIG.

A PC power control method according to the present invention includes: a controller for controlling a plurality of SDN (Software Defined Network) based switches; A virtual router providing a virtual routing function; And a virtual routing application for generating the virtual router, the method comprising: receiving a routing request message in the virtual routing application; In the virtual routing application, allocating computing resources to create the virtual router; Designating, in the virtual application, network information having a namespace identifier in the virtual router; And in the virtual router, preparing a virtual routing function using the network information, wherein the namespace identifier corresponds to a tenant of a plurality of tenants connected to the plurality of switches, The routing application creates a plurality of virtual routers, wherein the namespace identifier corresponds to a slicing identifier which is specific information based on a packet to be transmitted to the plurality of switches, and wherein, in a controller of the controller, Forwarding the incoming packet to the virtual routing application if there is no processing information of the received packet; Extracting a slicing identifier from the incoming packet in the virtual routing application; Transferring the incoming packet to a virtual router having a namespace identifier corresponding to the extracted slicing identifier among the plurality of virtual routers in the virtual routing application; Generating an IP address by using a virtual DHCP server function when the incoming packet is a dynamic host configuration protocol (DHCP) in the virtual router; And generating a response packet including the IP address and the pre-stored boot image identifier.

According to the present invention, it is possible to easily realize the dynamic PC power scheduling policy, to centrally control the power of the PC remotely, to automate the scheduling policy, and to simplify management. In addition, administrator-defined services can be enabled, and the PC environment can be changed dynamically according to the course.

1 is a block diagram of a controller of the network system of FIG. 1, FIG. 3 is a block diagram of a switch of the network system of FIG. 1, FIG. FIG. 5 is a field table of a group and a meter table; FIG. 5 is an operation table showing an operation type according to a field table and a flow entry;
FIG. 6 is a block diagram of a network system including an integrated routing system according to an embodiment of the present invention; FIG. 7 is a block diagram of a virtualized system of the network system of FIG. 6; and FIG. FIG. 10 is a signal flow diagram according to an integrated routing method according to an embodiment of the present invention. FIG. 11 is a block diagram of the SDN controller. FIG. 11 is a flowchart of a method of determining whether or not legacy routing is performed for the flow of the controller control unit of FIG. FIG. 12 is a flow chart according to an embodiment of the present invention. FIG. 12 is a flow chart according to an integrated routing method according to another embodiment of the present invention, and FIG.
FIG. 13 is a structural view of a multi-tenant supporting network system according to an embodiment of the present invention, FIG. 14 is a block diagram of components of the network system of FIG. 13, and FIG. 17 is a flowchart showing a method of preparing a routing function in Fig. 16, Fig. 18 is a structure diagram showing various interfaces of a virtual router, Fig. 19 is a diagram showing a configuration of a virtual router, FIG. 20 is a structure diagram of a virtual router according to another embodiment of the present invention, FIG. 20 is a structure diagram of a virtual router according to FIG. 19, FIG. 21 is a flow chart of a method of determining whether or not legacy routing is performed for a flow of a controller in FIG. FIG. 23 is a flow chart of an example, not the routing process of FIG. 22. FIG.
FIG. 24 is a network configuration diagram of a PC power control system according to an embodiment of the present invention, FIG. 25 is a PC control signal flow chart of the system of FIG. 24, and FIG. 26 is a PC power scheduling control How to do it.

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

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

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

In addition, suffixes "module" and " part "for the components used in the following description are given merely for convenience of description, and do not give special significance or role in themselves. Accordingly, the terms "module" and "part" may be used interchangeably. Components by "module", "part", and "app" may be embodied in a computer logic device or a computer-readable medium, such as a program, a data structure such as a table, and / or various data.

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

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

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

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

The basic SDN is the concept of separating the control plane from the transmission plane. That is, the control and forwarding functions coexisting in the existing network equipment are separated, and the data forwarding function which is processed by the hardware in the switch / router is controlled by the controller (controller) which is a software part. Since the functions that are individually performed in the legacy network are collected by the central controller, the network global view is obtained and network congestion can be prevented in advance. That is, the centralized controller can manage traffic from a battery point of view. Hereinafter, an existing network and an existing switch / router will be referred to as a legacy network and a legacy switch / router.

1 is a block diagram of a controller of the network system of FIG. 1, FIG. 3 is a block diagram of a switch of the network system of FIG. 1, FIG. FIG. 5 is a field table of a group and a meter table; FIG. 5 is an operation table showing an operation type according to a field table and a flow entry;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The network shown in Fig. 6 includes an SDN-based network including the controller 10 for controlling the flow of the open flow switch among the switch groups constituted by the plurality of switches SW1 to SW5 and the first to third legacy routers R1- R3 are mixed with each other.

In this specification, the SDN-based network means only an open-flow switch, or an independent network composed of an open-flow switch and an existing switch. When the SDN-based network is composed of an open-flow switch and an existing switch, it is preferable that the open-flow switch is arranged at an edge of a network domain of the switch group. The present invention may be embodied without requiring a legacy router or a conventional switch. The present invention may be embodied in other forms without departing from the spirit or essential characteristics thereof.

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

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

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

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

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

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

The routing app interface module 150 may communicate with the virtual routing app 300. The routing application interface module 150 can transmit the topology information of the switch group established by the topology management module 120 to the virtual routing application 300. The topology information may include connection information of the first to fifth switches SW1 to SW5 and connection or connection information of a plurality of network devices connected to the first to fifth switches SW1 to SW5.

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

8, the virtual routing application 300 includes an SDN interface module 310, a virtual router creation unit 320, a virtual router 340, a packet processing unit 330, and a routing information storage unit 390 can do.

The SDN interface module 310 may communicate with the controller 10. Each of the routing application interface module 150 and the SDN interface module 310 may serve as an interface between the controller 10 and the virtual routing application 300. The routing app interface module 150 and the SDN interface module 310 may communicate in a specific protocol or in a specific language. The routing application interface module 150 and the SDN interface module 310 can translate or interpret messages exchanged between the controller 10 and the virtual routing application 300. [

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

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

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

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

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

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

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

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

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

The packet processor 330 may generate the routing information storage unit 390 when the virtual router 340 is created. The routing information storage unit 390 may include routing information used for referring to routing in a legacy router. The routing information may include a routing table. The routing table may consist of some or all of the RIB, FIB, and ARP tables. The routing table may be modified or updated by the packet processing unit 330.

The packet processing unit 330 may generate a legacy routing path for the flow inquired by the controller 10. [ The packet processing unit 330 uses a part or all of the received packet received from the open flow switch included in the flow, the port information into which the received packet is input, the virtual router 340 information, and the routing information storage unit 390 Can generate legacy routing information.

The packet processing unit 330 may include a third party routing protocol stack to determine legacy routing.

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

The legacy routing determination method for the flow refers to whether the SDN control unit 100 performs general SDN control or flow inquiry to the virtual routing application 300 for the flow received from the open flow switch.

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

If the flow-in port is an edge port, the SDN control unit 100 determines whether packets of the flow can be interpreted (S512). If the packet can not be interpreted, the SDN control unit 100 can forward the flow to the virtual routing application 300 (S516). In the case of a protocol message used only in a legacy network, a general SDN-based controller can not interpret a packet.

If the received packet is a legacy packet such as that transmitted from the first legacy network to the second legacy network, the SDN control unit 100 can not calculate the routing path of the incoming legacy packet. Therefore, if the SDN control unit 100 can not calculate the path like the legacy packet, the SDN control unit 100 preferably sends the legacy packet to the virtual routing application 300. However, knowing the final processing method of the edge port and the legacy packet to which the legacy packet will flow, the SDN control unit 100 can process the legacy packet through the flow modification. If the packet can be analyzed, the SDN control unit 100 searches for a flow path such as whether the path of the flow can be calculated or whether there is an entry in the entry table (S514). If the path can not be retrieved, the SDN control unit 100 can forward the flow to the virtual routing application 300 (S516). If the path can be searched, the SDN control unit 100 can generate a packet-out message designating the output of the packet and transmit it to the open flow switch inquiring the packet (S518). A detailed example of this will be described later in Fig. 10 and Fig.

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

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

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

Referring to FIG. 10, 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 (S521).

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 SDN control unit 100 informing of the unkown packet (S522). The packet-in message preferably comprises a flow comprising a Hello1 packet and an incoming port (port 11) information.

The message management module 130 of the SDN control unit 100 can determine whether the processing rule for the flow can be generated (S523). See FIG. 9 for details of the determination method. In this example, since the OSPF protocol message is a packet that the SDN control unit 100 can not interpret, the SDN control unit 100 can forward the flow to the virtual routing application 300 (S524).

The SDN interface module 310 of the virtual routing application 300 transmits the Hello1 packet received from the SDN control unit 100 to the virtual router 340 corresponding to the port 11 of the first edge switch SW1 provided in the flow ) Port (port 11v). When the virtual router 340 receives the Hello1 packet, the packet processing unit 330 can generate the legacy routing information of the Hello1 packet based on the routing information storage unit 390 (S525). In this embodiment, the packet processing unit 330 generates a Hello2 message corresponding to the Hello1 message and specifies a routing path for designating the output port as the 11v port (port 11v) so that the Hello2 packet is transmitted to the first legacy router R1 Can be generated. The Hello2 message has a destination which is the first legacy router R1 and a pre-designated virtual router identifier. The legacy routing information may include a Hello2 packet, and an output port that is an eleventh port. The packet processor 330 may generate the legacy routing information by using the information of the virtual router 340. In this case,

The SDN interface module 310 may forward the generated legacy routing information to the routing app interface module 150 of the SDN control unit 100 (S526). Either the SDN interface module 310 or the routing application interface module 150 may convert the 11v port (port 11v), which is the output port, to the 11th port (port 11) of the first edge switch SW1. Or the 11th port and the 11th port are the same, and port conversion can be omitted.

The path calculation module 125 of the SDN control unit 100 outputs the Hello2 packet to the 11th port (port 11) of the first legacy router R1 using the legacy routing information received through the routing app interface module 150 (S527).

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

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 virtual routing application 300 can actively generate an OSPF hello message to be output to the edge port of the edge switch and send it to the SDN control unit 100. In this case, the SDN control unit 100 may transmit the hello packet to the open flow switch using a packet-out message. It is also possible to implement this embodiment by setting a packet-out message that does not correspond to a packet-in message such that the open-flow switch follows the packet-out message.

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

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

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

The message management module 130 of the SDN control unit 100 may determine whether SDN control for the flow is possible (S533). In this example, the packet P1 is interpretable but is directed to the legacy network, so that the SDN control unit 100 can not generate the path of the packet P1. The SDN control unit 100 can transmit the packet P1 and the eleventh port, which is an incoming port, to the virtual routing application 300 through the routing app interface module 150 (S534).

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

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

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

The SDN interface module 310 may forward the generated legacy routing information to the routing app interface module 150 of the SDN control unit 100 (S536). In this step, the output port can be converted to the edge port to be mapped.

The SDN control unit 100 can generate the flow processing rule in the open flow switch group using the legacy routing information received through the routing app interface module 150, in particular, the legacy route of the legacy routing information.

The path calculation module 125 of the SDN control unit 100 may calculate a path to be output from the first edge switch SW1 to the 32nd port of the third edge switch SW3 using the legacy path at step S537.

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

The flow entry according to the flow processing rule is preferably based on an identifier that identifies the data-packet corresponding to the flow managing the path of the packet P1. That is, the flow process for the packet P1 is preferably based on an identifier that can identify the legacy flow. To this end, a packet P1 to which a legacy identifier (tunnel ID) is added is included in a packet-out message transmitted to the first edge switch SW1, and a flow entry for attaching a legacy identifier (tunnel ID) .

An example of a flow table of each switch is shown in Fig. 12 (a) is a flow table of the first edge switch SW1. For example, Table 0 in FIG. 12 (a) adds tunnel 2 as a legacy identifier to the flow towards the second legacy router R2 and causes the flow to move to Table 1. The legacy identifier may be entered in a meta field or other field. Table 1 has a flow entry in which the flow having the tunnel 2 is output to the 14th port (port information of the first switch SW1 connected to the fourth switch SW4). 12 (b) is an example of a flow table of the fourth switch SW4. In the table of FIG. 12 (b), the flow whose legacy identifier is tunnel2 among the flow information is output to the 43rd port (port 43) connected to the third switch SW3. 12 (c) is an example of a flow table of the third switch SW3. Table 0 in FIG. 12 (c) removes the legacy identifier of the flow whose legacy identifier is tunnel2 and causes the flow to move to Table 1. Table 1 outputs the flow to port 32. By using multiple tables in this way, the number of cases can be reduced. This makes it possible to perform a quick search and reduce resource consumption of memory and the like.

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

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

FIG. 13 is a structural view of a multi-tenant supporting network system according to an embodiment of the present invention, and FIG. 14 is a block diagram of components of the network system of FIG. Reference is made to Figs. 1 to 12 for a detailed description of the same or similar components.

Referring to Fig. 13, the network system may include a plurality of switches SW1 to SW5, and a controller 10.

At least some of the plurality of switches SW1 to SW5 may be physical switches or virtual switches that support an open flow protocol with SDN (Software Defined Network) based switches. The plurality of switches SW1 to SW5 may be configured as a combination of an open flow switch and a conventional legacy switch, in which case the edge switch is preferably an open flow switch.

The plurality of switches SW1 to SW5 may be connected to each other. The edge switch among the plurality of switches SW1 to SW5 may be connected to the network devices through the ports p21 to p42 or may be connected to an external network (a legacy router, a gateway, etc.) .

The controller 10 can control a plurality of SDN (Software Defined Network) based switches.

14, the controller 10 may include a controller control unit 100, a virtual routing application 300, and a plurality of virtual routers 340. [

The controller control unit 100 of the controller 10 includes a topology management module 120, a path calculation module 125, an entry management module 135, a message management module 130, and a routing application interface module 150 . Each module may be configured in hardware in the control unit 100 and may be configured in software separate from the control unit 100. [ Reference will be made to Figs. 2 and / or 8 for a description of the components of the same reference numerals.

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

The routing app interface module 150 may communicate with the virtual routing app 300. The routing application interface module 150 may transmit the topology information of the switch group constructed by the topology management module 120 to the legacy routing container 300. [ The topology information includes connection relationship information of the first to fifth switches SW1 to SW5 and network devices and network devices (legacy switch, legacy router, etc.) connected to the first to fifth switches SW1 to SW5 Or connection or connection information of each other.

The routing application interface module 150 may be configured to determine whether an incoming packet received through one of the plurality of switches SW1 to SW5 can not be interpreted, can not be routed, To the virtual routing application 300.

An unexplainable or non-pathable example of a packet is such that the incoming packet can not be constructed or interpreted as a legacy protocol, or the path computation module 125 can not specify a path to a received packet in connection with a legacy network.

In the case where it is necessary to transmit the incoming packet to the application 300 in the policy, when the network connected to the plurality of switches SW1 to SW5 needs to be configured as a multi-tenant, or to configure a plurality of virtual routers If you need to. This can be triggered by a virtual router creation request message generated by an administrator or user's control or request. The virtual routing application 300 can receive the virtual router creation request message through the open flow switch or the orchestrator 1. The multi-tenant and the plurality of virtual routers will be described later.

If the routing application interface module 150 can not generate the processing rule of the flow included in the flow inquiry message received from the open flow switch, the routing application interface module 150 may transmit the flow to the virtual routing application 300. The flow preferably includes the port information of the switch that received the packet and the packet received from the open flow switch.

The routing application interface module 150 can convert the routing path information generated by the virtual router 340, which will be described later, into an OpenFlow protocol.

Referring to FIG. 14, the virtual routing application 300 may include a packet processing unit 330, a topology module 380, an SDN interface module 310, and a virtual router creation unit 320. The virtual routing application 300 may be run on a separate device or may be run on the controller 10.

The SDN interface module 310 can communicate with the controller control unit 100. Each of the legacy interface module 140 of the controller control unit 100 and the SDN interface module 310 of the virtual routing application 300 may serve as an interface between the controller control unit 100 and the legacy routing container 300. Legacy interface module 140 and SDN interface module 310 may communicate in a particular protocol or in a particular language.

Both or both of the legacy interface module 140 and the SDN interface module 310 may translate or interpret messages exchanged between the controller 10 and the legacy routing container 300. For example, legacy protocol messages can be converted into open flow protocol messages.

The topology module 380 may store network information such as topology information related to the plurality of switches SW1 to SW5 received from the controller control unit 100. [ The topology module 380 may create a network topology for multiple virtual routers or multi-tenants to be created on a policy basis. The information for generation of multi-tenants, such as a plurality of virtual routers of the topology module 380 or a network topology for multi-tenants (hereinafter referred to as 'multi-tenants') is not only generated by policy, Lt; / RTI >

A plurality of virtual routers allow the capacity of the network to be resiliently adjusted. If you need to provide a cloud environment like a data center, network capacity can be easily adjusted. When a cloud environment needs to be provided to various users, a plurality of virtual routers can support a virtual router according to a user, and can facilitate a charging policy according to a usage amount of a user. When the network environments controlled by each of the plurality of virtual routers are independent of each other, the resources of each tenant can support multi-tenancy so that independence is ensured so that they are not shared with other tenants.

In addition to the network topology, the information for generation of multi-tenants (hereinafter, 'generation information') includes information such as the number and type of network devices to be connected to the virtual router, network information, group policies of users, Resource allocation policy, loopback IP address or port information (link address, MAC address, etc.) of the virtual router. The allocation policy of the network or computing resource may be determined by a designation of an administrator or a request of a user, in addition to the basic policy. Some of the generated information may be included in the virtual router creation message mentioned above.

The virtual router generating unit 320 may generate and / or manage the virtual router 340 having the routing function based on the generation information of the topology module 380. [ Upon receiving the virtual router creation message from the controller control unit 100, the virtual router creation unit 320 prepares to create the virtual router 340.

First, the virtual router generating unit 320 may allocate computing resources to the virtual router 340 to be generated based on the network of the generated information or the computing resource allocation policy, and may generate the virtual router 340. [ Various virtualization techniques can be used for generating the virtual router 340.

The virtual router creation unit 320 can forward or specify the network information required for the virtual router 340 to the virtual router 340 through the packet processing unit 330. [ The required network information can be extracted from the generated information.

The virtual router creation unit 320 can designate a namespace identifier that can be distinguished from or identifiable to other virtual routers in the virtual router 340. [

The virtual router creation unit 320 can create a plurality of virtual routers 341, 342, and 343. The virtual router generating unit 320 can generate a plurality of virtual routers based on the slicing identifiers that are specific information based on the packets that are input to the plurality of switches SW1 to SW5.

Specific information based on the incoming packet includes incoming port information of the open flow edge switch to which the incoming packet is input, and tag information such as vLAN or vxLAN of the incoming packet. That is, the slicing identifier may include an incoming port of the incoming packet, vLAN, vxLAN information, and the like. The tag information of the incoming packet may be specified in the source device of the packet, or may be specified in the open flow switch or the controller 10. [ When a packet is connected through a mobile communication network, the slicing identifier may include tag information such as a tunnel ID added to the packet.

The slicing identifier may be associated with a namespace identifier. Thereby, the slicing identifier and the namespace identifier can correspond to each other.

The plurality of virtual routers 341, 342, and 343 can form a network isolated from each other. Thus, the network system according to the present invention can support multi-tenants.

When the network devices connected to the plurality of switches SW1 to SW5 constitute a multi-tenant, each tenant may correspond to a slicing identifier or a namespace identifier, respectively.

The namespace identifier can be specified to be the same as the loopback address of the virtual router functioning in the virtual router, or tag information such as vLAN, vxLAN information. The namespace identifier can be any value or the loopback address of the virtual router.

The packet processing unit 330 serves as an interface of the virtual router 340. When the controller control unit 100 transmits the incoming packet to the virtual routing application 300 for controlling the routing of the incoming packet to the open flow switch, the packet processing unit 330 transmits the received incoming packet to the plurality of virtual routers 341 , 342, and 343 to which virtual router. To this end, the packet processor 330 may extract the slicing identifier from the incoming packet and forward the incoming packet to the virtual router having the namespace identifier associated with the slicing identifier among the plurality of virtual routers 341, 342, and 343. The packet processing unit 330 may associate one value of the slicing identifier or a combination of a plurality of values and one namespace identifier as a pair and store the association list.

The packet processing unit 330 may receive the routing information to be described later from the virtual router 340, and may transmit the routing information to the SDN interface module 310.

Referring to FIG. 14, the virtual router 340 may include a namespace unit 350, a routing processing unit 332, and a routing information storage unit 392.

When the virtual router is created by the controller generating unit 350, the namespace unit 350 sets the network environment of the virtual router. The network environment of a virtual router is a network interface or a port interface of a virtual router to function so that a virtual router can function as a virtual router. That is, the namespace unit 350 can establish a network environment that is an interface with the outside.

The namespace unit 350 can use Linux's namespace technology. In this case, the namespace unit 350 can create a virtual router by the instruction of the controller generation unit 350. [

The namespace unit 350 serves as an interface of the virtual routing application 300. The namespace unit 350 can set the network environment of the virtual router using the network information received from the virtual routing application 300. The namespace unit 350 may establish a separate network environment separate from the network with other virtual routers.

The namespace unit 350 may allow the virtual router to function as a virtual router using the network information received from the virtual routing application 300. [ The namespace unit 350 receives the network environment of the virtual router required for the routing function, that is, the information of the network nodes and the topology information of the nodes from the virtual routing application 300 and stores the information in the routing information storage unit 392 have. The network nodes may include information of switches among the plurality of switches SW1 to SW5 to be involved in the virtual routing function, network devices connected to the switches, or an external network.

The routing processor 430 may generate a routing table (RIB, FIB, ARP table) using network topology information or network information stored in the routing information storage 392. [ The routing table can be updated, such as modified or deleted by the routing processing unit 332. [

For this purpose, the routing processor 332 can exchange messages with the outside using a legacy protocol. The generated table may be stored in the routing information storage unit 392.

The routing information storage unit 392 may store the namespace identifier. The namespace unit 350 may determine whether to drop the incoming packet received through the virtual routing application 300 using the namespace identifier.

The routing information storage unit 392 stores the interface of the virtual router provided by the virtual router so that the routing information storage unit 392 stores the switch group including some switches among the plurality of switches SW1- It can be seen as a router.

The interfaces of the virtual routers stored in the routing information storage unit 392 may vary.

15 is a block diagram of a virtual router according to another embodiment of the present invention. Please refer to Figs. 1 to 5.

Referring to FIG. 15, the virtual router may include a namespace unit 350, a routing processing unit 332, a routing information storage unit 392, and a DHCP virtual server 360. Refer to Fig. 14 for a description of the same components.

If the incoming packet received in the namespace unit 350 is a DHCP (Dynamic Host Configuration Protocol) protocol, the DHCP virtual server 360 can generate an IP address to be used in the requested network device. That is, if there is an IP address request in the network device, the DHCP virtual server 360 can send the IP address to the requested network device. The DHCP virtual server 360 may enable the virtual router to enable the DHCP server function.

16 is a flowchart of a virtual router creation method. 1 to 15.

Referring to FIG. 16, when the virtual routing application 300 receives a virtual router creation request message (S561), the virtual routing application 300 can allocate networking resources and / or computing resources for a virtual router to be created (S562).

The virtual routing application 300 can create a virtual router using the allocated resources (S563). After that, the virtual routing application 300 can forward and / or specify the network information such as the network interface and the network topology information required for the namespace identifier and the virtual routing function to the generated virtual router 340 (S564).

As described above, the creation of the virtual router is performed by creating the namespace unit 350 in the virtual router creation unit 320 of the virtual routing application 300, and replacing the remaining overall portion of the virtual router in the namespace unit 350 with .

The namespace unit 350 constructs a virtual router so that the virtual router functions as a virtual router by using the network information received from the virtual routing application 300 and transmits the interface and network topology information of the virtual router to the routing information storage unit 300. [ Lt; RTI ID = 0.0 > 392 < / RTI >

The routing processor 332 can use the information stored in the routing information storage 392 to create a routing table or a forwarding table so that the virtual router can perform the routing function. Thereby, the virtual router 340 is ready to provide the routing function (S565).

FIG. 17 is a flowchart illustrating a routing function preparation method of FIG. 16, and FIG. 18 is a structural diagram illustrating various interfaces of a virtual router. Please refer to Figs. 1 to 16.

Referring to FIG. 17, the namespace unit 350 may generate a routing function so that the generated virtual router functions as a router (S566). To this end, the namespace unit 350 may specify an interface of a virtual router and designate that each interface is connected to an interface of network nodes including a network device.

The namespace unit 350 may designate a switch group to be used for virtual routing among the plurality of switches SW1 to SW5, and may map the interfaces of the switches belonging to the switch group and the interfaces of the virtual router to each other (S567).

Referring to FIG. 18, a virtual router having various interfaces can be seen.

18A, the interface of the virtual router can be constructed such that a part of the ports of the edge switch among the plurality of switches SW1 to SW5 corresponds to the port of the first virtual router (v-R1). In this case, the slicing identifier may be ports p21, p31, p41, and p51. The namespace identifier may be assigned a value corresponding to the combination of ports p21, p31, p41, and p51, for example, v-R3. That is, the namespace identifier may correspond to a list of slicing identifier values.

Referring to FIG. 18 (b), an interface of the virtual router can be established such that the ports of some of the plurality of switches SW1-SW5 correspond to the ports of the second virtual router v-R2.

18 (c) to (f), the interface of the virtual router can be set to correspond to the vLAN or vxLAN value of the packet. If you create a virtual router with only the physical ports (physical ports) of the edge switch, you will be limited by the number of physical ports. However, when associated with packet identification information (vLAN or vxLAN), such constraints are eliminated. It can also be made to work similar to the flow of legacy packets in legacy networks. It can also drive virtual legacy routers per user or user group. The user or user group can be identified by packet identification information such as vLAN, vxLAN, or tunnel ID.

The namespace unit 350 may generate routing information using the network information (S568). The network information may be received from the virtual routing application 300.

FIG. 19 is a network structure diagram according to another embodiment of the present invention, and FIG. 20 is a structural diagram of a virtual router according to FIG. Please refer to Figs. 1 to 18.

Referring to FIG. 19, the network supports multi-tenancy, and network devices (VMs) belong to each of the multi-tenants. It is assumed that the first tenant is connected through ports p21n (p21_1, p21_2, ..., p12_n) and port p22n of the twenty-first and twenty-second switches SW21 and SW22 and the remaining devices are connected through ports p23n and p24n It is assumed that the policy is established to be connected to the twenty-third and twenty-fourth switches SW23 and SW24.

To support two tenants, the first and second virtual routers may be created such that two independent virtual router functions are provided as in FIG.

The slicing identifier is desirably designated by the vLAN value. That is, the first tenant may have a value of vLAN 101 and the second tenant may have a vLAN value of 102. [ The namespace identifier (nsID) may be specified to be equal to the vLAN value, respectively.

The port interface of the virtual router and the port interface of the edge switches may correspond to each other in 1: 1, or may be associated in various combinations.

FIG. 21 is a flowchart illustrating a method of determining whether legacy routing is performed for the flow of the controller of FIG. 13 to 18.

The method of determining the legacy routing for the flow indicates whether the controller 10 should perform general SDN control or flow control to the legacy routing container 300 for the flow received from the open flow switch.

Referring to FIG. 21, when preparation for the virtual routing function is completed in the virtual router 340, the controller 10 may receive the packet of the network device through the open flow switch (S571).

The controller 10 determines whether the incoming packet of the flow can be interpreted (S572). If the incoming packet can not be interpreted, the controller 10 may forward the flow to the legacy routing container app 300 (S575). In the case of a protocol message used only in a legacy network, a general SDN-based controller can not interpret a packet.

The SDN-based controller 10 can not calculate the routing path of the incoming legacy packet if the incoming packet is a legacy packet, such as being sent from an external first legacy network to an external second legacy network. Thus, if the controller 10 can not compute the path, such as a legacy packet, the controller 10 may forward the legacy packet to the legacy routing container app 300. The legacy routing path for the legacy packet can be calculated by the routing processing section 332 of the virtual router 340. [ However, knowing the final processing method of the edge port and the legacy packet to which the legacy packet will flow, the controller 10 can process the legacy packet through the flow modification.

If the packet can be analyzed, the controller 10 searches the flow path such as whether the path of the flow can be calculated or whether there is an entry in the entry table (S573). If the path can not be retrieved, the controller 10 transfers the flow to the legacy routing container application 300 (S575). If the path can be searched, the controller 10 may generate a packet-out message specifying the output of the packet and transmit it to the open flow switch inquiring the packet (S574).

FIG. 22 is a flowchart of a processing method for an incoming packet in a virtual router, and FIG. 23 is a flowchart for an example other than the routing processing of FIG.

22, the virtual routing application 300 analyzes the incoming packet of the flow received through the controller 10 and extracts the slicing identifier of the incoming packet (S581).

The virtual routing application 300 may determine whether a set of namespace (ns) identifiers associated with the extracted slicing identifiers is included in the association list of identifiers (S582).

If the slicing identifier and the namespace identifier set are not in the association list, the virtual routing application 300 may cause the incoming packet to be dropped (S589).

If the set of identifiers is in the association list, the virtual routing application 300 may forward the flow to the virtual router 340 with the namespace identifier associated with the slicing identifier (S583).

The routing processor 332 of the virtual router 340 analyzes the incoming packet of the received flow to determine whether the packet is a routing request message (S584).

If the incoming packet is a routing request, the virtual router 340 may determine whether there is routing information for the destination IP address of the incoming packet (S585).

If there is routing information for the destination IP address, the routing processor 332 may cause the incoming packet to be dropped (S589).

If there is routing information for the destination IP address, the routing processing unit 332 may generate a routing path and transmit the routing path to the virtual routing application 300 (S586). The routing path may be converted to an open flow protocol at either the legacy interface module 140 of the controller control unit 100 or the SDN interface module 310 of the virtual routing application 300 at step S587. For example, the legacy interface module 140 may create, modify, or delete a flow entry so that the flow proceeds on the open flow switches based on the routing path, and cause the entry table of the associated open flow switch to be updated.

If it is determined that the routing request has not been received (S583), the virtual router 340 may process the request (S588). See FIG. 23 for details.

Referring to FIG. 23, it is assumed that the incoming packet is a DHCP protocol in which a network device is started and a request for an IP address is made, not a routing request process.

The routing processor 332 of the virtual router 340 analyzes the content of the incoming packet and recognizes that the incoming packet is an IP address request message (S591). The routing processor 332 transfers the incoming packet to the DHCP virtual server 360 (S582). The DHCP virtual server 360 may generate the IP address information and the subnet mask information in consideration of the network environment of the network device that has sent the incoming packet, for example, which user group, or which tenant (S593). The generated IP address information and subnet mask information are transmitted to the sending network device via the virtual routing application 300, the controller 10, and the open flow switch (S594). The messages exchanged between the network device and the DHCP virtual server 360 may be general DHCP protocol messages (DHCP Discover, DHCP offer, DHCP request, DHCP ack).

FIG. 24 is a network configuration diagram of a PC power control system according to an embodiment of the present invention, FIG. 25 is a PC control signal flow chart of the system of FIG. 24, and FIG. 26 is a PC power scheduling control How to do it. Please refer to FIG. 13 to FIG.

24, the PC power control system by integrated routing includes a controller 10 for controlling a plurality of SDN-based switches, a PC power control application 600, a load control application 660, a plurality of boot image servers 0.0 > img.Svr.01 ~ 03), < / RTI > and a plurality of SDN based switches SW1-SW5.

The controller 10 may include a virtual routing application 300 and a virtual router 340. The virtual router 340 can treat the switch group including the switches of at least some of the plurality of switches SW1 to SW5 as virtual routers and generate routing information for the packets to be input to any one of the switches have. When the virtual routing application 300 receives the virtual router creation request message, the virtual routing application 300 can allocate the computing resources and create the virtual router 340 using the virtualization technology. The virtual routing application 300 can generate a plurality of virtual routers based on the slicing identifiers which are specific information based on the packets that are input to the plurality of switches SW1 to SW5. The slicing identifier corresponds to a tenant of a plurality of tenants connected to the plurality of switches.

The plurality of switches (SW1 to SW5) may be open-type switches supporting open flow based on the SDN protocol. In particular, the edge switch is preferably an open flow switch. A plurality of PCs (PC.11, PC.12, PC.21, PC.22) can be connected to the edge switch group among the plurality of switches (SW1-SW5).

In particular, in the network configuration diagram of Fig. 19, the network device (VM) is replaced with a PC and the PC power control application 600, the load control application 660 and the plurality of boot image servers (img.Svr.01- 03) are added, and detailed description of the same components will be omitted.

Multiple PCs (PC.11, PC.12, PC.21, PC.22) are PCs that can be switched on and off when the remote power switching signal is received through the network. Multiple PCs (PC.11, PC.12, PC.21, PC.22) can perform the boot operation in the existing network boot environment. For example, multiple PCs (PC.11, PC.12, PC.21, PC.22) can perform a network boot operation based on a Pre-boot eXecution Environment (PXE) boot. A plurality of PCs (PC.11, PC.12, PC.21, PC.22) mounts a boot image stored in one of a plurality of boot image servers (img.Svr.01 ~ 03) can do. A plurality of PCs (PC.11, PC.12, PC.21, PC.22) can perform the same operation as a PC operated in the existing Noh Hard service.

A plurality of switches SW1 to SW5 provide a switching and routing function through the controller 10 and an API transmission can be performed through the controller 10 And can convey various control messages to a particular PC or group of PCs. A detailed description will be given later.

The PC power control application 600 can control power of a plurality of PCs (PC.11, PC.12, PC.21, PC.22). When the remote power switching signal is transmitted to the PC via the plurality of switches SW1 to SW5 in the PC power control application 600, the PC can switch on and off. The remote power switching signal may be a WOL (Wake On Lan) or the like. Multiple PCs (PC.11, PC.12, PC.21, PC.22) can support WOL.

When the PC receives the remote power switching signal while the power is off, the power is turned on and the DHCP client is activated and can send a DHCP request to get the IP. The DHCP request packet may be broadcast cast.

The PC power control application 600 can group a plurality of PCs (PC.11, PC.12, PC.21, PC.22) and perform separate scheduling power management for each PC group. Scheduling power management can be generated according to a preset power policy. It is preferable from the management viewpoint that each PC group belongs to the same network (tenant) by the controller 10.

In addition, the PC power control application 600 can perform dynamic boot image management for each PC group. The PC power control application 600 can provide one of several boot images to a specific PC group so that different boot images can be mounted on the PCs of the PC group by time zone.

The DHCP virtual server 360 of the virtual router 340 can process the response according to the DHCP request. In addition to assigning an IP address, the DHCP response may provide a boot image identifier designated by the PC power control application 600. For this, the DHCP virtual server 360 may store the location information of the boot image for each PC. The DHCP virtual server 360 may include the location information of the boot image according to the namespace so that the PC groups that transmitted the DHCP request packet having the same slicing identifier can be mounted with the same boot image.

The boot image identifier may be location information (URL or URI) of the boot image file including the server on which the boot image is stored and the folder of the server.

The boot image identifier may consist of a unique value indicating a plurality of boot image files of the same content. A plurality of boot image servers (img.Svr.01 ~ 03) can distribute and store boot image files having the same contents. The load control application 660 that receives the boot image request packet with the boot image identifier of PC may determine whether the boot image file corresponding to the boot image identifier is stored The boot image request packet may be transmitted to the optimal server among the boot image servers.

25 assumes that a first virtual router 341 that manages specific tenants is created by the virtual routing application 300 of the controller 10 of FIG.

Referring to FIG. 25, the PC power control application 600 can request PC information for power control of the PC connected to the plurality of switches SW1 to SW5 through the controller 10 (S701). In this embodiment, the PC information request message (req.info) is transmitted to the eleventh PC (PC.11) via the eleventh switch SW11, but the present invention is not limited thereto. For example, a PC information request message (req.info) may be broadcast and transmitted to all PCs, or may be transmitted specifying a connected PC when it is detected that a new PC is connected.

Upon receiving the PC information request message (req.info), the eleventh PC (PC.11) may transmit the PC information response message including the MAC address to the eleventh switch SW11 (S703). The eleventh PC (PC.11) may broadcast the PC information irrespective of the PC information request message (req.info). The PC information response message (res.info) may further include a slicing identifier. The slicing identifier may be vLAN information. The slicing identifier may be added by the eleventh switch SW11.

The eleventh switch SW11 may add switch information of the eleventh switch SW11, for example, a DPID which is a switch identifier, to the received PC information response message (res.info). The eleventh switch SW11 may add the incoming port information, which is the port that received the PC information response message (res.info), to the PC information response message (res.info). The eleventh switch SW11 may further add a slicing identifier if the PCS information response message (res.info) does not include the slicing identifier. Thereafter, the PC information response message (res.info) can be transmitted from the eleventh switch SW11 to the PC power control application 600 through the controller control unit 100 (S705).

The PC power control application 600 may monitor the preset scheduling policy (S750). The scheduling policy is described with reference to FIG. 26, which will be described later.

The PC power control application 600 can transmit the remote power switching signal (packet) (pk.WOL) to the 11th PC (PC.11) by an administrator instruction or according to a scheduling policy (S751) . The remote power switching signal pk.WOL may be configured such that packets are transmitted only from the eleventh switch SW11 to the eleventh PC 11 or all the PCs 11, Lt; RTI ID = 0.0 > 12). ≪ / RTI > The remote power switching signal (pk.WOL) may be an existing WOL packet.

Upon receiving the remote power switching signal (pk.WOL), the 11th PC (PC.11) can switch the power state from "ON" to "OFF" or from "OFF to ON" (S753). In the present embodiment, it is assumed that the power of the eleventh PC (PC.11) is changed from OFF to ON.

The eleventh PC (PC.11) with the power turned on can generate a DHCP request message (packet) (req.DHCP) requesting an IP address together with the location of the boot image file and transmit it to the eleventh switch SW11. The eleventh switch SW11 may designate a slicing identifier, i.e., a vLAN value, as 101 in the DHCP request message (req.DHCP), and may transmit the slicing identifier to the virtual routing application 300 through the controller control unit 100. [ The eleventh switch SW11 may selectively add information such as switch information and an incoming port to the DHCP request message (req.DHCP). The virtual routing application 300 can transmit a DHCP request message (req.DHCP) to the first virtual router 341 having the same namespace as the slicing identifier through packet analysis (S755).

The first virtual router 341 receives a DHCP response message (res.DHCP) having a boot image identifier retrieved from the list of pre-stored PC information and boot image identifier pairs as the key value of the PC information of the DHCP request message (req.DHCP) And transmits it to the 11th PC (PC.11) (S757). The first virtual router 341 may set the destination IP address as the IP address of the image server having the boot image identifier. However, as described above, the destination virtual IP address is set to the IP address of the load control application 660 . The load control application 660 may be an app running on a separate server or an app running on one of a plurality of boot image servers (img.Svr.01 ~ 03). The IP address of the load control application 660 means the IP address of the server that drives the load control application 660. [

The eleventh PC (PC.11) receiving the DHCP response message (res.DHCP) generates a boot image request message (req.Img) based on the boot image identifier of the DHCP response message (res.DHCP) (SW11) to the load control application 660 (S759).

The load control application 660 is based on a predetermined load balancing policy among the image server groups having the boot image identifier included in the boot image request message (req.Img) among the plurality of boot image servers (img.Svr.01 to 03) The boot image request packet req.Img may be transmitted to the optimal image server (assuming the first image server (img.Svr.01)) (S761).

The first image server img.Svr.01 may transmit the boot image file res.Img corresponding to the boot image identifier to the eleventh PC PC 11. S763. The 11th PC (PC.11) can be booted by mounting the received boot image file (res.Img).

Referring to FIG. 26, the PC power control application 600 can configure a network domain for each namespace (S721). The PC power control application 600 can schedule a boot image to be mounted on a PC independent of each namespace.

The PC power control application 600 can set an image to be booted by the PC in a time zone based on the domain (S723). That is, the PC power control application 600 may store and manage a scheduling list including a namespace, a time zone, and a boot image identifier, and perform a scheduling policy.

The PC power control application 600 can transmit a power off message to the PCs when the dynamic change time for the PC is booted by the scheduling list (S725). If the power state of the corresponding PC is OFF, this step may be omitted.

The PC power control application 600 can transmit a power-on message to the PCs (S727). Thereafter, the CPUs of the corresponding domain can be restarted with the booting image according to the scheduling by processing the DHCP messages (S729).

The present invention can be implemented in hardware or software. The present invention can also be embodied as computer readable code on a computer readable recording medium. That is, in the form of a recording medium including instructions executable by the computer. Computer-readable media includes any type of media in which data that can be read by a computer system is stored. Computer readable media can include computer storage media and communication media. Computer storage media includes any storable medium embodied as any method or technology for storage of information such as computer readable instructions, data structures, program modules, and other data, including volatile / nonvolatile / hybrid type memory Whether it is separated / non-detachable, and the like. Communication media includes modulated data signals or transmission mechanisms, such as carrier waves, any information delivery media, and the like. And functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers skilled in the art to which the present invention pertains.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, It will be understood by those skilled in the art that various changes and modifications may be made by those skilled in the art without departing from the spirit and scope of the present invention.

10: controller 20: SDN switch
30: Network device 100: Controller controller
120: Topology management module 125: Path calculation module
130: Message management module 135: Entry management module
190: storage unit 200: switch control unit
205: port portion 210; Controller communication section
220: Flow Search Module 230: Flow Processing Module
235: Packet processing module 240: Table management module
300: virtual routing app 340: virtual router

Claims (7)

A method for providing an IP address of a multi-tenant supporting network system based on SDN (Software Defined Network)
The system comprises:
A controller for controlling a plurality of SDN-based switches;
A virtual router for treating a switch group including at least some switches among the plurality of switches as a virtual router and generating routing information for a packet to be input to one of the switches;
A virtual routing application that, when receiving a virtual router creation request message, allocates computing resources to create the virtual router using virtualization technology; And
And a PC power control application for controlling power of a PC connected to an edge switch among the plurality of switches,
Wherein the virtual routing application generates a plurality of virtual routers based on the slicing identifiers, which are specific information based on packets to be transmitted to the plurality of switches,
Wherein the slicing identifier corresponds to a tenant of a plurality of tenants connected to the plurality of switches,
The PC power control application transmitting a remote power switching signal through the network to the PC;
Switching the power of the PC to an on state when receiving the remote power switching signal when the PC is in an off state;
Receiving a Dynamic Host Configuration Protocol (DHCP) request packet transmitted by the virtual router from the PC;
Transmitting, by the virtual DHCP server, a DHCP response packet having the IP address and the boot image identifier to the PC corresponding to the DHCP request packet; And
And transmitting the boot image request packet to the edge switch based on the boot image identifier of the DHCP response packet received by the PC. The method according to claim 1,
Wherein the plurality of virtual routers form an isolated network from each other. The method according to claim 1,
Wherein the virtual routing application assigns to the virtual router network information having a namespace identifier associated with a slicing identifier of the packet. The method of claim 3,
Wherein the virtual routing application further comprises extracting a slicing identifier in the received DHCP request packet and delivering the DHCP request packet to a virtual router having a namespace identifier corresponding to the extracted slicing identifier, To control the power of the PC. 5. The method of claim 4,
Wherein the PC power control application further comprises modifying a boot image identifier of a DHCP server of the virtual router according to a predetermined scheduling policy. The method according to claim 1,
The edge switch sending the boot image request packet to a load control app that adjusts the load of a plurality of image servers storing a boot image; And
Wherein the load control application transmits the boot image request packet to a specific image server based on a predetermined load balancing policy among image server groups having a boot image identifier included in the boot image request packet among the plurality of image servers Further comprising the step of controlling the power of the PC by the integrated routing. A controller for controlling a plurality of switches based on SDN (Software Defined Network);
A virtual router providing a virtual routing function; And
A method of controlling power of a multi-tenant network system having a virtual routing application for generating the virtual router,
Receiving, at the virtual routing application, a routing request message;
In the virtual routing application, allocating computing resources to create the virtual router;
Designating, in the virtual application, network information having a namespace identifier in the virtual router; And
And in the virtual router, preparing the virtual routing function using the network information,
Wherein the namespace identifier corresponds to a tenant of a plurality of tenants connected to the plurality of switches,
The virtual routing application creates a plurality of virtual routers,
Wherein the namespace identifier corresponds to a slicing identifier which is specific information based on a packet that is input to the plurality of switches,
Transmitting, by the control unit of the controller, the incoming packet to the virtual routing application when there is no processing information of a packet entered into any one of the plurality of switches;
Extracting a slicing identifier from the incoming packet in the virtual routing application;
Transferring the incoming packet to a virtual router having a namespace identifier corresponding to the extracted slicing identifier among the plurality of virtual routers in the virtual routing application;
Generating an IP address by using a virtual DHCP server function when the incoming packet is a dynamic host configuration protocol (DHCP) in the virtual router; And
Further comprising generating a response packet including the IP address and the pre-stored boot image identifier in the multi-tenant network system.

Images