KR20180058593A - Software Defined Network Whitebox Switch - Google Patents

Abstract

The present invention relates to a software defined network (SDN) controller, an SDN white box switch and an SDN/TAP (test access port) application and a system including all of them. It is possible to provide a TAP solution on the SDN that does not depend on a specific SDN device. The SDN white box switch changes mapped information according to a procedure called in the TAP.

Description

SDN white box switch {Software Defined Network Whitebox Switch}

The present invention relates to a software defined network (SDN) controller, an SDN white-box switch and an SDN / TAP (Test Access Port) application and a system including both.

TAP provides functions such as debugging, pattern analysis, data analysis, data center monitoring, trespass detection, network and application performance measurement, security monitoring, data leakage prevention system and SLA (Service Level Agreement) There is a problem in that additional devices must be provided on the network in order to use these functions.

Many analysis systems such as Intrusion Prevention System (IDS) and IDS (Detection) are now becoming NFV (Network Function Virtualization). As a solution to this problem, SDN (Software Defined Network) and OpenFlow There is an attempt to solve the above problems. However, there is a problem that the SDN controller is dependent on the manufacturer because one SDN device operates in the same manner as most software, and one packaged software operates dependently on the internal modules.

Therefore, the development of a TAP solution on an SDN that is not dependent on a specific SDN equipment is required.

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

The present invention seeks to provide a TAP solution on an SDN that is not dependent on a specific SDN equipment.

A SDN controller according to the present invention is an SDN controller for acquiring information of a plurality of open flow edge switches belonging to a switch group, wherein a plurality of open flow edge switches connected to a plurality of legacy networks,

The plurality of legacy networks generate at least one virtual router so that at least a part of the switch group is treated as a legacy router based on the acquired information of the plurality of open flow edge switches, A legacy routing container for generating legacy routing information based on the information of the at least one virtual router maps a plurality of network devices connected to the plurality of open flow switches to external network information directly connected to the virtual router,

And changes the mapped information according to a procedure called in a TAP (Test Access Port) application.

Further, a white-box switch according to the present invention is a white-box switch in which a plurality of open-flow edge switches connected to a plurality of legacy networks provide information of the plurality of open-flow edge switches belonging to a switch group,

The plurality of legacy networks generate at least one virtual router so that at least a part of the switch group is treated as a legacy router based on the acquired information of the plurality of open flow edge switches, A legacy routing container for creating legacy routing information for a flow inquiry message of an SDN controller that obtains information based on information of the at least one virtual router is provided to a plurality of network devices connected to the plurality of open flow switches, To the external network information directly connected to the network,

And changes the mapped information according to a procedure called in a TAP (Test Access Port) application.

In addition, the SDN / TAP (Software Defined Network / Test Access Port) application according to the present invention may include a plurality of open flow edge switches connected to a plurality of legacy networks for receiving information of the plurality of open flow edge switches belonging to a switch group As an SDN / TAP application to acquire,

The plurality of legacy networks generate at least one virtual router so that at least a part of the switch group is treated as a legacy router based on the acquired information of the plurality of open flow edge switches, A legacy routing container for generating legacy routing information based on the information of the at least one virtual router maps a plurality of network devices connected to the plurality of open flow switches to external network information directly connected to the virtual router,

And calls the procedure to change the mapped information.

A system comprising a Software Defined Network (SDN) controller, an SDN white box switch, and an SDN / Test Access Port (SDN / TAP) according to the present invention and a system including both of them can be controlled by a TAP application as an SDN controller, TAP functions can be performed, and a plurality of network devices and switches can be centrally managed.

1 is a block diagram of an SDN network system according to an embodiment of the present invention;
2 is a block diagram of an SDN network system according to another embodiment of the present invention;
3 is a block diagram of an SDN network system according to another embodiment of the present invention;
4 is a block diagram of an SDN controller of the network system of Figs.
Fig. 5 is a block diagram of a switch of the network system of Figs. 1 to 3,
6 is a block diagram of a TAP application of the network system of Figs.
7 shows an operation table indicating the type of operation according to the field table and the flow entry of the flow entry,
Figure 8 shows the field tables of the group and metric tables,
9 is a block diagram of a network system including an integrated routing system according to an embodiment of the present invention;
10 is a virtualized block diagram of the network system of FIG. 9,
11 is a block diagram of an SDN controller according to another embodiment of the present invention.
12 is a block diagram of a legacy routing container according to an embodiment of the present invention;
FIG. 13 is a flow chart of a method of determining whether or not legacy routing is performed for the flow of the SDN controller of FIG. 9;
FIG. 14 is a signal flow diagram according to an integrated routing method according to an embodiment of the present invention;
15 is a signal flow diagram according to an integrated routing method according to another embodiment of the present invention, and Fig.
16 is a flow table according to an embodiment of the present invention.

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

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

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

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

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

FIG. 1 is a block diagram of an SDN network system according to an embodiment of the present invention. FIG. 4 is a block diagram of an SDN controller of the network system of FIG. 1. FIG. Fig. 7 is an operation table showing a field table of a flow entry and an operation type according to a flow entry, and Fig. 8 is a field table of a group and a meter table.

Referring to FIG. 1, an SDN network system according to an embodiment of the present invention may include an SDN controller 10, a plurality of switches 20, and a plurality of network devices 30.

The network device 30 may include a user terminal device to which data or information is exchanged, or a physical or virtual device that performs 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.

There is a network function virtualization (NFV) defined in a white paper on NFV issued by the European Telecommunications Standards Institute (ETSI) (see non-patent reference 3) as a virtualized network function. 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.

The SDN 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 SDN controller 10 can define the flow of packets occurring in the plurality of switches 20 in the lower layer. The SDN controller 10 may calculate the path (data path) to which the flow passes by referring to the network topology and the like with respect to the flow allowed in the network policy, and then set the entry of the flow in the switch on the path. The SDN controller 10 may communicate with the switch 20 using a particular protocol, for example, an open flow protocol. The communication channel between the SDN controller 10 and the switch 20 can be encrypted by SSL.

Referring to FIG. 2, a plurality of SDN controllers 10 may be coupled to a single TAP application 50.

Referring to FIG. 3, a white box switch 40 connected to a TAP application 50 is connected to a data center 60 in which a large number of network devices constitute a network and a large amount of traffic is generated through a relay server 70 And the traffic analysis application 80 connected to the relay server 70 can analyze the traffic between the data centers 60.

4, the SDN controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190 for communicating 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 SDN controller 10 by controlling 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, an API server module 136 and an API parser module 137 and a message management module 130 have. 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 the switches and a network device topology connected to each switch.

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 by 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 API server module 136 may perform a procedure according to a procedure for changing the information of the mapped network device.

The API parser module 137 may interpret the procedure for changing the information of the mapped network device.

The message management module 130 may interpret the message received through the switch communication unit 110 or may generate an SDN 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 SDN controller-switch messages, may be generated based on the entry according to 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. [

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.

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.

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

The port unit 205 may include a plurality of pairs of ports that are flown out from 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 210. [ 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 by the SDN controller 10. The table entry can be destroyed by itself.

6, the TAP application 50 may include a control unit 500, a communication unit 510 for communicating with the SDN controller 10, and a storage unit 590.

The control unit 500 may include a layer filter module 521, a policy management module 522, a port management module 523, an API server module 536, and an API parser module 537.

The storage unit 590 may include an entry DB 591, a port DB 592, a filter DB 593, and a policy DB 594.

The flow table can be composed of multiple flow tables to handle the pipeline of open flows. Referring to FIG. 7, a flow entry of a flow table includes match fields describing conditions (matching rules) that 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 by the switch, an opaque type that is selected by the SDN controller, May be used by the controller to filter flow statistics, flow changes, and flow deletes, and may 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 is an operation 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. FIG. 8 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 matching the packet, the packet may be dropped according to the table setting, or the packet may be sent to the SDN 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. 8A, 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.

The meter table is made up 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. 8 (b), a meter table includes a meter identifier for identifying a meter, a speed 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 210 can control the overall operation of the switch 200 by controlling the operations of the respective units. The control unit 210 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 110 and may be configured in software separate from the control unit 110. [

The table management module 240 may add the entry received from the SDN controller 10 to the appropriate table through the SDN 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 SDN controller 100 through the SDN 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 can actually output the processed packet by the flow processing module 230 to one or more ports of the port unit 205 specified by the flow processing module 230. [

Although not shown in FIG. 1, the SDN network system may further include an orchestrator for creating, changing, and deleting virtual network devices, virtual switches, and the like. When an orchestrator creates a virtual network device, the orchestrator generates a virtual network device such as a network device, such as identification information of a switch to be connected to the virtual network, port identification information connected to the switch, MAC address, IP address, tenant identification information, Information to the SDN controller 10.

The SDN 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 an SDN 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 SDN controller-switch message is a message generated by the SDN controller 10 and transmitted to the switch 20, which is mainly used to manage or check the state of the switch 20. [ The SDN controller-switch message may be generated by the controller 100 of the SDN controller 10, and in particular by the message management module 130.

The SDN controller-switch message includes features for querying the capabilities of the switch, configuration for inquiring and configuring settings such as the configuration parameters of the switch 20, flow / group / A modify state message for adding / deleting / modifying meter entries, a packet-out message for sending a packet received from the switch via a packet-in message to a specific port on the switch, . 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 and the network event in the SDN 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 SDN controller 10 to receive control of the packet. The packet-in message may include all or part of the received packet, or a copy thereof, sent from the open flow switch 20 to the SDN controller 10 to request the data path if the switch 20 receives an unknown packet It is a message to include. 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 SDN controller. The deleted flow-removed message is used to forward the flow entry information to the SDN controller 10 to be deleted from the flow table. This message occurs when the SDN 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 SDN controller 10 and the switch 20, and is transmitted even if there is no request from the other party. It is used by the hello, SDN controller used to initiate the connection between the SDN controller and the switch, the echo to confirm that there is no abnormality in the SDN controller and switch connection, and the SDN controller or switch, And an error message for the user. The error message is mostly used in the switch to indicate a failure in response to a request initiated by the SDN controller.

FIG. 9 is a block diagram of a network system including an integrated routing system according to an embodiment of the present invention, FIG. 10 is a block diagram of a virtualized system of the network system of FIG. 9, and FIG. 12 is a block diagram of a legacy routing container according to an embodiment of the present invention.

The network shown in Fig. 9 includes an SDN-based network including an SDN controller 10 for controlling the flow of an open flow switch among switch groups composed of a plurality of switches SW1 to SW5, and a first to a 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.

9, an SDN-based integrated routing system according to the present invention includes a switch group having first to fifth switches SW1 to SW5, an SDN controller 10, and a legacy routing container 300 . Refer to Figures 1-8 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.

Referring to FIG. 11, the SDN controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190, which communicate with the switch 20.

The control unit 100 of the SDN controller may include a topology management module 120, a path calculation module 125, an entry management module 135, a message management module 130, and a legacy interface module 145. 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. 4 for a description of the components of the same reference numerals.

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

The legacy interface module 145 may communicate with the legacy routing container 300. The legacy interface module 145 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 may include connection information of the first to fifth switches SW1 to SW5 and connection or connection information of a plurality of network devices connected to the first to fifth switches SW1 to SW5.

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

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

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

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

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

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

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

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

10B, the connection between the plurality of virtual legacy routers (v-R1, v-R2) and the legacy router is performed by connecting to a plurality of sub-interfaces in which one physical 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. 10A, the virtual router creation unit 320 has created the 0th port (port 0) in the 0th virtual legacy router (v-R0). 10 (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 of the switch group are connected. 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. 9 by the virtual router 340 generated in the virtual router 340 can be virtualized as shown in Fig. 10 (a) or 10 (b). For example, in the case of FIG. 10 (a), the virtualized network is configured such that the first to fifth switches SW1 to SW5 are virtualized into the virtual legacy router v-R0, and the virtualized legacy router v- The 11th, 32v, and 33v ports (ports 11v, 32v, and 33v) are connected to the first to third legacy routers R1 to R3 and are connected to the 0th port of the 0th virtual legacy router (v- port 0) may be connected to an external network (vN) which is at least a part of a plurality of network devices.

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

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

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

13 is a flowchart of a method of determining whether legacy routing is performed for the flow of the SDN controller of FIG. 9 to 12.

The legacy routing decision method for the flow refers to whether the SDN 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. 13, the SDN controller 10 determines whether the flow-in port is an edge port (S510). If the flow-in port is not an edge port, the SDN controller 10 can perform SDN-based flow control by calculating a path to a general open flow packet (S590).

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

If the received packet is a legacy packet such as is transmitted from the first legacy network to the second legacy network, the SDN based controller 10 can not calculate the routing path of the incoming legacy packet. Thus, if the SDN controller 10 can not compute the path, such as a legacy packet, it is desirable for the SDN controller 10 to send the legacy packet to the legacy routing container 300. However, knowing the final processing method of the edge port and the legacy packet to which the legacy packet will flow, the SDN controller 10 can process the legacy packet through the flow modification. If the packet can be interpreted, the SDN controller 10 searches the flow path such as whether the path of the corresponding flow can be calculated or whether there is an entry in the entry table (S530). If the path can not be retrieved, the SDN controller 10 may forward the flow to the legacy routing container 300 (S550). If the path can be searched, the SDN controller 10 can generate a packet-out message designating the output of the packet and transmit it to the open flow switch inquiring the packet (S540). Detailed examples of this will be described later with reference to FIG. 14 and FIG.

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

14 shows a flow of processing a legacy protocol message in an SDN-based network to which the present invention is applied. FIG. 14 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 SDN controller 10 and the legacy routing container 300 as shown in Fig. 10 (a).

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

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

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

The SDN interface module 345 of the legacy routing container 300 transmits the Hello1 packet received from the SDN controller 10 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 routing processor 330 can generate the legacy routing information of the Hello1 packet based on the routing table 335 (S450). In the present embodiment, the routing processor 330 generates a Hello2 message corresponding to the Hello1 message, and specifies a routing path for designating the output port as the 11v port (port 11v) so that the Hello2 packet is transmitted to the first legacy router R1 Can be generated. The Hello2 message has a destination which is the first legacy router R1 and a pre-designated virtual router identifier. The legacy routing information may include a Hell2 packet, and an output port that is an eleventh port. The routing processor 330 may generate the legacy routing information by using the information of the virtual router 340. However, the present invention is not limited thereto.

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

The path calculation module 125 of the SDN controller 10 uses the legacy routing information received through the legacy interface module 145 so that the Hello2 packet is output to the eleventh port (port 11) of the first legacy router R1 (S470).

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

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

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

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

Since the first edge switch SW1 does not have a flow entry for the packet P1, the first edge switch SW1 can transmit the packet P1 to the SDN controller 10 and inquire about the flow process (packet-in message) (S620).

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

The routing processor 330 of the legacy routing container 300 may generate the legacy routing information based on the information of the virtual router 340 and the routing table 335 from the packet P1 received from the SDN controller 10 ). 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 becomes the MAC of the incoming port of the second legacy router. That is, part of the header information of the packet P1 changes during the legacy routing.

In order to correspond to the legacy routing, the routing processing unit 330 may generate the packet P1 'in which the header information of the packet P1 is adjusted and include it in the legacy routing information. In this case, the incoming packet must be processed to the SDN controller 10 or the legacy routing container 300 every time for the same packet, or a similar packet having the same destination address range. Accordingly, 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 rather than the legacy routing container 300 . To this end, the legacy routing information described above may include source and destination MAC addresses. The SDN controller 10 may use this routing information to send a flow-Mod message to the third edge switch to change the header information of the packet P1 '.

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

The path calculation module 125 of the SDN controller 10 outputs the output from the first edge switch SW1 to the 32nd port of the third edge switch SW3 using the legacy routing information received via the legacy interface module 145 (Step S670).

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

The flow process for the packet P1 is preferably based on an identifier capable of identifying 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 the flow table of each switch is shown in Fig. 16 (a) is a flow table of the first edge switch SW1. For example, Table 0 in FIG. 16 (a) adds tunnel 2 as a legacy identifier to the flow to the second legacy router R 2 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). 16B is an example of a flow table of the fourth switch SW4. In the table of FIG. 16B, 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. 16 (c) is an example of a flow table of the third switch SW3. Table 0 in FIG. 16 (c) removes the legacy identifier of the flow whose legacy identifier is tunnel2 and causes the flow to move to Table 1. Table 1 outputs the flow to port 32. By using multiple tables in this way, the number of cases can be reduced. This makes it possible to perform a quick search and reduce resource consumption of memory and the like.

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

The core network may transmit the flow to the third edge switch SW3 (S730). The third edge switch SW3 may remove the legacy identifier and output packet P1 to the designated port (S740). In this case, although not shown in the flow table of Fig. 16, 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.

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

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

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 in form and detail may be made therein without departing from the spirit and scope of the present invention.

10: SDN controller 20: SDN switch
30: Network device 40: White box switch
50: TAP application 60: Data center
70: Relay server 80: Traffic analysis application
100: control unit 120: topology management module
125: path calculation module 130: message management module
135: Entry management module 136: API server module
137: API parser module 140: message determination module
145: legacy interface module 190:
200: switch control unit 205: port unit
210; SDN controller communication unit 220: Flow search module
230: flow processing module 235: packet processing module
240: Table management module 300: Legacy Kenterer
500: control unit 510: communication unit
520: device management module 521: layer filter module
522: Policy management module 536: API server module
537: API parser module 590:
591: Entry DB 592: Port DB
593: Filter DB 594: Policy DB

Claims (4)

Wherein a plurality of open flow edge switches connected to a plurality of legacy networks provide information of the plurality of open flow edge switches belonging to a switch group,
The plurality of legacy networks generate at least one virtual router so that at least a part of the switch group is treated as a legacy router based on the acquired information of the plurality of open flow edge switches, A legacy routing container for creating legacy routing information for a flow inquiry message of an SDN controller that obtains information based on information of the at least one virtual router is provided to a plurality of network devices connected to the plurality of open flow switches, To the external network information directly connected to the network,
SDN white box switch in which the mapped information changes according to a procedure called in a Test Access Port (TAP) application. The method according to claim 1,
Wherein the called procedure virtualizes a plurality of SDN controllers into a single router system. The method according to claim 1,
And the called procedure limits the mapped information to a predefined network layer. The method according to claim 1,
Wherein the called procedure limits the mapped information to a predefined constraint and priority.

Images