WO2017122847A1 - Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템 - Google Patents

Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템 Download PDF

Info

Publication number
WO2017122847A1
WO2017122847A1 PCT/KR2016/000436 KR2016000436W WO2017122847A1 WO 2017122847 A1 WO2017122847 A1 WO 2017122847A1 KR 2016000436 W KR2016000436 W KR 2016000436W WO 2017122847 A1 WO2017122847 A1 WO 2017122847A1
Authority
WO
WIPO (PCT)
Prior art keywords
legacy
container
packet
network
controller
Prior art date
Application number
PCT/KR2016/000436
Other languages
English (en)
French (fr)
Inventor
박성용
공석환
딥죠이티사이키아
Original Assignee
쿨클라우드(주)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020160003888A external-priority patent/KR101729945B1/ko
Priority claimed from KR1020160003797A external-priority patent/KR101729939B1/ko
Application filed by 쿨클라우드(주) filed Critical 쿨클라우드(주)
Publication of WO2017122847A1 publication Critical patent/WO2017122847A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming

Definitions

  • the present invention relates to a multi-tenant support method and system therefor for a software defined network (SDN) -based network system, and enables flexible network operation using a plurality of virtual routers and supports multi-tenancy through a plurality of routers.
  • SDN software defined network
  • the present invention relates to a method and a system for supporting multi-tenant.
  • SDN Software-Defined Network
  • Open flow is one of the mechanisms that separate high-speed data planes and high-level routing decision functions.
  • the packet forwarding plane is still involved in the switch stage, while high-level routing decisions are involved in separate controllers, which communicate through open flow protocols.
  • the existing virtual router In the case of the existing virtual router, the control plane and the data plane coexist, and the existing router is often moved into the form of a virtual machine. This is dependent on virtualization technology, and performance is low compared to existing hardware routers. In addition, the existing routers had to be managed individually for each router and could not actively respond to changes in network requirements.
  • Network management through DHCP handling in a traditional cloud environment is done at the cloud control node.
  • Non-Patent Document 1 OpenFlow Switch Specification version 1.4.0 (Wire Protocol 0x05), October 14, 2013 [https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow -spec-v1.4.0.pdf]
  • Non-Patent Document 2 Software-Defined Networking: The New Norm for Netwrks, ONF White Paper, April 13, 2012 [https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp -sdn-newnorm.pdf]
  • Non-Patent Document 3 ETSI GS NFV 002 v1.1.1 (2013-10)
  • An object of the present invention to support the legacy network in the SDN network, to provide a cloud environment to a variety of users, such as a data center, to charge according to the user's usage, to enable elastic network operation, the user It is to provide an SDN-based multi-tenant support network system that can easily manage the network while ensuring the service quality of the service.
  • Another object of the present invention is to provide a method for providing an IP address in which a SDN controller directly manages a DHCP server managed by a cloud control node.
  • a controller for controlling a plurality of switches based on SDN Software Defined Network
  • a legacy container which handles a switch group including at least some of the switches of the plurality of switches as a virtual router, and generates routing information for a packet introduced into any one of the switch groups
  • a legacy container app configured to allocate a computing resource and generate the legacy container using a virtualization technology upon receiving a virtual router creation request message, wherein the legacy container app includes specific information based on packets introduced into the plurality of switches.
  • Multiple legacy containers can be created based on the in-slicing identifier.
  • a controller for controlling a plurality of switches based on SDN Software Defined Network
  • a legacy container providing a virtual routing function
  • a legacy container app for generating a legacy container
  • the multi-tenant support method of a network system comprises: receiving, at the legacy container app, a routing request message; Allocating computing resources in the app to create the legacy container; Assigning, by the app, network information including a namespace identifier to the container; And in the container, preparing a virtual routing function using the network information, wherein the namespace identifier may correspond to one of a plurality of tenants connected to the plurality of switches.
  • a legacy network may be supported in an SDN network, a plurality of virtual routers may be provided, and a plurality of virtual routers may be collectively managed by an SDN controller. Accordingly, a routing function may be provided for various users, and a multi-tenancy function may be provided. It can also reduce management complexity.
  • FIG. 1 is a structural diagram of an SDN network system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram of a controller of the network system of FIG. 1;
  • FIG. 3 is a block diagram of a switch of the network system of FIG.
  • 4 is an operation table indicating a field table of a flow entry and an operation type according to the flow entry;
  • 5 is a field table of a group and a meter table
  • FIG. 6 is a structural diagram of a multi-tenant support network system according to an embodiment of the present invention.
  • FIG. 7 is a block diagram of components of the network system of FIG. 6;
  • FIG. 8 is a block diagram of a legacy container according to another embodiment of the present invention.
  • FIG. 9 is a flowchart illustrating a legacy container creation method.
  • FIG. 10 is a flowchart illustrating a method of preparing a routing function of FIG. 9;
  • FIG. 11 is a structural diagram showing various interfaces of a virtual router
  • FIG. 13 is a structural diagram of a virtual router according to FIG. 12;
  • FIG. 14 is a flowchart illustrating a method of determining legacy routing for a flow of the controller of FIG. 6.
  • 15 is a flowchart of a processing method for incoming packets in a legacy container.
  • FIG. 16 is a flowchart for an example other than the routing process of FIG. 15.
  • first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
  • the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.
  • a component When a component is referred to as being “connected” or “connected” to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be “directly connected” or “directly connected” to another component, it should be understood that there is no other component in between.
  • first component and the second component on the network are connected or connected, it means that data can be exchanged between the first component and the second component by wire or wirelessly.
  • module and “unit” for the components used in the following description are merely given in consideration of ease of preparation of the present specification, and do not give particular meanings or roles by themselves. Therefore, the “module” and “unit” may be used interchangeably.
  • Such components may be configured by combining two or more components into one component, or by dividing one or more components into two or more components as necessary when implemented in an actual application.
  • the same reference numerals are given to the same or similar components throughout the drawings, and detailed descriptions of the components having the same reference numerals may be omitted by replacing the descriptions of the aforementioned components.
  • SDN is a separate concept from the data plane that carries packets and the control plane that controls the flow of packets.
  • the network equipment asks the SDN control software (controller) where to forward the packet and reflects the result to determine the path and method of transmitting the packet.
  • SDN is a theoretical concept, and Openflow has emerged for practical application.
  • OpenFlow is a standard interface established to implement SDN. Openflow is composed of an openflow controller and an openflow switch to control flow information to determine the delivery path and method of the packet. Throughout this specification, openflow and SDN may be used interchangeably or in the same sense.
  • a flow may refer to a packet flow of a specific path according to a combination of a series of packets or multiple flow entries of multiple switches that share a value of at least one header field from one switch perspective.
  • Openflow networks can perform path control, failover, load balancing and optimization on a flow-by-flow basis.
  • a flow may mean a specific packet, and may also include other metadata such as a specific packet and an ingress port.
  • FIG. 1 is a block diagram of an SDN network system according to an embodiment of the present invention
  • FIG. 2 is a block diagram of a controller of the network system of FIG. 1
  • FIG. 3 is a block diagram of a switch of the network system of FIG. 4 is an operation table indicating a field table of a flow entry and an operation type according to the flow entry
  • FIG. 5 is a field table of a group and a meter table.
  • an SDN network system may include a controller 10, a plurality of switches 20, and a plurality of network devices 30.
  • the network device 30 may include a user terminal device for exchanging data or information, or a physical device or a virtual device for performing a specific function. From a hardware point of view, the network device 30 may be a PC, a client terminal, a server, a workstation, a supercomputer, a mobile communication terminal, a smartphone, a smart pad, or the like. Network device 30 may also be a virtual machine (VM) created on a physical device.
  • VM virtual machine
  • the network device 30 may be referred to as a network function that performs various functions on the network.
  • Network features include anti-DDoS, intrusion detection / blocking (IDS / IPS), integrated security services, virtual private network services, antivirus, antispam, security services, access management services, firewalls, load balancing, QoS, video optimization, etc. It may include.
  • This network function can be virtualized.
  • a virtualized network function is the Network Function Virtualization (NFV) defined in the NFV white paper (see Non-Patent Document 3) issued by the ETSI (European Telecommunication Standards Association).
  • Network function can be used interchangeably with network function virtualization (NFV) herein.
  • NFV dynamically creates the necessary L4-7 service connections per tenant to provide the necessary network functions, or in the case of DDoS attacks, quickly provides the necessary firewall, IPS, and DPI features through a series of service chaining. Can be.
  • NFV can easily turn on or off firewalls or IDS / IPS and automatically provision them. NFV can also reduce the need for over-provisioning.
  • the controller 10 is a kind of command computer that controls the SDN system, and can perform various and complex functions such as routing, policy declaration, security check, and the like.
  • the controller 10 may define a flow of packets occurring in the plurality of switches 20 of the lower layer.
  • the controller 10 may calculate a path (data path) for the flow to pass through by referring to the network topology and the like for the flow allowed by the network policy, and then allow the entry of the flow to be set in the switch on the path.
  • the controller 10 may communicate with the switch 20 using a specific protocol, such as an openflow protocol.
  • the communication channel of the controller 10 and the switch 20 may be encrypted by SSL.
  • the controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190 communicating with the switch 20.
  • the storage unit 190 may store a program for processing and controlling the controller 100.
  • the storage unit 190 may perform a function for temporarily storing input or output data (packets, messages, etc.).
  • the storage unit 190 may include an entry database (DB) 191 that stores flow entries.
  • DB entry database
  • the controller 100 may control the overall operations of the controller 10 by controlling the operations of the respective units.
  • the controller 100 may include a topology management module 120, a path calculation module 125, an entry management module 135, and a message management module 130. Each module may be configured in hardware in the controller 100, or may be configured in software separate from the controller 100.
  • the topology management module 120 may construct and manage network topology information based on a connection relationship of the switches 20 collected through the switch communication unit 110.
  • the network topology information may include a topology between switches and a topology of network devices connected to each switch.
  • the topology information may be stored in the storage 190.
  • the path calculation module 125 may obtain a data path of a packet received through the switch communication unit 110 and an action string to be executed in the switch on the data path based on the network topology information constructed by the topology management module 120.
  • the entry management module 135 may register with the entry DB 191 as an entry such as a flow table, a group table, and a meter table based on a result calculated by the route calculation module 125, a policy such as QoS, a user indication, and the like. Can be.
  • the entry management module 135 may allow an entry of each table to be registered in advance in the switch 20, or may be responsive to a request for adding or updating an entry from the switch 20.
  • the entry management module 135 may change or delete an entry of the entry DB 191 as necessary or by an entry destruction message of the switch 10.
  • the message management module 130 may interpret a message received through the switch communication unit 110 or generate a controller-switch message to be described later transmitted to the switch through the switch communication unit 110.
  • the state change message which is one of the controller-switch messages, may be generated based on an entry generated by the entry management module 135 or an entry stored in the entry DB 191.
  • the switch 20 may be a physical switch or a virtual switch that supports the OpenFlow protocol.
  • the switch 20 may process the received packet to relay the flow between the network devices 30.
  • the switch 20 may be provided with one flow table or multiple flow tables for pipeline processing described in Non-Patent Document 1.
  • the flow table may include a flow entry that defines a rule of how to process the flow of the network device 30.
  • the switch 20 may be divided into a core switch between an ingress switch and an egress switch and an edge switch of a flow according to a combination of multiple switches.
  • the switch 20 includes a port unit 205 for communicating with another switch and / or a network device, a controller communication unit 210 for communicating with the controller 10, a switch control unit 200, and a storage unit ( 290).
  • the port portion 205 may have a plurality of pairs of ports connected to a switch or a network device.
  • the pair of ports may be implemented as one port.
  • the storage unit 290 may store a program for processing and controlling the switch control unit 200.
  • the storage unit 290 may perform a function for temporarily storing input or output data (packets, messages, etc.).
  • the storage unit 290 may include a table 291, such as a flow table, a group table, and a meter table.
  • the table 230 or entries in the table may be added, modified, or deleted based on the message of the controller 10. The table entry can be discarded by itself by the switch 20.
  • Flow tables can be composed of multiple flow tables to handle the pipeline of OpenFlow.
  • a flow entry of a flow table includes match fields describing the conditions (control rules) matching packets, priority, counters updated when there is a match, Instructions, which are a set of various actions that occur when a packet is matched in a flow entry, timeouts describing the time to be discarded from the switch, and an opaque type selected by the controller. And may be used to filter flow statistics, flow changes, and flow deletions, and may include tuples such as cookies that are not used in packet processing.
  • Instructions can alter pipeline processing, such as forwarding packets to another flow table. Instructions can also include a set of actions that add an action to an action set, or a list of actions to apply directly to a packet.
  • An action may mean an operation of modifying a packet such as transmitting a packet to a specific port or decreasing a TTL field.
  • An action may belong to an action bucket associated with a group entry or part of a set of instructions associated with a flow entry.
  • An action set means a set of accumulated actions indicated in each table. An action set can be performed when no table matches. 5 illustrates various packet processing by flow entries.
  • Pipeline means a series of packet processing between packet and flow table.
  • the switch 20 searches for a flow entry matching the packet in the order of high priority of the first flow table. If a match is found, the instruction of the entry is executed. Instructions are executed immediately after a match (apply-action), clear-action (write-action), metadata modification (write-metadata), specified There are goto-tables that move packets with metadata into tables. If there is no flow entry matching the packet, the packet may be dropped or sent to the controller 10 in a packet-in message according to the table setting.
  • the group table may include group entries.
  • the group table may be indicated by the flow entry to suggest additional forwarding methods.
  • a group entry of a group table may include the following fields.
  • a group identifier that identifies the group entry, a group type that specifies a rule as to whether to perform some or all of the action buckets defined in the group entry, a counter of the flow entry Counters for statistics, and action buckets, which are a set of actions associated with parameters defined for a group.
  • the meter table consists of meter entries and defines per-flow meters. Per flow meter can allow openflow to apply various QoS operations.
  • a meter is a kind of switch element that can measure and control the rate of packets.
  • a meter table includes a meter identifier for identifying a meter, meter bands indicating a speed designated in a band and a packet operation method, and a packet. It consists of counter fields that are updated when running on the meter.
  • Meter bands are band types that indicate how packets are processed, the rate used to select the meter band by the meter, and counters that are updated when packets are processed by the meter band. ), And fields such as type specific arguments, which are bad types with optional arguments.
  • the switch controller 200 may typically control the operations of the units to control the overall operation of the switch 20.
  • the switch controller 200 may include a table management module 240, a flow search module 220, a flow processing module 230, and a packet processing module 235 that manage the table 291.
  • Each module may be configured in hardware in the controller 200, or may be configured in software separate from the controller 200.
  • the table management module 240 may add an entry received from the controller 10 through the controller communication unit 210 to an appropriate table or periodically remove an entry timed out.
  • the flow search module 220 may extract flow information from a packet received as user traffic.
  • the flow information includes identification information of an ingress port, which is a packet inflow port of an edge switch, identification information of a packet incoming port of a corresponding switch, packet header information (IP address, MAC address, port of source and destination, And VLAN information, etc.), metadata, and the like.
  • the metadata may be optionally added in the previous table or data added in another switch.
  • the flow search module 220 may search whether there is a flow entry for the received packet in the table 291 with reference to the extracted flow information. When the flow entry is retrieved, the flow retrieval module 220 may request the flow processing module 260 to process the received packet according to the retrieved flow entry. If the flow entry search fails, the flow search module 220 may transmit the received packet or the minimum data of the received packet to the controller 10 through the controller communication unit 210.
  • the flow processing module 230 may process an action such as outputting, dropping, or modifying a specific header field to a specific port or multiple ports according to the procedure described in the entry retrieved by the flow retrieval module 220. have.
  • the flow processing module 230 may execute an instruction to process a pipeline entry of a flow entry or change an action, or execute a set of actions when the flow table can no longer go to the next table.
  • the packet processing module 235 may actually output the packet processed by the flow processing module 230 to one or two or more ports of the port unit 205 designated by the flow processing module 230.
  • the SDN network system may further include an orchestrator 1.
  • the orchestrator 1 may create, change, and delete virtual network devices, virtual switches, and the like.
  • the orchestrator 1 identifies the switch to which the virtual network will connect, the port identification to the switch, the MAC address, the IP address, and the tenant identification.
  • Information of the network device such as information and network identification information can be provided to the controller 10.
  • the controller 10 and the switch 20 communicate with the orchestrator 1 via a separate interface, or the orchestrator 1 through the switch communication unit 110 of the controller 10 and the controller communication unit 210 of the switch 20. ) Can be communicated with.
  • the switch 20 may exchange messages with the orchestrator 1 through the controller 10.
  • the controller 10 and the switch 20 exchange various information, which is called an openflow protocol message.
  • open flow messages include types such as controller-to-switch messages, asynchronous messages, and symmetric messages.
  • Each message may have a transaction id (xid) in the header that identifies the entry.
  • the controller-switch message is a message generated by the controller 10 and transmitted to the switch 20, and is mainly used to manage or check the state of the switch 20.
  • the controller-switch message may be generated by the controller 100 of the controller 10, in particular the message management module 130.
  • Controller-switch messages include features for querying the capabilities of the switch, configurations for querying and setting settings for the configuration parameters of the switch 20, flows / groups / meters in the OpenFlow table.
  • Status change messages include modify flow table messages, modify flow entry messages, modify group entry messages, port modification messages, and meter entry changes. Message (meter modification message).
  • the asynchronous message is a message generated by the switch 20 and used to update the state of the switch, network events, and the like in the controller 10.
  • the asynchronous message may be generated by the control unit 200 of the switch 20, in particular the flow retrieval module 220.
  • Asynchronous messages include packet-in messages, flow-removed messages, and error messages.
  • the packet-in message is used by the switch 20 to send a packet to the controller 10 to take control of the packet.
  • the packet-in message includes all or part of a received packet or copy thereof sent from the openflow switch 20 to the controller 10 to request a data path when the switch 20 receives an unknown packet. Is a message.
  • Packet-in messages are also used when the action of an entry associated with an incoming packet is destined to be sent to the controller.
  • the deleted flow-removed message is used to convey to the controller 10 the flow entry information to be deleted in the flow table. This message occurs in the flow expiry process where the controller 10 has requested the switch 20 to delete the corresponding flow entry or because of a flow timeout.
  • Symmetric messages are generated by both the controller 10 and the switch 20, and are transmitted without the request of the other party.
  • Hello used to initiate a connection between the controller and the switch, an echo to ensure that there is no problem with the connection between the controller and the switch, and an error message used by the controller or switch to notify the other side of the problem (error message) and the like.
  • Error messages are mostly used in switches to indicate failures in response to requests initiated by the controller.
  • FIG. 6 is a structural diagram of a multi-tenant support network system according to an embodiment of the present invention
  • FIG. 7 is a block diagram of components of the network system of FIG. Detailed descriptions of the same or similar components refer to FIGS. 1 to 5.
  • the network system may include a plurality of switches SW1 to 5, a controller 10, a legacy container app 300, and a plurality of legacy containers 400.
  • At least some of the plurality of switches SW1-SW5 may be a physical switch or a virtual switch that supports the OpenFlow protocol as a switch based on a software defined network (SDN).
  • the plurality of switches SW1-SW5 may be configured by mixing an open flow switch and a legacy legacy switch.
  • the edge switch is preferably an open flow switch.
  • the switches SW1-SW5 may be connected to each other.
  • the edge switch of the plurality of switches SW1-SW5 may be connected to network devices through respective ports p21, p22, p31, p32, p41, and p42, or may be connected to an external network (legacy router, gateway, etc.). .
  • the controller 10 may control a plurality of switches based on SDN (Software Defined Network).
  • SDN Software Defined Network
  • the controller controller 100 of the controller 10 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. ) May be included.
  • Each module may be configured in hardware in the controller 100, or may be configured in software separate from the controller 100. Description of elements of the same reference numerals is made with reference to FIG. 2.
  • the functions of the topology management module 120 and the path calculation module 125 are the same as those described with reference to FIGS. 1 to 5.
  • the topology management module 120 may obtain connection information with the legacy switch through the open flow switch.
  • the legacy interface module 145 may communicate with the legacy container app 300.
  • the legacy interface module 145 may transmit topology information of the switch group established 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, respectively. It may include the connection or connection information of or of each other.
  • the legacy interface module 145 may be able to interpret incoming packets received through any one of the plurality of switches SW1-SW5 when it is impossible to interpret, when routing is impossible, and when it is specified by policy.
  • the incoming packet may be delivered to the legacy container app 300.
  • non-interpretable or non-routable packets include incoming packets that are configured with legacy protocols and cannot be interpreted, or when route calculation module 125 is unable to route received packets due to connectivity with legacy networks.
  • SW1-SW5 When the incoming packet needs to be transmitted to the app 300 according to the policy, when a network connected to a plurality of switches (SW1-SW5) must be configured as a multi-tenant, or configured as a plurality of virtual routers in order to flexibly operate the network. If you have to. This may be triggered by a virtual router creation request message generated by an administrator or user's control or request.
  • the legacy container app 300 may receive the virtual router creation request message through the openflow switch or the orchestrator 1. Multi-tenant and multiple virtual routers will be described later.
  • the legacy interface module 145 may transmit the flow to the legacy container app 300.
  • the flow preferably includes packets received by the OpenFlow switch and port information of the switch that received the packet.
  • the legacy interface module 145 may convert the routing path information generated in the legacy container 400 to be described later into an OpenFlow protocol.
  • the legacy container app 300 may include a packet processor 310, a topology module 320, an SDN interface module 340, and a container generator 350.
  • the legacy container app 300 may be driven on a separate device or driven by the controller 10.
  • the SDN interface module 340 may communicate with the controller controller 100.
  • Each of the legacy interface module 140 of the controller controller 100 and the SDN interface module 340 of the legacy container app 300 may serve as an interface between the controller controller 100 and the legacy routing container 300.
  • the legacy interface module 140 and the SDN interface module 340 may communicate in a specific protocol or a specific language.
  • Both or both of the legacy interface module 140 and the SDN interface module 340 may translate or interpret messages exchanged between the controller 10 and the legacy routing container 300. For example, you can convert legacy protocol messages into Openflow protocol messages.
  • the topology module 320 may store network information such as topology information related to the plurality of switches SW1-SW5 received from the controller controller 100.
  • the topology module 320 may generate a network topology for a plurality of virtual routers or multi-tenants to be created by policy.
  • Information for generation such as a multi-tenant such as a network topology for a plurality of virtual routers or multi-tenants (hereinafter referred to as 'multi-tenant') of the topology module 320 is not only generated by a policy but also by a user request or administrator. Can be generated by the control of.
  • Multiple virtual routers enable elastic adjustment of the capacity of the network. If you need to provide a cloud environment, such as a data center, network capacity scaling can be easy.
  • a plurality of virtual routers may support the virtual routers according to the users, and may facilitate the charging policy according to the usage of the users.
  • resources of each tenant may support multi-tenancy such that independence is ensured and is not shared with other tenants.
  • Generation information such as multi-tenant (hereinafter referred to as 'creation information') includes the number and type of network devices to be connected to the virtual router in addition to the network topology, location and network information, group policy of users, network resources or computing to be granted to the virtual router to be created. It may include 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 an administrator's designation or a user's request in addition to the basic policy. Part of the creation information may be included in the above-mentioned virtual router creation message.
  • the container generator 350 may generate and / or manage the legacy container 400 having a routing function based on the generation information of the topology module 320.
  • the container generator 350 receives the virtual router creation message from the controller controller 100, the container generator 350 prepares to generate the legacy container 400.
  • the container generator 350 may allocate computing resources to the legacy container 400 to be generated based on the network or computing resource allocation policy of the generated information, and generate the legacy container 400.
  • various virtualization technologies may be used as a technology for creating the legacy container 400.
  • the container generator 350 may transmit or designate network information required for the legacy container 400 to the legacy container 400 through the packet processor 310. Necessary network information can be extracted from the generated information.
  • the container generator 350 may designate a namespace identifier that may be distinguished from other legacy containers or may be identified by the legacy container 400.
  • the container generator 350 may generate a plurality of legacy containers 401, 402, and 403.
  • the container generator 350 may generate a plurality of legacy containers based on slicing identifiers, which are specific information based on packets introduced into the plurality of switches SW1-SW5.
  • Specific information based on an incoming packet includes incoming port information of an open flow edge switch to which an incoming packet is introduced, and tag information such as vLAN or vxLAN of an incoming packet. That is, the slicing identifier may include an incoming port, vLAN, vxLAN information, etc. of the incoming packet.
  • the tag information of the incoming packet may be specified at the source device of the packet or at the openflow switch or controller 10.
  • the slicing identifier may include tag information such as a tunnel ID added to the packet.
  • the slicing identifier can be associated with a namespace identifier.
  • the slicing identifier and the namespace identifier may correspond to each other.
  • the plurality of legacy containers 401, 402, 403 may form an isolated network from each other.
  • the network system according to the present invention may support multi-tenant.
  • each tenant may correspond to a slicing identifier or a namespace identifier, respectively.
  • the namespace identifier can be specified to be identical to the loopback address of the virtual router functioning in the legacy container, or tag information such as vLAN and vxLAN information.
  • the namespace identifier can be any value or the loopback address of the virtual router.
  • the packet processor 310 serves as an interface with the legacy container 400.
  • the packet processing unit 310 receives the incoming packet from the plurality of legacy containers 401. , 402, 403 may determine which legacy container to deliver.
  • the packet processor 310 may extract the slicing identifier from the incoming packet, and deliver the incoming packet to the legacy container having a namespace identifier associated with the slicing identifier among the plurality of legacy containers 401, 402, and 403.
  • the packet processor 310 may associate one namespace identifier or a combination of multiple values with one namespace identifier in pairs and store the pair as an association list.
  • the packet processor 310 may receive routing information to be described later from the legacy container 400 and transmit the routing information to the SDN interface module 340.
  • the legacy container 400 may include a namespace unit 440, a routing processor 430, and a routing information storage unit 450.
  • the namespace unit 440 sets a network environment of the legacy container when the legacy container is generated by the controller generation unit 350.
  • the network environment of a legacy container includes a network interface or a port interface of a virtual router to function as a legacy container. That is, the namespace unit 440 may build a network environment that is an interface with the outside.
  • the namespace unit 440 may use Linux's namespace technology.
  • the namespace generator 440 may generate the legacy container according to the instruction of the controller generator 350.
  • the namespace unit 440 serves as an interface with the legacy container app 300.
  • the namespace unit 440 may set a network environment of the legacy container using the network information received from the legacy container app 300.
  • the namespace unit 440 may set up an independent network environment separate from the network with other legacy containers.
  • the namespace unit 440 may enable the legacy container to function as a virtual router using network information received from the legacy container app 300.
  • the namespace unit 440 may receive the network environment of the virtual router necessary for the routing function, that is, information of network nodes or topology information of the nodes from the legacy container app 300 and store it in the routing information storage unit 450. have.
  • the network nodes may include information of switches to which a virtual routing function is to be involved among the plurality of switches SW1-SW5, 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 unit 450.
  • the routing table may be updated or modified by the routing processor 430.
  • the routing processor 430 may exchange messages with the outside using a legacy protocol.
  • the generated table may be stored in the routing information storage unit 450.
  • the routing information storage unit 450 may store a namespace identifier.
  • the namespace unit 440 may determine whether to drop the incoming packet received through the legacy container app 300 using the namespace identifier.
  • the routing information storage unit 450 stores the interface of the virtual router provided by the legacy container, so that the routing information storage unit 450 virtually switches the switch group including the switches of some of the switches SW1-SW5. It can be seen as a router.
  • the interface of the virtual router stored in the routing information storage unit 450 may vary.
  • FIGS. 8 is a block diagram of a legacy container according to another embodiment of the present invention. See FIGS. 1 to 5.
  • the legacy container may include a namespace unit 440, a routing processor 430, a routing information storage unit 450, and a DHCP virtual server 460. Description of the same components is made with reference to FIG. 7.
  • the DHCP virtual server 460 may generate an IP address to be used by the requested network device. That is, when there is an IP address request from the network device, the DHCP virtual server 460 may send an IP address to the requested network device.
  • the DHCP virtual server 460 may allow legacy containers to enable DHCP server functionality.
  • the legacy container app 300 may allocate networking resources and / or computing resources for the legacy container to be generated. (S520).
  • the legacy container app 300 may generate a legacy container using the allocated resources (S530). Thereafter, the legacy container app 300 may transfer or / or designate network information such as a namespace identifier and a network interface necessary for a virtual routing function, and network topology information to the generated legacy container 400 (S540).
  • network information such as a namespace identifier and a network interface necessary for a virtual routing function, and network topology information to the generated legacy container 400 (S540).
  • the generation of the legacy container generates the namespace unit 440 in the container generator 350 of the legacy container app 300, and generates the remaining overall portion of the legacy container in the namespace unit 440. You may.
  • the namespace unit 440 constructs a virtual router so that the legacy container functions as a virtual router by using the network information received from the legacy container app 300, and routes the interface and network topology information of the virtual router to the routing information storage unit. Can be stored at 450.
  • the routing processor 430 may create a routing table or a forwarding table for the virtual router to perform a routing function by using the information stored in the routing information storage unit 450. As a result, the legacy container 400 is ready to provide a routing function (S550).
  • FIG. 10 is a flowchart illustrating a method for preparing a routing function of FIG. 9, and FIG. 11 is a structural diagram illustrating various interfaces of a virtual router. See FIGS. 1 to 9.
  • the namespace unit 440 may designate an interface of a virtual router and connect the interface of network nodes including network devices to each interface (S560).
  • the namespace unit 440 may designate a switch group to be used for the corresponding virtual routing among the plurality of switches SW1-SW5, and allow the interfaces of the switches belonging to the switch group and the interface of the virtual router to be mapped (S570).
  • FIG. 11 a virtual router having various interfaces can be seen.
  • an interface of a virtual router may be constructed such that some of the ports of an edge switch among the switches SW1-SW5 and a port of the first virtual router v-R1 correspond to each other.
  • the slicing identifiers 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 the list of slicing identifier values.
  • an interface of a virtual router may be constructed such that ports of some edge switches of the plurality of switches SW1-SW5 correspond to ports of the second virtual router v-R2.
  • the interface of the virtual router may be set to correspond to the vLAN or vxLAN value of the packet. If you create a virtual router with only physical ports (physical ports) on the edge switch, you are limited by the number of physical ports. However, this restriction is eliminated when associating packet identification information (vLAN or vxLAN). It can also behave similarly to the flow of legacy packets in legacy networks. You can also run a virtual legacy router for each user or group of users. The user or user group may be divided into packet identification information such as vLAN, vxLAN or tunnel ID.
  • FIG. 12 is a diagram illustrating a network structure according to another embodiment of the present invention
  • FIG. 13 is a diagram illustrating a virtual router according to FIG. 12. See FIGS. 1 through 11.
  • the network supports multi-tenancy, and network devices (VMs) belong to each of the multi-tenants.
  • VMs network devices
  • 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 the ports p23n and p24n.
  • a policy is established to be connected to the twenty-third and twenty-fourth switches SW23 and SW24.
  • first and second legacy containers may be created to provide two independent virtual router functions.
  • the slicing identifier is preferably specified by the vLAN value. That is, the first tenant may have a value of vLAN of 101 and the second tenant may have a vLAN of 102.
  • the namespace identifier nsID may be designated equal to each of the vLAN values.
  • the port interface of the virtual router and the port interface of the edge switches may correspond to 1: 1, or may be associated in various combinations.
  • FIG. 14 is a flowchart illustrating a method of determining legacy routing for a flow of the controller of FIG. 6. Reference is made to FIGS. 6 to 11.
  • the legacy routing determination method for the flow means whether the controller 10 should perform general SDN control on the flow received from the open flow switch or should inquire the legacy routing container 300 for flow control.
  • the controller 10 may receive a packet of a network device as a flow through the openflow switch (S610).
  • the controller 10 determines whether the incoming packet of the flow can be interpreted (S620). If the incoming packet cannot be interpreted, the controller 10 may transfer the flow to the legacy routing container app 300 (S650). This is because, in case of a protocol message that a packet uses only in a legacy network, the SDN-based general controller cannot interpret the packet.
  • the SDN-based controller 10 may not calculate the routing path of the incoming legacy packet. Therefore, when the controller 10 cannot calculate a route, such as legacy packets, the controller 10 may forward the legacy packets to the legacy routing container app 300.
  • the legacy routing path for the legacy packet may be calculated by the routing processor 430 of the legacy container 400. However, knowing the edge port to be leaked of the legacy packet and the final processing method of the legacy packet, the controller 10 can process the legacy packet through the flow modification.
  • the controller 10 searches for the flow path, such as whether the path of the flow can be calculated or if there is an entry in the entry table (S630). If the route cannot be retrieved, the controller 10 transfers the flow to the legacy routing container app 300 (S650). If the path can be retrieved, the controller 10 may generate a packet-out message specifying the output of the packet and transmit the packet-out message to the packet-inquired openflow switch (S640).
  • FIG. 15 is a flowchart of a processing method for an incoming packet in a legacy container
  • FIG. 16 is a flowchart of an example other than the routing process of FIG. 15.
  • the legacy container app 300 may analyze an incoming packet of a flow received through the controller 10 and extract a slicing identifier of the incoming packet (S810).
  • the legacy container app 300 may determine whether a namespace ns identifier set associated with the extracted slicing identifier is in the association list of identifiers (S820).
  • the legacy container app 300 may cause the incoming packet to be dropped (S900).
  • the legacy container app 300 may transfer the flow to the legacy container 400 to which the namespace identifier associated with the slicing identifier is assigned (S830).
  • the routing processor 430 of the legacy container 400 may analyze the incoming packet of the received flow to determine whether the corresponding packet is a routing request message (S840).
  • the legacy container 400 may determine whether there is routing information for the destination IP address of the incoming packet (S850).
  • the routing processor 430 may cause the incoming packet to be dropped (S890).
  • the routing processor 430 may generate a routing path and transmit the generated routing path to the legacy container app 300 (S860).
  • the routing path may be converted into an open flow protocol in any one of the legacy interface module 140 of the controller controller 100 or the SDN interface module 340 of the legacy container app 300 (S870).
  • the legacy interface module 140 may create, modify, or delete a flow entry for flow in the openflow switches based on the routing path, and cause the entry table of the associated openflow switch to be updated.
  • the legacy container 400 may process the request (S880). See FIG. 16 for details.
  • an incoming packet is a DHCP protocol in which a network device is started and requests an IP address, not a routing request process.
  • the routing processor 430 of the legacy container 400 may analyze the contents of the incoming packet and may recognize that the incoming packet is an IP address request message (S910).
  • the routing processor 430 transmits the incoming packet to the DHCP virtual server 460 (S820).
  • the DHCP virtual server 460 may generate the IP address information and the subnet mask information in consideration of the network environment of the network device that sent the incoming packet, for example, which user group or which tenant, in step S930.
  • the generated IP address information and the subnet mask information are transferred to the sending network device through the legacy container app 300, the controller 10, and the open flow switch (S940).
  • the message exchanged between the network device and the DHCP virtual server 460 may be a general DHCP protocol message (DHCP Discover, DHCP offer, DHCP request, DHCP ack).
  • the present invention may be implemented in hardware or software.
  • the invention may also be embodied as computer readable code on a computer readable recording medium.
  • the computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like, which are also implemented in the form of carrier waves (for example, transmission over the Internet). Include.
  • the computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. And functional programs, codes and code segments for implementing the present invention can be easily inferred by programmers in the art to which the present invention belongs.
  • Embodiments of the present invention may include a carrier wave having electronically readable control signals that may be operated with a programmable computer system on which one of the methods described herein is executed.
  • Embodiments of the present invention may be implemented as a computer program product having a program code, the program code being operated to execute one of the methods when the computer program is run on a computer.
  • the program code may for example be stored on a machine readable carrier.
  • One embodiment of the invention may be a computer program having program code for executing one of the methods described herein when the computer program is run on a computer.
  • the invention may include a computer, or a programmable logic device, for performing one of the methods described above. Programmable logic devices (eg, field programmable gate arrays, complementary metal oxide semiconductor based logic circuits) may be used to perform some or all of the functions described above.
  • controller 20 SDN switch
  • topology management module 125 path calculation module

Abstract

본 발명은 SDN(Software Defined Network) 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템에 관한 것으로, 복수의 가상 라우터를 이용하여 탄력적인 네트워크 운용이 가능하고, 복수의 라우터를 통해 멀티 테넌시를 지원하며, 멀티 테넌트를 지원하는 방법 및 그 시스템에 관한 것이다. 본 시스템은 SDN 기반의 복수의 스위치를 제어하는 제어기; 상기 복수의 스위치 중 적어도 일부의 스위치를 포함하는 스위치 군을 가상 라우터로 취급하여, 상기 스위치 군 중 어느 한 스위치에 인입되는 패킷에 대한 라우팅 정보를 생성하는 레거시 컨테이너; 및 가상 라우터 생성 요청 메시지를 수신하면, 컴퓨팅 자원을 할당하여 상기 레거시 컨테이너를 가상화 기술을 이용하여 생성하는 레거시 컨테이너 앱을 포함하고, 상기 레거시 컨테이너 앱은 상기 복수의 스위치로 인입하는 패킷에 기반한 특정 정보인 슬라이싱 식별자를 기초로 레거시 컨테이너를 복수개 생성할 수 있다.

Description

SDN 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템
본 발명은 SDN(Software Defined Network) 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템에 관한 것으로, 복수의 가상 라우터를 이용하여 탄력적인 네트워크 운용이 가능하고, 복수의 라우터를 통해 멀티 테넌시를 지원하며, 멀티 테넌트를 지원하는 방법 및 그 시스템에 관한 것이다.
휴대 장치 및 서버 가상화의 폭발적인 증가와 클라우드 서비스의 출현으로, 네트워크 수요가 늘어났다. SDN(Software-Defined Network)은 네트워크 관리자가 낮은 레벨 기능의 추상화를 통해 네트워크 서비스를 관리할 수 있는 컴퓨터 네트워킹에의 접근이다. 이는 선택된 목적지로 트래픽을 포워딩하는 근본적인 시스템(데이터 평면; data plane)으로부터 트래픽이 어디로 전송될 것인지에 대한 결정을 하는 시스템(제어 평면; control plane)을 분리함으로써 달성할 수 있다.
오픈 플로우는 고속 데이터 평면과 높은 레벨의 라우팅 결정 기능들을 분리하는 메커니즘 중 하나이다. 패킷 포워딩 플레인은 여전히 스위치 단에 관여되며, 반면 고수준 라우팅 결정은 분리된 컨트롤러에서 관여되며, 이들은 오픈 플로우 프로토콜을 통해 통신한다.
그러나 기존 네트워크에서 SDN으로의 전환 과도기로서, 기존 레거시 프로토콜 및 장치를 SDN에 끊임 없이 연결하는 인터페이스를 정의할 필요가 있다. 이러한 하이브리드 SDN 네트워크를 구성하는 장비는 컴퓨팅 자원이나 네트워킹 자원 소모가 적으며, 단순한 구조와 운영이 필요하다.
기존의 가상 라우터의 경우 제어 평면과 데이터 평면이 공존하고, 기존 라우터를 가상 머신 형태로 옮긴 경우가 많다. 이는 가상화 기술에 의존적일 수 밖에 없고, 기존 하드웨어 라우터에 비해 성능이 낮을 수 밖에 없다. 또한 기존 라우터의 경우 라우터 마다 개별 관리를 해야 하고, 네트워크의 요구 변화에 능동적으로 대응하지 못하였다.
기존 클라우드 환경에서 DHCP 핸들링을 통한 네트워크 관리는 클라우드 컨트롤 노드에서 이루어진다. 클라우드 환경을 SDN 네트워크 기반에서 운용하는 경우, 기존 SDN 네트워크를 관리하는 SDN 제어기의 정보와 클라우드 내부 네트워크를 관리하는 DHCP 정보의 분산이 이러나 관리에 어려움이 있다.
<선행기술문헌>
비특허문헌 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]
본 발명의 목적은 SDN 네트워크에서 레거시 네트워크를 지원할 수 있도록 하며, 데이터 센터와 같이 다양한 사용자에게 클라우드 환경을 제공하고, 사용자의 사용량에 따라 과금할 수 있도록 하며, 탄력적인 네트워크 운용이 가능하도록 하고, 사용자의 서비스 품질을 보장하면서 손쉬운 네트워크 관리가 가능한 SDN 기반의 멀티 테넌트 지원 네트워크 시스템을 제공하는 데 있다.
또한 클라우드 컨트롤 노드에서 관리하던 DHCP 서버를 SDN 제어기가 직접 관리하는 IP 주소 제공 방법을 제공하는 데 본 발명의 다른 목적이 있다.
본 발명의 일실시예에 따른 SDN 기반의 멀티 테넌트 지원 네트워크 시스템은, SDN(Software Defined Network) 기반의 복수의 스위치를 제어하는 제어기; 상기 복수의 스위치 중 적어도 일부의 스위치를 포함하는 스위치 군을 가상 라우터로 취급하여, 상기 스위치 군 중 어느 한 스위치에 인입되는 패킷에 대한 라우팅 정보를 생성하는 레거시 컨테이너; 및 가상 라우터 생성 요청 메시지를 수신하면, 컴퓨팅 자원을 할당하여 상기 레거시 컨테이너를 가상화 기술을 이용하여 생성하는 레거시 컨테이너 앱을 포함하고, 상기 레거시 컨테이너 앱은 상기 복수의 스위치로 인입하는 패킷에 기반한 특정 정보인 슬라이싱 식별자를 기초로 레거시 컨테이너를 복수개 생성할 수 있다.
본 발명의 일실시예에 따른 SDN 기반의 멀티 테넌트 지원 방법은, SDN(Software Defined Network) 기반의 복수의 스위치를 제어하는 제어기; 가상 라우팅 기능을 제공하는 레거시 컨테이너; 및 상기 레거시 컨테이너를 생성하는 레거시 컨테이너 앱을 구비하는 네트워크 시스템의 멀티 테넌트 지원 방법으로서, 상기 레거시 컨테이너 앱에서, 라우팅 요청 메시지를 수신하는 단계; 상기 앱에서 컴퓨팅 자원을 할당하여 상기 레거시 컨테이너를 생성하는 단계; 상기 앱에서 상기 컨테이너에 네임 스페이스 식별자를 구비하는 네트워크 정보를 지정하는 단계; 및 상기 컨테이너에서, 상기 네트워크 정보를 이용하여 가상 라우팅 기능을 준비하는 단계를 포함하고, 상기 네임 스페이스 식별자는 상기 복수의 스위치에 연결된 복수의 테넌트(tenant) 중 어느 한 테넌트에 대응할 수 있다.
본 발명에 따르면, SDN 네트워크에서 레거시 네트워크를 지원할 수 있으며, 다수의 가상 라우터를 제공할 수 있으며, 다수의 가상 라우터를 SDN 제어기에서 일괄 관리할 수 있도록 할 수 있다. 이에 따라 다양한 사용자 별로 라우팅 기능을 제공할 수 있으며, 멀티 테넌시 기능을 제공할 수도 있다. 또한 관리의 복잡성을 줄일 수 있다.
도 1은 본 발명의 일실시예에 따른 SDN 네트워크 시스템의 구조도,
도 2는 도 1의 네트워크 시스템의 제어기의 블록 구성도(block diagram),
도 3은 도 1의 네트워크 시스템의 스위치의 블록 구성도,
도 4는 플로우 엔트리의 필드 테이블 및 플로우 엔트리에 따른 동작 종류를 나타내는 동작 테이블,
도 5는 그룹 및 미터 테이블의 필드 테이블,
도 6은 본 발명의 일 실시예에 따른 멀티 테넌트 지원 네트워크 시스템에 대한 구조도,
도 7은 도 6의 네트워크 시스템의 구성요소에 대한 블록 구성도,
도 8은 본 발명의 다른 실시예에 따른 레거시 컨테이너의 블록 구성도,
도 9는 레거시 컨테이너 생성 방법에 대한 순서도,
도 10은 도 9의 라우팅 기능 준비 방법을 구체화한 순서도,
도 11은 가상 라우터의 다양한 인터페이스를 도시한 구조도,
도 12는 본 발명의 다른 실시예에 따른 네트워크 구조도,
도 13은 도 12에 따른 가상 라우터의 구조도,
도 14는 도 6의 제어기의 플로우에 대한 레거시 라우팅 여부 판단 방법에 대한 순서도,
도 15는 레거시 컨테이너에서 인입 패킷에 대한 처리 방법의 순서도, 및
도 16은 도 15의 라우팅 처리가 아닌 일례에 대한 순서도이다.
이하, 도면을 참조하여 본 발명을 보다 상세하게 설명한다.
제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다. 또한 네트워크 상의 제1 구성요소와 제2 구성요소가 연결되어 있거나 접속되어 있다는 것은, 유선 또는 무선으로 제1 구성요소와 제2 구성요소 사이에 데이터를 주고 받을 수 있음을 의미한다.
또한, 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 단순히 본 명세서 작성의 용이함만이 고려되어 부여되는 것으로서, 그 자체로 특별히 중요한 의미 또는 역할을 부여하는 것은 아니다. 따라서, 상기 "모듈" 및 "부"는 서로 혼용되어 사용될 수도 있다.
이와 같은 구성요소들은 실제 응용에서 구현될 때 필요에 따라 2 이상의 구성요소가 하나의 구성요소로 합쳐지거나, 혹은 하나의 구성요소가 2 이상의 구성요소로 세분되어 구성될 수 있다. 도면 전체를 통하여 동일하거나 유사한 구성요소에 대해서는 동일한 도면 부호를 부여하였고, 동일한 도면 부호를 가지는 구성요소에 대한 자세한 설명은 전술한 구성요소에 대한 설명으로 대체되어 생략될 수 있다.
SDN은 패킷을 전달하는 데이터 플레인과 패킷의 흐름을 제어하는 제어 플레을 분리된 개념이다. SDN에서 패킷이 발생했을 때, 네트워크 장비는 패킷을 어디로 전달할지 SDN 제어 소프트웨어(제어기)에게 물어보고, 그 결과를 반영하여 패킷을 전송하는 경로와 방식을 결정한다. SDN은 이론적인 개념으로, 실제로 적용하기 위해 오픈플로우(Openflow)가 등장하였다. 즉 오픈플로우는 SDN을 구현하기 위해 제정된 표준 인터페이스이다. 오픈플로우는 오픈플로우 제어기와 오픈플로우 스위치로 구성되어, 플로우 정보를 제어하여 패킷의 전달 경로 및 방식을 결정한다. 본 명세서 전반에서, 오픈플로우와 SDN는 서로 동일한 의미로 사용되거나 혼용하여 사용될 수 있다.
플로우(flow)는 하나의 스위치 관점에서 적어도 하나의 헤더 필드의 값을 공유하는 일련의 패킷들 또는 다중 스위치의 여러 플로우 엔트리(flow entry)들의 조합에 따른 특정 경로의 패킷 흐름을 의미할 수 있다. 오픈플로우 네트워크는 플로우 단위로 경로 제어, 장애 회복, 부하 분산 및 최적화를 행할 수 있다. 본 명세서에서 플로우는 특정 패킷을 의미할 수 있으며, 특정 패킷과 인입 포트 등 다른 메타데이터를 포함하는 것을 의미할 수도 있다.
도 1은 본 발명의 일실시예에 따른 SDN 네트워크 시스템의 블록 구성도(block diagram), 도 2는 도 1의 네트워크 시스템의 제어기의 블록 구성도, 도 3은 도 1의 네트워크 시스템의 스위치의 블록 구성도, 도 4는 플로우 엔트리의 필드 테이블 및 플로우 엔트리에 따른 동작 종류를 나타내는 동작 테이블, 도 5는 그룹 및 미터 테이블의 필드 테이블이다.
도 1(a)를 참조하면, 본 발명에 일 실시예에 따른 SDN 네트워크 시스템은 제어기(contoller)(10), 복수의 스위치(20) 및 복수의 네트워크 디바이스(30)를 포함할 수 있다.
네트워크 디바이스(30)는 데이터나 정보를 주고 받고자 하는 사용자 단말 장치, 또는 특정 기능을 수행하는 물리 장치 또는 가상 장치를 포함할 수 있다. 하드웨어 관점에서, 네트워크 디바이스(30)는 PC, 클라이언트 단말기, 서버, 워크스테이션, 수퍼컴퓨터, 이동통신 단말기, 스마트폰, 스마트패드 등이 있을 수 있다. 또한 네트워크 디바이스(30)는 물리 장치 상에 생성된 가상 머신(VM)일 수 있다.
네트워크 디바이스(30)는 네트워크 상의 여러가지 기능을 수행하는 네트워크 기능(network function)으로 지칭될 수 있다. 네트워크 기능은 안티(anti) DDoS, 침입 감지/차단(IDS/IPS), 통합 보안 서비스, 가상 사설망 서비스, 안티 바이러스, 안티 스팸, 보안 서비스, 접근관리 서비스, 방화벽, 로드 밸런싱, QoS, 비디오 최적화 등을 포함할 수 있다. 이러한 네트워크 기능은 가상화될 수 있다.
가상화된 네트워크 기능으로 ETSI(유럽전기통신표준협회)에서 발행한 NFV 관련 백서(비특허문헌 3 참조)에서 정의된 네트워크 기능 가상화(Network Function Virtualiztion; NFV)가 있다. 본 명세서에서 네트워크 기능(NF)은 네트워크 기능 가상화(NFV)와 혼용하여 사용될 수 있다. NFV는 테넌트(tenant)별 필요한 L4-7 서비스 연결을 동적으로 생성하여 필요한 네트워크 기능을 제공하거나, DDoS 공격의 경우 정책 기반으로 필요한 방화벽, IPS 및 DPI 기능 등을 일련의 서비스 체이닝으로 빠르게 제공되는데 이용될 수 있다. 또한 NFV는 방화벽이나 IDS/IPS를 쉽게 온오프 할 수 있으며, 자동으로 프로비저닝(provisioning)할 수 있다. NFV는 오버 프로비저닝의 필요성도 줄일 수 있다.
제어기(controller)(10)는 SDN 시스템을 제어하는 일종의 지휘 컴퓨터로서, 다양하고 복잡한 기능들, 예를 들어, 라우팅, 정책 선언, 및 보안 체크 등을 할 수 있다. 제어기(10)는 하위 계층의 복수의 스위치(20)에서 발생하는 패킷의 플로우를 정의할 수 있다. 제어기(10)는 네트워크 정책 상 허용되는 플로우에 대해 네트워크 토폴로지 등을 참조하여 플로우가 경유할 경로(데이터 경로)를 계산한 후, 경로 상의 스위치에 상기 플로우의 엔트리가 설정되도록 할 수 있다. 제어기(10)는 특정 프로토콜, 예를 들어, 오픈플로우 프로토콜을 이용하여 스위치(20)와 통신할 수 있다. 제어기(10)와 스위치(20)의 통신 채널은 SSL에 의해 암호화 될 수 있다.
도 2를 참조하면, 제어기(10)는 스위치(20)와 통신하는 스위치 통신부(110), 제어부(100), 및 저장부(190)를 포함할 수 있다.
저장부(190)는 제어부(100)의 처리 및 제어를 위한 프로그램을 저장할 수 있다. 저장부(190)는 입력되거나 출력되는 데이터들(패킷, 메시지 등)을 임시 저장을 위한 기능을 수행할 수 있다. 저장부(190)는 플로우 엔트리를 저장하는 엔트리 데이터베이스(DB)(191)를 포함할 수 있다.
제어부(100)는 통상적으로 상기 각 부의 동작을 제어하여 제어기(10)의 전반적인 동작을 제어할 수 있다. 제어부(100)는 토폴로지 관리 모듈(120), 경로 계산 모듈(125), 엔트리 관리 모듈(135) 및 메시지 관리 모듈(130)을 포함할 수 있다. 각 모듈은 제어부(100) 내에 하드웨어로 구성될 수 있고, 제어부(100)와 별개의 소프트웨어로 구성될 수도 있다.
토폴로지 관리 모듈(120)은 스위치 통신부(110)를 통하여 수집된 스위치(20)의 접속 관계를 기초로 네트워크 토폴로지 정보를 구축 및 관리 할 수 있다. 네트워크 토폴로지 정보는 스위치들 사이의 토폴로지 및 각 스위치에 연결되어 있는 네트워크 디바이스들의 토폴로지를 포함할 수 있다. 토폴로지 정보는 저장부(190)에 저장될 수 있다.
경로 계산 모듈(125)은 토폴로지 관리 모듈(120)에서 구축된 네트워크 토폴로지 정보를 기초로 스위치 통신부(110)를 통해 수신한 패킷의 데이터 경로 및 상기 데이터 경로 상의 스위치에서 실행될 액션 열을 구할 수 있다.
엔트리 관리 모듈(135)는 경로 계산 모듈(125)에서 계산된 결과, QoS 등의 정책, 사용자 지시 등을 기초로 플로우 테이블, 그룹 테이블, 및 미터 테이블 등의 엔트리로서 엔트리 DB(191)에 등록할 수 있다. 엔트리 관리 모듈(135)은 스위치(20)에 미리 각 테이블의 엔트리가 등록되도록 하거나(proactive), 스위치(20)로부터의 엔트리의 추가 또는 갱신 요구에 응답(reactive)할 수 있다. 엔트리 관리 모듈(135)은 필요에 따라 또는 스위치(10)의 엔트리 소멸 메시지 등에 의해 엔트리 DB(191)의 엔트리를 변경하거나 삭제할 수 있다.
메시지 관리 모듈(130)은 스위치 통신부(110)를 통해 수신한 메시지를 해석하거나, 스위치 통신부(110)를 통해 스위치로 전송되는 후술할 제어기-스위치 메시지를 생성할 수 있다. 제어기-스위치 메시지 중 하나인 상태 변경 메시지는 엔트리 관리 모듈(135)에 의해 생성된 엔트리 또는 엔트리 DB(191)에 저장된 엔트리에 기초하여 생성될 수 있다.
스위치(20)는 오픈플로우 프로토콜을 지원하는 물리적인 스위치 또는 가상 스위치일 수 있다. 스위치(20)는 수신한 패킷을 처리하여, 네트워크 디바이스(30) 사이의 플로우를 중계할 수 있다. 이를 위해 스위치(20)는 하나의 플로우 테이블 또는 비특허문헌 1에 상술되어 있는 파이프라인(pipeline) 처리를 위해 다중 플로우 테이블을 구비할 수 있다.
플로우 테이블은 네트워크 디바이스(30)의 플로우를 어떻게 처리할 지의 규칙을 정의한 플로우 엔트리를 포함할 수 있다.
스위치(20)는 다중 스위치의 조합에 따른 플로우의 입구 및 출구 측 에지 스위치(edge switch)(ingress switch and egress switch)와 에지 스위치 사이의 코어 스위치(core switch)로 구분될 수 있다.
도 3을 참조하면, 스위치(20)는 다른 스위치 및/또는 네트워크 디바이스와 통신하는 포트부(205), 제어기(10)와 통신하는 제어기 통신부(210), 스위치 제어부(200), 및 저장부(290)를 포함할 수 있다.
포트부(205)는 스위치 또는 네트워크 디바이스와 연결된 한 쌍의 포트를 다수 구비할 수 있다. 한 쌍의 포트는 하나의 포트로 구현될 수 있다.
저장부(290)는 스위치 제어부(200)의 처리 및 제어를 위한 프로그램을 저장할 수 있다. 저장부(290)는 입력되거나 출력되는 데이터들(패킷, 메시지 등)을 임시 저장을 위한 기능을 수행할 수 있다. 저장부(290)는 플로우 테이블, 그룹 테이블, 및 미터 테이블 등의 테이블(291)을 구비할 수 있다. 테이블(230) 또는 테이블의 엔트리는 제어기(10)의 메시지에 기초하여 추가, 수정, 삭제될 수 있다. 테이블 엔트리는 스위치(20)에 의해 자체적으로 파기될 수 있다.
플로우 테이블은 오픈플로우의 파이프라인(pipeline)을 처리하기 위해 다중 플로우 테이블로 구성될 수 있다. 도 4를 참조하면, 플로우 테이블의 플로우 엔트리는 패킷과 매치하는 조건(대조 규칙)을 기술한 매치 필드(match fields), 우선 순위(priority), 매치되는 패킷이 있는 경우 업데이트되는 카운터(counters), 플로우 엔트리에 매치되는 패킷이 있으면 발생하는 다양한 액션들의 집합인 인스트럭션(instruction), 스위치에서 파기될 시간을 기술하는 타임아웃(timeouts), 제어기에 의해 선택되어지는 오파큐(opaque) 타입으로, 제어기에 의해 플로우 통계, 플로우 변경, 및 플로우 삭제를 필터하기 위해 사용될 수 있으며, 패킷 처리시 사용되지 않는 쿠키(cookie) 등의 튜플(tuple)을 포함할 수 있다.
인스트럭션(instruction)은 다른 플로우 테이블로 패킷을 전달하는 것과 같은 파이프라인 프로세싱을 변경할 수 있다. 또한 인스트럭션은 액션 셋(action set)에 액션을 더하는 액션(action)들의 집합, 또는 패킷에 바로 적용하기 위한 액션들의 리스트를 포함할 수 있다. 액션(action)은 특정 포트로 패킷을 전송하거나, TTL 필드를 감소시키는 것과 같이 패킷을 수정하는 작업을 의미할 수 있다. 액션은 플로우 엔트리와 연관된 인스트럭션 집합의 일부 또는 그룹 엔트리와 연관된 액션 버킷에 속할 수 있다. 액션 셋(action set)은 각 테이블에서 지시된 액션이 누적된 집합을 의미한다. 액션 셋은 매치되는 테이블이 없을 때 수행될 수 있다. 도 5는 플로우 엔트리에 의한 여러 패킷 처리를 예시한다.
파이프라인(pipleline)은 패킷과 플로우 테이블 사이의 일련의 패킷 처리 과정을 의미한다. 스위치(20)에 패킷이 유입되면, 스위치(20)는 첫번째 플로우 테이블의 우선 순위가 높은 순서대로 패킷과 매칭되는 플로우 엔트리를 탐색한다. 매칭이 되면 해당 엔트리의 인스트럭션을 수행한다. 인스트럭션은 매칭되면 바로 수행하는 명령(apply-action), 액션 셋의 내용을 지우거나 추가/수정하는 명령(clear-action; write-action), 메타데이터(metadata) 수정 명령(write-metadata), 지정된 테이블로 메타데이터와 함께 패킷을 이동시키는 고우투 명령(goto-table) 등이 있다. 패킷과 매칭되는 플로우 엔트리가 없는 경우, 테이블 설정에 따라 패킷을 폐기(drop)하거나 제어기(10)로 패킷을 패킷-인 메시지(packet-in message)에 실어서 보낼 수 있다.
그룹 테이블은 그룹 엔트리들을 포함할 수 있다. 그룹 테이블은 플로우 엔트리에 의해 지시되어 추가적인 포워딩 방법들을 제시할 수 있다. 도 5(a)를 참조하면, 그룹 테이블의 그룹 엔트리는 다음과 같은 필드를 구비할 수 있다. 그룹 엔트리를 구분할 수 있는 그룹 식별자(group identifier), 그룹 엔트리에 정의된 액션 버킷들을 일부(select) 또는 전부(all) 수행할 것이 여부에 대한 규칙을 명시한 그룹 타입(group type), 플로우 엔트리의 카운터와 같이 통계를 위한 카운터(counters), 및 그룹을 위해 정의된 파라미터들과 연관된 액션들의 집합인 액션 버킷(action buckets)을 포함할 수 있다.
미터 테이블(meter table)은 미터 엔트리들(meter entries)로 구성되며, 플로우 미터-당(per-flow meters)을 정의한다. 플로우 미터-당은 오픈플로우가 다양한 QoS 작동을 적용될 수 있도록 할 수 있다. 미터(meter)는 패킷의 레이트(rate of packets)를 측정 및 제어할 수 있는 일종의 스위치 요소이다. 도 5(b)를 참조하면, 미터 테이블(meter table)은 미터를 식별하는 미터 식별자(meter identifier), 밴드(band)에 지정된 속도와 패킷 동작 방법을 나타내는 미터 밴드(meter bands), 및 패킷이 미터에서 동작될 때 업데이트되는 카운터(counters) 필드들로 구성된다. 미터 밴드(meter bands)는 패킷이 어떻게 처리되는 지를 나타내는 밴드 타입(band type), 미터에 의해 미터 밴드를 선택하는데 사용되는 레이트(rate), 미터 밴드에 의해 패킷들이 처리될 때 업데이트되는 카운터(counters), 및 선택적인 아규먼트(argument)를 가지는 배드 타입들인 특정 아규먼트 타입(type specific argument)과 같은 필드들로 구성될 수 있다.
스위치 제어부(200)는 통상적으로 상기 각 부의 동작을 제어하여 스위치(20)의 전반적인 동작을 제어할 수 있다. 스위치 제어부(200)는 테이블(291)을 관리하는 테이블 관리 모듈(240), 플로우 검색 모듈(220), 플로우 처리 모듈(230), 및 패킷 처리 모듈(235)를 포함할 수 있다. 각 모듈은 제어부(200) 내에 하드웨어로 구성될 수 있고, 제어부(200)와 별개의 소프트웨어로 구성될 수도 있다.
테이블 관리 모듈(240)은 제어기 통신부(210)를 통해 제어기(10)로부터 수신한 엔트리를 적절한 테이블에 추가하거나, 타임 아웃(time out)된 엔트리를 주기적으로 제거할 수 있다.
플로우 검색 모듈(220)은 유저 트래픽으로서 수신한 패킷으로부터 플로우 정보를 추출할 수 있다. 플로우 정보는 에지 스위치의 패킷 유입 포트인 입구 포트(ingress port)의 식별 정보, 해당 스위치의 패킷 유입 포트(incoming port)의 식별 정보, 패킷 헤더 정보(송신원 및 목적지의 IP 주소, MAC 주소, 포트, 및 VLAN 정보 등), 및 메타데이터 등을 포함할 수 있다. 메타데이터는 이전 테이블에서 선택적으로 추가되거나, 다른 스위치에서 추가된 데이터일 수 있다. 플로우 검색 모듈(220)은 추출한 플로우 정보를 참조하여 테이블(291)에 수신 패킷에 대한 플로우 엔트리가 있는지 검색할 수 있다. 플로우 검색 모듈(220)은 플로우 엔트리가 검색되면, 플로우 처리 모듈(260)에 검색된 플로우 엔트리에 따라 수신 패킷을 처리하도록 요청할 수 있다. 만일 플로우 엔트리 검색이 실패하면, 플로우 검색 모듈(220)은 수신 패킷 또는 수신 패킷의 최소한의 데이터를 제어기 통신부(210)를 통해 제어기(10)로 전송할 수 있다.
플로우 처리 모듈(230)는 플로우 검색 모듈(220)에서 검색된 엔트리에 기술된 절차에 따라 패킷을 특정 포트 또는 다중 포트로 출력하거나, 드롭시키거나 또는 특정 헤더 필드를 수정하는 등의 액션을 처리할 수 있다.
플로우 처리 모듈(230)는 플로우 엔트리의 파이프라인 프로세스를 처리하거나 액션을 변경하기 위한 인스트럭션을 실행하거나 다중 플로우 테이블에서 더 이상 다음 테이블로 갈 수 없을 때 액션 세트를 실행할 수 있다.
패킷 처리 모듈(235)은 플로우 처리 모듈(230)에 의해 처리된 패킷을 플로우 처리 모듈(230)에서 지정한 포트부(205)의 하나 또는 2 이상의 포트로 실제로 출력할 수 있다.
도 1(b)를 참조하면, SDN 네트워크 시스템은 오케스트레이터(1)를 더 포함할 수 있다. 오케스트레이터(1)는 가상 네트워크 디바이스, 가상 스위치 등을 생성, 변경 및 삭제할 수 있다. 오케스트레이터(1)에서 가상 네트워크 디바이스를 생성하는 경우, 오케스트레이터(1)는 가상 네트워크가 접속할 스위치의 식별 정보, 해당 스위치에 연결되는 포트 식별 정보, MAC 주소, IP 주소, 터넨트(tenant) 식별 정보 및 네트워크 식별 정보 등의 네트워크 디바이스의 정보를 제어기(10)로 제공할 수 있다.
제어기(10) 및 스위치(20)는 오케스트레이터(1)와 별도의 인터페이스로 통신하거나, 제어기(10)의 스위치 통신부(110) 및 스위치(20)의 제어기 통신부(210)를 통해 오케스트레이터(1)와 통신할 수 있다. 스위치(20)는 제어기(10)를 통해 오케스트레이터(1)와 메시지를 주고 받을 수 있다.
제어기(10)와 스위치(20)는 다양한 정보를 주고 받는데, 이를 오픈플로우 프로토콜 메시지(openflow protocol message)라 칭한다. 이러한 오픈플로우 메시지는 제어기-스위치 메시지(controller-to-switch message), 비동기 메시지(asynchronous message), 및 대칭 메시지(symmetric message) 등의 타입이 있다. 각 메시지는 엔트리를 식별하는 트랜잭션 식별자(transaction id; xid)를 헤더에 구비할 수 있다.
제어기-스위치 메시지는 제어기(10)가 생성하여 스위치(20)에 전달하는 메시지로써, 주로 스위치(20)의 상태를 관리하거나 점검하기 위해 사용된다. 제어기-스위치 메시지는 제어기(10)의 제어부(100), 특히 메시지 관리 모듈(130)에 의해 생성될 수 있다.
제어기-스위치 메시지는 스위치의 능력(capabilities)을 문의하는 기능(features), 스위치(20)의 구성 매개 변수 등의 설정을 문의하고 설정하기 위한 설정(configuration), 오픈플로우 테이블의 플로우/그룹/미터 엔트리들을 추가/삭제/수정하기 위한 상태 변경 메시지(modify state message), 패킷-인 메시지를 통해 스위치로부터 수신한 패킷을 해당 스위치 상의 특정한 포트로 전송하도록 하는 패킷-아웃 메시지(packet-out message) 등이 있다. 상태 변경 메시지는 플로우 테이블 변경 메시지(modify flow table message), 플로우 엔트리 변경 메시지(modify flow entry message), 그룹 엔트리 변경 메시지(modify group entry message), 포트 변경 메시지(prot modification message), 및 미터 엔트리 변경 메시지(meter modification message) 등이 있다.
비동기 메시지는 스위치(20)가 생성하는 메시지로서, 스위치의 상태 변경 및 네트워크 이벤트 등을 제어기(10)에서 업테이트하기 위해 사용된다. 비동기 메시지는 스위치(20)의 제어부(200), 특히 플로우 검색 모듈(220)에 의해 생성될 수 있다.
비동기 메시지로 패킷-인 메시지(packet-in message), 플로우 삭제 메시지(flow-removed), 에러 메시지 등이 있다. 패킷-인 메시지는 스위치(20)가 제어기(10)에게 패킷을 전송하여 패킷에 대한 제어를 받기 위해 사용된다. 패킷-인 메시지는 스위치(20)가 미지의 패킷을 수신한 경우, 데이터 경로를 요구하기 위해, 오픈플로우 스위치(20)에서 제어기(10)로 전송되는 수신 패킷 또는 그 사본의 전부 또는 일부를 포함하는 메시지이다. 유입 패킷에 연관된 엔트리의 액션이 제어기로 보내라고 정해져 있을 때에도 패킷-인 메시지가 사용된다. 삭제된 플로우(flow-removed) 메시지는 플로우 테이브에서 삭제할 플로우 엔트리 정보를 제어기(10)로 전달하기 위해 사용된다. 이 메시지는 제어기(10)가 스위치(20)에 해당 플로우 엔트리 삭제를 요청하였거나 플로우 타임아웃(timeout)에 의한 플로우 만기 처리(flow expiry process)에서 발생한다.
대칭 메시지는 제어기(10) 및 스위치(20) 모두에서 생성되며, 상대방의 요청이 없어도 전송되는 특징이 있다. 제어기와 스위치 간에 연결을 개시할 때 사용되는 헬로(hello), 제어기 및 스위치 간 연결에 이상이 없음을 확인하기 위한 에코(echo), 및 제어기나 스위치에 의해 사용되며 문제를 반대측에 알리기 위한 에러 메시지(error message) 등을 포함할 수 있다. 에러 메시지는 대부분 제어기에 의해 개시된 요청에 따른 실패를 나타나기 위해 스위치에서 사용된다.
도 6은 본 발명의 일 실시예에 따른 멀티 테넌트 지원 네트워크 시스템에 대한 구조도, 도 7은 도 6의 네트워크 시스템의 구성요소에 대한 블록 구성도이다. 동일하거나 유사한 구성요소에 대한 자세한 설명은 도 1 내지 도 5를 참조한다.
도 6을 참조하면, 네트워크 시스템은 복수의 스위치(SW1~5), 제어기(10), 레거시 컨테이너 앱(300), 및 복수의 레거시 컨테이너(400)를 포함할 수 있다.
복수의 스위치(SW1-SW5) 중 적어도 일부는 SDN(Software Defined Network) 기반의 스위치로 오픈플로우 프로토콜을 지원하는 물리적인 스위치 또는 가상 스위치일 수 있다. 복수의 스위치(SW1-SW5)는 오픈플로우 스위치와 기존의 레거시 스위치의 혼용으로 구성될 수 있는데, 이 경우 에지 스위치는 오픈플로우 스위치인 것이 바람직하다.
복수의 스위치(SW1-SW5)는 서로 연결될 수 있다. 복수의 스위치(SW1-SW5) 중 에지 스위치는 각 포트들(p21, p22, p31, p32, p41, p42)을 통해 네트워크 디바이스들과 연결되거나, 외부 네트워크(레거시 라우터, 게이트웨이 등)와 연결될 수 있다.
제어기(10)는 SDN(Software Defined Network) 기반의 복수의 스위치를 제어할 수 있다. 도 7을 참조하면, 제어기(10)의 제어기 제어부(100)는 토폴로지 관리 모듈(120), 경로 계산 모듈(125), 엔트리 관리 모듈(135), 메시지 관리 모듈(130), 레거시 인터페이스 모듈(145)을 포함할 수 있다. 각 모듈은 제어부(100) 내에 하드웨어로 구성될 수 있고, 제어부(100)와 별개의 소프트웨어로 구성될 수도 있다. 동일한 도면 부호의 구성요소에 대한 설명은 도 2를 참조한다.
스위치 그룹이 오픈플로우 스위치로만 구성된 경우, 토폴로지 관리 모듈(120) 및 경로 계산 모듈(125)의 기능은 도 1 내지 도 5에서 설명한 것과 동일하다. 스위치 그룹이 오픈플로우 스위치와 기존의 레거시 스위치로 구성된 경우, 토폴로지 관리 모듈(120)은 오픈플로우 스위치를 통해 레거시 스위치와의 접속 정보를 얻을 수 있다.
레거시 인터페이스 모듈(145)은 레거시 컨테이너 앱(300)과 통신할 수 있다. 레거시 인터페이스 모듈(145)은 토폴로지 관리 모듈(120)에서 구축한 스위치 그룹의 토폴로지 정보를 레거시 라우팅 컨테이너(300)로 전송할 수 있다. 토폴로지 정보는 제1 내지 제5 스위치(SW1-SW5)의 접속 관계 정보 및 제1 내지 제5 스위치(SW1-SW5)에 연결되어 있는 네트워크 디바이스들 및 네트워크 장치들(레거시 스위치, 레거시 라우터 등) 각각의 또는 서로의 연결 또는 접속 정보를 포함할 수 있다.
레거시 인터페이스 모듈(145)은 복수의 스위치(SW1-SW5) 중 어느 한 스위치를 통해 수신한 인입 패킷에 대해 해석이 불가능한 경우, 경로 지정이 불가능한 경우, 및 정책상 지정되어 있는 경우 중 어느 한 경우에 인입 패킷을 레거시 컨테이너 앱(300)으로 전달할 수 있다.
패킷의 해석 불가능 또는 경로 지정 불가능의 예는 인입 패킷이 레거시 프로토콜로 구성되어 해석할 수 없거나, 레거시 네트워크와 연결되어 경로 계산 모듈(125)이 수신 패킷에 대한 경로를 지정할 수 없는 경우 등이 있다.
정책상 인입 패킷을 앱(300)으로 전송해야 하는 경우는, 복수의 스위치(SW1-SW5)에 연결된 네트워크를 멀티 테넌트로 구성해야 하는 경우, 또는 네트워크를 탄력적으로 운용하기 위해 다수의 가상 라우터로 구성해야 하는 경우 등이 있다. 이는 관리자 또는 사용자의 제어나 요청에 의해 발생된 가상 라우터 생성 요청 메시지에 의해 트리거될 수 있다. 레거시 컨테이너 앱(300)는 가상 라우터 생성 요청 메시지를 오픈플로우 스위치나 오케스트레이터(1)를 통해 수신할 수 있다. 멀티 테넌트 및 다수의 가상 라우터에 관해서는 후술한다.
레거시 인터페이스 모듈(145)은 오픈플로우 스위치로부터 수신한 플로우 문의 메시지에 구비된 플로우의 처리 규칙을 생성할 수 없는 경우, 해당 플로우를 레거시 컨테이너 앱(300)으로 전송할 수 있다. 해당 플로우는 오픈플로우 스위치에서 수신한 패킷 및 패킷을 수신한 스위치의 포트 정보를 포함하는 것이 바람직하다.
레거시 인터페이스 모듈(145)은 후술할 레거시 컨테이너(400)에서 생성된 라우팅 경로 정보를 오픈플로우(OpenFlow) 프로토콜로 변환할 수 있다.
도 7을 참조하면, 레거시 컨테이너 앱(300)은 패킷 처리부(310), 토폴로지 모듈(320), SDN 인터페이스 모듈(340), 및 컨테이너 생성부(350)을 포함할 수 있다. 레거시 컨테이너 앱(300)은 별도의 장치에서 구동되거나, 제어기(10)에서 구동될 수 있다.
SDN 인터페이스 모듈(340)은 제어기 제어부(100)와 통신할 수 있다. 제어기 제어부(100)의 레거시 인터페이스 모듈(140) 및 레거시 컨테이너 앱(300)의 SDN 인터페이스 모듈(340) 각각은 제어기 제어부(100)와 레거시 라우팅 컨테이너(300)의 인터페이스 역할을 할 수 있다. 레거시 인터페이스 모듈(140) 및 SDN 인터페이스 모듈(340)은 특정 프로토콜이나 특정 언어로 통신할 수 있다.
레거시 인터페이스 모듈(140) 및 SDN 인터페이스 모듈(340) 모두 또는 어느 하나는 제어기(10)와 레거시 라우팅 컨테이너(300)가 주고 받는 메시지를 번역하거나 해석할 수 있다. 예를 들어, 레거시 프로토콜 메시지를 오픈플로우 프로토콜 메시지로 변환할 수 있다.
토폴로지 모듈(320)은 제어기 제어부(100)로부터 전달받은 복수의 스위치(SW1-SW5)에 관련된 토폴로지 정보 등의 네트워크 정보를 저장할 수 있다. 토폴로지 모듈(320)은 정책상 생성할 다수의 가상 라우터 또는 멀티 테넌트에 대한 네트워크 토폴로지를 생성할 수 있다. 토폴로지 모듈(320)의 다수의 가상 라우터 또는 멀티 테넌트(이하, '멀티 테넌트 등'이라고 칭함)에 대한 네트워크 토폴로지 등과 같은 멀티 테넌트 등의 생성용 정보는 정책에 의해 생성될 뿐만 아니라 사용자의 요청이나 관리자의 제어에 의해 생성될 수 있다.
복수의 가상 라우터는 네트워크의 용량을 탄력적으로 조절할 수 있게 한다. 데이터 센터와 같이 클라우드 환경을 제공해야 하는 경우 네트워크 용량 조절이 용이할 수 있다. 다양한 사용자에게 클라우드 환경을 제공해야 하는 경우, 복수의 가상 라우터는 사용자에 따라 가상 라우터를 지원할 수 있으며 사용자의 사용량에 따른 과금 정책을 용이하게 할 수 있다. 복수의 가상 라우터 각각이 제어하는 네트워크 환경을 서로 독립적으로 하는 경우, 각각의 테넌트가 가지는 자원은 독립성이 보장되어 다른 테넌트와 공유되지 않도록 하는 멀티 테넌시를 지원할 수 있다.
멀티 테넌트 등의 생성용 정보(이하, '생성 정보')는 네트워크 토폴로지 이외에 가상 라우터에 연결될 네트워크 디바이스의 개수나 종류 위치 및 네트워크 정보, 사용자들의 그룹 정책, 생성될 가상 라우터에 부여될 네트워크 자원이나 컴퓨팅 자원 할당 정책, 가상 라우터의 루프백(loopback) IP 주소나 포트 정보(링크 주소, 맥 주소 등) 등이 포함될 수 있다. 네트워크 또는 컴퓨팅 자원의 할당 정책은 기본 정책 이외에, 관리자의 지정 또는 사용자의 요청에 의해 결정될 수 있다. 생성 정보의 일부는 위에서 언급한 가상 라우터 생성 메시지에 포함되어 있을 수 있다.
컨테이너 생성부(350)는 토폴로지 모듈(320)의 생성 정보에 기초하여 라우팅 기능을 가지는 레거시 컨테이너(400)를 생성 및/또는 관리 할 수 있다. 컨테이너 생성부(350)는 제어기 제어부(100)로부터 가상 라우터 생성 메시지를 수신하면, 레거시 컨테이너(400)를 생성하기 위한 준비를 한다.
우선, 컨테이너 생성부(350)는 생성 정보의 네트워크 또는 컴퓨팅 자원 할당 정책에 기초하여 생성될 레거시 컨테이너(400)에 컴퓨팅 자원을 할당하고, 레거시 컨테이너(400)를 생성할 수 있다. 레거시 컨테이너(400)를 생성하는 기술은 다양한 가상화 기술이 사용될 수 있다.
컨테이너 생성부(350)은 레거시 컨테이너(400)에 필요한 네트워크 정보를 패킷 처리부(310)를 통해 레거시 컨테이너(400)로 전달하거나 지정할 수 있다. 필요한 네트워크 정보는 생성 정보에서 추출될 수 있다.
컨테이너 생성부(350)는 레거시 컨테이너(400)에 다른 레거시 컨테이너와 구별되거나 그 자체로 식별될 수 있는 네임 스페이스 식별자를 지정할 수 있다.
컨테이너 생성부(350)는 복수의 레거시 컨테이너(401, 402, 403)를 생성할 수 있다. 컨테이너 생성부(350)은 복수의 스위치(SW1-SW5)에 인입하는 패킷에 기반한 특정 정보인 슬라이싱 식별자를 기초로 레거시 컨테이너를 복수개 생성할 수 있다.
인입 패킷에 기반한 특정 정보는 인입 패킷이 인입된 오픈플로우 에지 스위치의 인입 포트 정보, 인입 패킷의 vLAN 이나 vxLAN과 같은 태그 정보 등이 있다. 즉, 슬라이싱 식별자는 인입 패킷의 인입 포트, vLAN, vxLAN 정보 등을 포함할 수 있다. 인입 패킷의 태그 정보는 패킷의 소스 디바이스에서 지정되거나, 오픈플로우 스위치 또는 제어기(10)에서 지정될 수 있다. 패킷이 이동통신망을 통해 접속되는 경우, 슬라이싱 식별자는 패킷에 부가되는 터널(tunnel) 아이디 등의 태그 정보를 포함할 수 있다.
슬라이싱 식별자는 네임 스페이스 식별자에 연관될 수 있다. 이에 의해, 슬라이싱 식별자와 네임 스페이스 식별자는 서로 대응될 수 있다.
복수의 레거시 컨테이너(401, 402, 403)는 서로 격리된 네트워크를 형성할 수 있다. 이로 인해 본 발명에 따른 네트워크 시스템은 멀티 테넌트를 지원할 수 있다.
복수의 스위치(SW1-SW5)에 연결된 네트워크 디바이스들이 멀티 테넌트를 구성하는 경우, 각각의 테넌트는 슬라이싱 식별자 또는 네임 스페이스 식별자에 각각 대응될 수 있다.
네임 스페이스 식별자는 레거시 컨테이너에서 기능하는 가상 라우터의 루프백 주소, 또는 vLAN, vxLAN 정보와 같은 태그 정보와 동일하도록 지정할 수 있다. 네임 스페이스 식별자는 임의의 값이나 가상 라우터의 루프백 주소를 사용할 수 있다.
패킷 처리부(310)는 레거시 컨테이너(400)와의 인터페이스 역할을 한다. 오픈플로우 스위치에 인입된 인입 패킷에 대한 라우팅 제어를 위해 제어기 제어부(100)가 인입 패킷을 레거시 컨테이너 앱(300)로 전달하면, 패킷 처리부(310)는 수신한 인입 패킷이 복수의 레거시 컨테이너(401, 402, 403) 중 어느 레거시 컨테이너로 전달해야할지 결정할 수 있다. 이를 위해, 패킷 처리부(310)는 인입 패킷으로부터 슬라이싱 식별자를 추출하고, 복수의 레거시 컨테이너(401, 402, 403) 중 슬라이싱 식별자에 연관된 네임 스페이스 식별자를 가진 레거시 컨테이너로 인입 패킷을 전달할 수 있다. 패킷 처리부(310)는 슬라이싱 식별자의 하나의 값 또는 여러 값들의 조합과 하나의 네임 스페이스 식별자를 한 쌍으로 연관시켜 연관 리스트로 저장할 수 있다.
패킷 처리부(310)는 레거시 컨테이너(400)로부터 후술할 라우팅 정보를 수신하여, SDN 인터페이스 모듈(340)으로 전달할 수 있다.
도 7을 참조하면, 레거시 컨테이너(400)는 네임 스페이스부(440), 라우팅 처리부(430), 및 라우팅 정보 저장부(450)를 포함할 수 있다.
네임 스페이스부(440)는, 컨트롤러 생성부(350)에 의해 레거시 컨테이너가 생성되면, 레거시 컨테이너의 네트워크 환경을 설정한다. 레거시 컨테이너의 네트워크 환경은 레거시 컨테이너가 가상 라우터로서 기능할 수 있도록 네트워크 인터페이스나 기능할 가상 라우터의 포트 인터페이스 등이 있다. 즉 네임 스페이스부(440)는 외부와의 인터페이스인 네트워크 환경을 구축할 수 있다.
네임 스페이스부(440)는 리눅스의 네임 스페이스 기술을 사용할 수 있다. 이 경우, 컨트롤러 생성부(350)의 지시에 의해, 네임 스페이스부(440)가 레거시 컨테이너를 생성할 수 있다.
네임 스페이스부(440)는 레거시 컨테이너 앱(300)와의 인터페이스 역할을 한다. 네임 스페이스부(440)는 레거시 컨테이너 앱(300)으로부터 수신한 네트워크 정보를 이용하여 레거시 컨테이너의 네트워크 환경을 설정할 수 있다. 네임 스페이스부(440)는 다른 레거시 컨테이너와의 네트워크와 별도의 독립된 네트워크 환경을 설정할 수 있다.
네임 스페이스부(440)는 레거시 컨테이너 앱(300)으로부터 수신한 네트워크 정보를 이용하여 레거시 컨테이너가 가상의 라우터로 기능하도록 할 수 있다. 네임 스페이스부(440)는, 라우팅 기능에 필요한 가상 라우터의 네트워크 환경, 즉, 네트워크 노드들의 정보나 노드들의 토폴로지 정보를 레거시 컨테이너 앱(300)으로부터 수신하여, 라우팅 정보 저장부(450)에 저장할 수 있다. 네트워크 노드들은 복수의 스위치(SW1-SW5) 중 가상 라우팅 기능이 관여할 스위치들의 정보, 스위치들에 연결된 네트워크 디바이스들이나 외부 네트워크를 포함할 수 있다.
라우팅 처리부(430)는 라우팅 정보 저장부(450)에 저장된 네트워크 토폴로지 정보나 네트워크 정보를 이용하여 라우팅 테이블(RIB, FIB, ARP 테이블)을 생성할 수 있다. 라우팅 테이블은 라우팅 처리부(430)에 의해 수정되거나 삭제되는 등 업데이트될 수 있다.
이를 위해, 라우팅 처리부(430)은 레거시 프로토콜을 이용하여 외부와 메시지를 주고 받을 수 있다. 생성된 테이블은 라우팅 정보 저장부(450)에 저장될 수 있다.
라우팅 정보 저장부(450)는 네임 스페이스 식별자를 저장할 수 있다. 네임 스페이스부(440)는 레거시 컨테이너 앱(300)을 통해 수신한 인입 패킷에 대해 네임 스페이스 식별자를 이용하여 드롭 여부를 결정할 수도 있다.
라우팅 정보 저장부(450)는 레거시 컨테이너가 제공하는 가상 라우터의 인터페이스를 저장함으로써, 라우팅 정보 저장부(450)는 복수의 스위치(SW1-SW5) 중 일부의 스위치를 포함하는 스위치 군을 외부에서 가상 라우터로 보이도록 할 수 있다.
라우팅 정보 저장부(450)에 저장되는 가상 라우터의 인터페이스는 다양할 수 있다.
도 8은 본 발명의 다른 실시예에 따른 레거시 컨테이너의 블록 구성도이다. 도 1 내지 도 5를 참조한다.
도 8을 참조하면, 레거시 컨테이너는 네임 스페이스부(440), 라우팅 처리부(430), 라우팅 정보 저장부(450), 및 DHCP 가상 서버(460)를 포함할 수 있다. 동일한 구성요소에 대한 설명은 도 7을 참조한다.
DHCP 가상 서버(460)는 네임 스페이스부(440)에서 수신한 인입 패킷이 DHCP(Dynamic Host Configuration Protocol) 프로토콜인 경우, 요청한 네트워크 디바이스에서 사용할 IP 주소를 생성할 수 있다. 즉 네트워크 디바이스에서 IP 주소 요청이 있는 경우, DHCP 가상 서버(460)는 요청한 네트워크 디바이스에 IP 주소를 발송할 수 있다. DHCP 가상 서버(460)은 레거시 컨테이너가 DHCP 서버 기능을 가능하도록 할 수 있다.
도 9는 레거시 컨테이너 생성 방법에 대한 순서도이다. 도 1 내지 도 8을 참조한다.
도 9를 참조하면, 레거시 컨테이너 앱(300)에서 가상 라우터 생성 요청 메시지를 수신하면(S540), 레거시 컨테이너 앱(300)은 네트워킹 자원 또는/ 및 컴퓨팅 자원을 생성될 레거시 컨테이너를 위해 할당할 수 있다(S520).
레거시 컨테이너 앱(300)은 할당된 자원을 이용하여 레거시 컨테이너를 생성할 수 있다(S530). 이 후, 레거시 컨테이너 앱(300)은 네임 스페이스 식별자 및 가상 라우팅 기능에 필요한 네트워크 인터페이스, 네트워크 토폴로지 정보 등의 네트워크 정보를 생성된 레거시 컨테이너(400)에 전달 또는/및 지정할 수 있다(S540).
앞서 서술한 바와 같이, 레거시 컨테이너의 생성은 레거시 컨테이너 앱(300)의 컨테이너 생성부(350)에서 네임 스페이스부(440)를 생성하고, 네임 스페이스부(440)에서 레거시 컨테이너의 나머지 전반적인 부분을 생성할 수도 있다.
네임 스페이스부(440)는 레거시 컨테이너 앱(300)으로부터 수신한 네트워크 정보를 이용하여, 레거시 컨테이너가 가상 라우터로 기능하도록 가상 라우터를 구축하여, 가상 라우터의 인터페이스 및 네트워크 토폴로지 정보 등을 라우팅 정보 저장부(450)에 저장할 수 있다.
라우팅 처리부(430)는 라우팅 정보 저장부(450)에 저장된 정보를 이용하여, 가상 라우터가 라우팅 기능을 하도록 라우팅 테이블이나 포워딩 테이블을 작성할 수 있다. 이에 의해 레거시 컨테이너(400)는 라우팅 기능을 제공할 준비가 완료된다(S550).
도 10은 도 9의 라우팅 기능 준비 방법을 구체화한 순서도이고, 도 11은 가상 라우터의 다양한 인터페이스를 도시한 구조도이다. 도 1 내지 도 9를 참조한다.
도 10을 참조하면, 네임 스페이스부(440)는 가상 라우터의 인터페이스를 지정하고, 각 인터페이스에 네트워크 디바이스를 포함하는 네트워크 노드들의 인터페이스와 연결되도록 지정할 수 있다(S560).
네임 스페이스부(440)는 복수의 스위치(SW1-SW5) 중 해당 가상 라우팅에 이용될 스위치 군을 지정하고, 스위치 군에 속하는 스위치들의 인터페이스와 가상 라우터의 인터페이스가 맵핑되도록 할 수 있다(S570).
도 11을 참조하면, 다양한 인터페이스를 가지는 가상 라우터를 볼 수 있다.
도 11(a)를 보면, 복수의 스위치(SW1-SW5) 중 에지 스위치의 포트들 중 일부와 제1 가상 라우터(v-R1)의 포트가 대응되도록 가상 라우터의 인터페이스가 구축될 수 있다. 이 경우, 슬라이싱 식별자는 포트 p21, p31, p41, 및 p51가 될 수 있다. 네임 스페이스 식별자는 포트 p21, p31, p41, 및 p51의 조합과 대응하는 값, 예를 들어, v-R3로 지정될 수 있다. 즉 네임 스페이스 식별자는 슬라이싱 식별자 값들의 리스트와 대응될 수 있다.
도 11(b)를 참조하면, 복수의 스위치(SW1-SW5) 중 일부 에지 스위치의 포트들이 제2 가상 라우터(v-R2)의 포트와 대응되도록 가상 라우터의 인터페이스가 구축될 수 있다.
도 11(c) 내지 (f)를 참조하면, 가상 라우터의 인터페이스는 패킷의 vLAN 또는 vxLAN 값과 대응되도록 설정될 수 있다. 에지 스위치의 물리적 포트(실제 포트)만으로 가상 라우터를 생성하는 경우, 물리적 포트의 수에 제한을 받게 된다. 그러나 패킷 식별 정보(vLAN 또는 vxLAN)에 연관시키는 경우, 이러한 제약 사항이 없어진다. 또한 기존의 패킷의 레거시 네트워크에서의 흐름과 유사하게 작동되도록 할 수 있다. 또한 사용자 또는 사용자 그룹 별로 가상의 레거시 라우터를 구동할 수 있다. 사용자 또는 사용자 그룹은 vLAN, vxLAN 또는 터널 아이디와 같은 패킷 식별 정보로 구분될 수 있다.
도 12는 본 발명의 다른 실시예에 따른 네트워크 구조도이고, 도 13은 도 12에 따른 가상 라우터의 구조도이다. 도 1 내지 도 11을 참조한다.
도 12를 참조하면, 본 네트워크는 멀티 테넌시를 지원하며, 네트워크 디바이스(VM)들은 멀티 테넌트 각각에 속해있다. 제1 테넌트는 제21 및 제22 스위치(SW21, SW22)의 포트 p21n(p21_1, p21_2, ..., p12_n) 및 포트 p22n을 통해 연결되어 있다고 가정하며, 나머지 디바이스들은 포트 p23n, 및 p24n을 통해 제23 및 제24 스위치(SW23, SW24)와 연결되도록 정책이 성립되었다고 가정한다.
두 개의 테넌트를 지원하기 위해, 도 13과 같이 독립된 두 개의 가상 라우터 기능이 제공되도록 제1 및 제2 레거시 컨테이너가 생성될 수 있다.
슬라이싱 식별자는 vLAN 값으로 지정하는 것이 바람직하다. 즉 제1 테넌트는 vLAN이 101인 값이고, 제2 테넌트는 vLAN 값이 102인 것이 될 수 있다. 네임 스페이스 식별자(nsID)는 vLAN 값과 각각 동일하게 지정될 수 있다.
가상 라우터의 포트 인터페이스와 에지 스위치들의 포트 인터페이스는 1:1로 대응되도록 하거나, 다양한 조합으로 연관되도록 할 수 있다.
도 14는 도 6의 제어기의 플로우에 대한 레거시 라우팅 여부 판단 방법에 대한 순서도이다. 도 6 내지 도 11을 참조한다.
플로우에 대한 레거시 라우팅 여부 판단 방법은, 제어기(10)가 오픈플로우 스위치로부터 수신한 플로우에 대해 일반적인 SDN 제어를 할 것인지 또는 레거시 라우팅 컨테이너(300)에 플로우 제어를 문의해야 하는지를 의미한다.
도 14를 참조하면, 레거시 컨테이너(400)에서 가상 라우팅 기능 준비가 완료되면, 제어기(10)는 오픈플로우 스위치를 통해 네트워크 디바이스의 패킷을 플로우로 수신할 수 있다(S610).
제어기(10)는 플로우의 인입 패킷이 해석 가능한지 판단한다(S620). 인입 패킷을 해석할 수 없는 경우, 제어기(10)는 플로우를 레거시 라우팅 컨테이너 앱(300)으로 전달할 수 있다(S650). 패킷이 레거시 네트워크에서만 사용하는 프로토콜 메시지의 경우, SDN 기반의 일반적인 제어기는 패킷을 해석을 할 수 없기 때문이다.
인입 패킷이 외부의 제1 레거시 네트워크에서 외부의 제2 레거시 네트워크로 전송되는 것과 같은 레거시 패킷인 경우, SDN 기반의 제어기(10)는 유입된 레거시 패킷의 라우팅 경로를 계산할 수 없다. 따라서 레거시 패킷과 같이 제어기(10)에서 경로를 계산할 수 없는 경우, 제어기(10)는 레거시 패킷을 레거시 라우팅 컨테이너 앱(300)으로 전달할 수 있다. 레거시 패킷에 대한 레거시 라우팅 경로는 레거시 컨테이너(400)의 라우팅 처리부(430)에 의해 계산될 수 있다. 다만 레거시 패킷의 유출될 에지 포트와 레거시 패킷의 최종 처리 방법을 알면, 플로우 수정을 통해 제어기(10)에서 레거시 패킷을 처리할 수 있다.
이에 패킷을 해석할 수 있는 경우, 제어기(10)는 해당 플로우의 경로를 계산할 수 있는지 또는 엔트리 테이블에 엔트리가 있는지 등의 플로우 경로를 검색한다(S630). 경로를 검색할 수 없으면, 제어기(10)는 해당 플로우를 레거시 라우팅 컨테이너 앱(300)으로 전달한다(S650). 경로를 검색할 수 있으면, 제어기(10)는 패킷의 출력을 지정하는 패킷-아웃 메시지를 생성하여 패킷 문의한 오픈플로우 스위치로 전송할 수 있다(S640).
도 15는 레거시 컨테이너에서 인입 패킷에 대한 처리 방법의 순서도이고, 도 16은 도 15의 라우팅 처리가 아닌 일례에 대한 순서도이다.
도 15를 참조하면, 레거시 컨테이너 앱(300)은 제어기(10)를 통해 수신한 플로우의 인입 패킷을 분석하고 인입 패킷의 슬라이싱 식별자를 추출할 수 있다(S810).
레거시 컨테이너 앱(300)은 추출한 슬라이싱 식별자와 연관된 네임 스페이스(ns) 식별자 세트가 식별자들의 연관 리스트에 있는지 판단할 수 있다(S820).
슬라이싱 식별자 및 네임 스페이스 식별자 세트가 연관 리스트에 없는 경우, 레거시 컨테이너 앱(300)은 인입 패킷이 드롭되도록 할 수 있다(S900).
식별자 세트가 연관 리스트에 있는 경우, 레거시 컨테이너 앱(300)은 슬라이싱 식별자와 연관된 네임 스페이스 식별자가 지정된 레거시 컨테이너(400)로 플로우를 전달할 수 있다(S830).
레거시 컨테이너(400)의 라우팅 처리부(430)는 수신한 플로우의 인입 패킷을 해석하여 해당 패킷이 라우팅 요청 메시지인지 판단할 수 있다(S840).
인입 패킷이 라우팅 요청인 경우, 레거시 컨테이너(400)는 인입 패킷의 목적지 IP 주소에 대한 라우팅 정보가 있는지 판단할 수 있다(S850).
목적지 IP 주소에 대한 라우팅 정보가 있는 경우, 라우팅 처리부(430)는 인입 패킷이 드롭되도록 할 수 있다(S890).
목적지 IP 주소에 대한 라우팅 정보가 있는 경우, 라우팅 처리부(430)는 라우팅 경로를 생성하여 레거시 컨테이너 앱(300)으로 전송할 수 있다(S860). 라우팅 경로는 제어기 제어부(100)의 레거시 인터페이스 모듈(140) 또는 레거시 컨테이너 앱(300)의 SDN 인터페이스 모듈(340) 중 어느 한 곳에서, 오픈플로우 프로토콜로 변환될 수 있다(S870). 예를 들어, 레거시 인터페이스 모듈(140)은 라우팅 경로에 기초하여 오픈플로우 스위치들에서 플로우가 진행되도록 플로우 엔트리를 생성, 수정, 또는 삭제하고, 관련된 오픈플로우 스위치의 엔트리 테이블이 업데이트되도록 할 수 있다.
라우팅 요청 여부의 판단(S830) 결과 라우팅 요청 처리가 아닌 경우, 레거시 컨테이너(400)는 해당 요청을 처리할 수 있다(S880). 이에 대한 자세한 사항은 도 16을 참조한다.
도 16을 참조하면, 인입 패킷이 라우팅 요청 처리가 아닌 네트워크 디바이스가 시작되어 IP 주소를 요청하는 DHCP 프로토콜인 경우로 가정한다.
레거시 컨테이너(400)의 라우팅 처리부(430)는 인입 패킷의 내용을 분석하여, 인입 패킷이 IP 주소 요청 메시지임을 알 수 있다(S910). 라우팅 처리부(430)는 인입 패킷을 DHCP 가상 서버(460)로 전달한다(S820). DHCP 가상 서버(460)는 인입 패킷을 발송한 네트워크 디바이스의 네트워크 환경, 예를 들어 어느 사용자 그룹인지, 또는 어느 테넌트인지 고려하여, IP 주소 정보와 서브넷 마스크 정보를 생성할 수 있다(S930). 생성된 IP 주소 정보와 서브넷 마스크 정보는 레거시 컨테이너 앱(300)과 제어기(10), 오픈플로우 스위치를 거쳐, 발송 네트워크 디바이스로 전달된다(S940). 네트워크 디바이스와 DHCP 가상 서버(460)가 주고 받는 메시지는 일반적인 DHCP 프로토콜 메시지(DHCP Discover, DHCP offer, DHCP request, DHCP ack)일 수 있다.
상기 본 발명은 하드웨어 또는 소프트웨어에서 구현될 수 있다. 구현은 상기 본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술분야의 프로그래머들에 의해 용이하게 추론될 수 있다.
본 발명의 실시예들은 여기에 설명된 방법들 중 하나가 실행되는 프로그램가능 컴퓨터 시스템으로 운영될 수 있는, 전자적으로 판독가능한 제어 신호들을 갖는 캐리어 웨이브를 포함할 수 있다. 본 발명의 실시예들은 프로그램 코드를 갖는 컴퓨터 프로그램 제품으로서 구현될 수 있으며, 프로그램 코드는 컴퓨터 프로그램이 컴퓨터 상에서 구동될 때 방법들 중 하나를 실행하기 위하여 운영된다. 프로그램 코드는 예를 들면 기계 판독가능 캐리어 상에 저장될 수 있다. 본 발명의 일실시예는 컴퓨터 프로그램이 컴퓨터 상에 구동될 때, 여기에 설명된 방법들 중 하나를 실행하기 위한 프로그램 코드를 갖는 컴퓨터 프로그램일 수 있다. 본 발명은 위에서 설명한 방법들 중 하나를 실행하기 위한 컴퓨터, 또는 프로그램가능 논리 장치를 포함할 수 있다. 위에서 설명한 방법들의 일부 또는 모든 기능을 실행하기 위하여 프로그램가능 논리 장치(예를 들면, 필드 프로그램가능 게이트 어레이, 상보성 금속 산화물 반도체 기반 논리 회로)가 사용될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안 될 것이다.
<부호의 설명>
10: 제어기 20: SDN 스위치
30: 네트워크 디바이스 100: 제어부
120: 토폴로지 관리 모듈 125: 경로 계산 모듈
130: 메시지 관리 모듈 135: 엔트리 관리 모듈
190: 저장부 200: 스위치 제어부
205: 포트부 210; 제어기 통신부
220: 플로우 검색 모듈 230: 플로우 처리 모듈
235: 패킷 처리 모듈 240: 테이블 관리 모듈
300: 레거시 컨테이너 앱 400: 레거시 컨테이너

Claims (13)

  1. SDN(Software Defined Network) 기반의 복수의 스위치를 제어하는 제어기;
    상기 복수의 스위치 중 적어도 일부의 스위치를 포함하는 스위치 군을 가상 라우터로 취급하여, 상기 스위치 군 중 어느 한 스위치에 인입되는 패킷에 대한 라우팅 정보를 생성하는 레거시 컨테이너; 및
    가상 라우터 생성 요청 메시지를 수신하면, 컴퓨팅 자원을 할당하여 상기 레거시 컨테이너를 가상화 기술을 이용하여 생성하는 레거시 컨테이너 앱을 포함하고,
    상기 레거시 컨테이너 앱은 상기 복수의 스위치로 인입하는 패킷에 기반한 특정 정보인 슬라이싱 식별자를 기초로 레거시 컨테이너를 복수개 생성하는, SDN 기반의 멀티 테넌트 지원 네트워크 시스템.
  2. 제 1 항에 있어서,
    상기 복수의 레거시 컨테이너는 서로 격리된 네트워크를 형성하는, 네트워크 시스템.
  3. 제 1 항에 있어서,
    상기 패킷의 슬라이싱 식별자는 인입 포트, vLAN, 및 vxLAN 정보 중 적어도 하나인, 네트워크 시스템.
  4. 제 1 항에 있어서,
    상기 레거시 컨테이너 앱은 상기 패킷의 슬라이싱 식별자에 연관된 네임 스페이스 식별자를 구비하는 네트워크 정보를 상기 레거시 컨테이너에 지정하는, 네트워크 시스템.
  5. 제 1 항에 있어서,
    상기 제어기는 상기 복수의 스위치에 인입하는 인입 패킷에 대해 해석 불가능한 경우, 상기 인입 패킷의 경로 지정이 불가능한 경우, 및 정책에 지정되어 있는 경우 중 적어도 어느 한 경우에 상기 인입 패킷을 상기 레거시 컨테이너 앱으로 전달하는, 네트워크 시스템.
  6. 제 5 항에 있어서,
    상기 레거시 컨테이너 앱은 상기 제어기로부터 전달받은 상기 인입 패킷으로부터 슬라이싱 식별자를 추출하여 상기 추출된 슬라이싱 식별자에 대응하는 네임 스페이스 식별자를 구비하는 레거시 컨테이너에 상기 인입 패킷을 전달하는, 네트워크 시스템.
  7. 제 1 항에 있어서,
    상기 제어기는 상기 레거시 컨테이너에서 생성된 라우팅 경로 정보를 오픈플로우(OpenFlow) 프로토콜로 변환하는, 네트워크 시스템.
  8. 제 1 항에 있어서,
    상기 복수의 스위치는 복수의 테넌트(tenant) 각각에 속하는 각 네트워크 디바이스 군에 연결되고,
    상기 패킷 슬라이싱 식별자는 상기 복수의 테넌트 중 한 테넌트에 연관되는, 네트워크 시스템.
  9. SDN(Software Defined Network) 기반의 복수의 스위치를 제어하는 제어기;
    가상 라우팅 기능을 제공하는 레거시 컨테이너; 및
    상기 레거시 컨테이너를 생성하는 레거시 컨테이너 앱을 구비하는 네트워크 시스템의 멀티 테넌트 지원 방법으로서,
    상기 레거시 컨테이너 앱에서, 라우팅 요청 메시지를 수신하는 단계;
    상기 앱에서 컴퓨팅 자원을 할당하여 상기 레거시 컨테이너를 생성하는 단계;
    상기 앱에서 상기 컨테이너에 네임 스페이스 식별자를 구비하는 네트워크 정보를 지정하는 단계; 및
    상기 컨테이너에서, 상기 네트워크 정보를 이용하여 가상 라우팅 기능을 준비하는 단계를 포함하고,
    상기 네임 스페이스 식별자는 상기 복수의 스위치에 연결된 복수의 테넌트(tenant) 중 어느 한 테넌트에 대응하는, 지원 방법.
  10. 제 9 항에 있어서,
    상기 앱은 레거시 컨테이너를 복수개 생성하고,
    상기 복수의 레거시 컨테이너는 서로 격리된 네트워크를 형성하는, 지원 방법.
  11. 제 10 항에 있어서,
    상기 네임 스페이스 식별자는 상기 복수의 스위치에 인입하는 패킷에 기반한 특정 정보인 슬라이싱 식별자에 대응하는, 지원 방법.
  12. 제 11 항에 있어서,
    상기 제어기에서, 상기 복수의 스위치 중 어느 한 스위치에 인입된 패킷의 처리 정보가 없는 경우, 상기 인입 패킷을 상기 앱으로 전달하는 단계;
    상기 앱에서, 상기 인입 패킷으로부터 슬라이싱 식별자를 추출하는 단계; 및
    상기 앱에서, 상기 복수의 레거시 컨테이너 중 상기 추출된 슬라이싱 식별자에 대응하는 네임 스페이스 식별자를 구비한 컨테이너로 상기 인입 패킷을 전달하는 단계를 더 포함하는, 지원 방법.
  13. 제 12 항에 있어서,
    상기 인입 패킷을 전달 받은 컨테이너에서, 상기 네트워크 정보를 이용하여 구축된 라우팅 정보를 이용하여 상기 인입 패킷의 라우팅 경로 정보를 생성하는 단계;
    상기 생성된 상기 라우팅 경로 정보가 상기 앱을 통해 상기 제어기로 전송되는 단계; 및
    상기 제어기에서, 상기 라우팅 경로 정보를 SDN 프로토콜로 변환하는 단계를 더 포함하는, 지원 방법.
PCT/KR2016/000436 2016-01-12 2016-01-15 Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템 WO2017122847A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR1020160003888A KR101729945B1 (ko) 2016-01-12 2016-01-12 Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법
KR1020160003797A KR101729939B1 (ko) 2016-01-12 2016-01-12 Sdn 기반의 멀티 테넌트 지원 네트워크 시스템
KR10-2016-0003888 2016-01-12
KR10-2016-0003797 2016-01-12

Publications (1)

Publication Number Publication Date
WO2017122847A1 true WO2017122847A1 (ko) 2017-07-20

Family

ID=59311677

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/000436 WO2017122847A1 (ko) 2016-01-12 2016-01-15 Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템

Country Status (1)

Country Link
WO (1) WO2017122847A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210306285A1 (en) * 2018-08-07 2021-09-30 Nippon Telegraph And Telephone Corporation Transfer device, transfer system, transfer method, and program

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130058215A1 (en) * 2010-07-06 2013-03-07 Teemu Koponen Network virtualization apparatus and method with a table mapping engine
KR101527786B1 (ko) * 2013-12-31 2015-06-09 쿨클라우드(주) 하이브리드 sdn 네트워크 관리 방법
KR101527377B1 (ko) * 2014-03-31 2015-06-09 쿨클라우드(주) Sdn 기반의 서비스 체이닝 시스템
KR20150146391A (ko) * 2014-06-23 2015-12-31 인텔 코포레이션 소프트웨어 정의 네트워크에서의 가상화된 컨테이너 및 가상 머신을 통한 로컬 서비스 체이닝

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130058215A1 (en) * 2010-07-06 2013-03-07 Teemu Koponen Network virtualization apparatus and method with a table mapping engine
KR101527786B1 (ko) * 2013-12-31 2015-06-09 쿨클라우드(주) 하이브리드 sdn 네트워크 관리 방법
KR101527377B1 (ko) * 2014-03-31 2015-06-09 쿨클라우드(주) Sdn 기반의 서비스 체이닝 시스템
KR20150146391A (ko) * 2014-06-23 2015-12-31 인텔 코포레이션 소프트웨어 정의 네트워크에서의 가상화된 컨테이너 및 가상 머신을 통한 로컬 서비스 체이닝

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NASCIMENTO, MARCELO R. ET AL.: "Virtual Routers as a Service: the RouteFlow Approach Leveraging Software-defined Networks", CFI 1 1 PROCEEDINGS OF THE 6TH INTERNATIONAL CONFERENCE ON FUTURE INTERNET TECHNOLOGIES, 13 June 2011 (2011-06-13), pages 34 - 37, XP055398891, ISBN: 9 978-1-4503-0821-2 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210306285A1 (en) * 2018-08-07 2021-09-30 Nippon Telegraph And Telephone Corporation Transfer device, transfer system, transfer method, and program
US11799801B2 (en) * 2018-08-07 2023-10-24 Nippon Telegraph And Telephone Corporation Transfer device, transfer system, transfer method, and program

Similar Documents

Publication Publication Date Title
KR101703088B1 (ko) Sdn 기반의 통합 라우팅 방법 및 그 시스템
WO2017122849A1 (ko) 사물 인터넷 네트워크 시스템
CN105612719B (zh) 使用封装头部中的元数据的高级网络虚拟化
US9094459B2 (en) Flow based overlay network
CN105591863B (zh) 一种实现虚拟私有云网络与外部网络互通的方法和装置
US20190230039A1 (en) Method and system for extracting in-tunnel flow data over a virtual network
KR101527786B1 (ko) 하이브리드 sdn 네트워크 관리 방법
WO2020130158A1 (ko) 오픈 프론트홀 네트워크 시스템
WO2017131285A1 (ko) 컨테이너 네트워크 관리 시스템 및 컨테이너 네트워킹 방법
WO2022019720A1 (ko) 엣지 플랫폼 네트워크의 가속화 제어 방법 및 이를 사용하는 전자 장치
JP5679343B2 (ja) クラウドシステム、ゲートウェイ装置、通信制御方法、及び通信制御プログラム
KR101729944B1 (ko) Sdn 기반의 멀티 테넌트 지원 네트워크 시스템의 ip 주소 제공 방법
KR101797112B1 (ko) 컨테이너 네트워크 관리 시스템
WO2018008933A1 (ko) 단일 인터넷 회선을 이용한 가상 cpe 서비스 제공 방법 및 네트워크 펑션 가상화 클라우드
WO2020027378A1 (ko) 소프트웨어 정의 네트워크 기반의 sdn 컨트롤러, 그리고 이를 이용한 트래픽 엔지니어링 시스템 및 트래픽 엔지니어링 방법
KR20180058594A (ko) Sdn/tap 어플리케이션
KR101797115B1 (ko) 컨테이너 네트워크의 컨테이너 네트워킹 방법
WO2017122847A1 (ko) Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템
KR20180058592A (ko) Sdn 제어기
KR101729945B1 (ko) Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법
KR101729939B1 (ko) Sdn 기반의 멀티 테넌트 지원 네트워크 시스템
WO2017122848A1 (ko) Sdn 기반의 멀티 테넌트 지원 네트워크 시스템 및 멀티 테넌트 지원 방법
WO2015065003A1 (ko) 서비스에 따른 트래픽 처리를 이용한 ＱｏＳ 제어 방법
KR20180087561A (ko) 동적 가상망 서비스를 제공하기 위한 시스템 인터페이스
KR20180058593A (ko) Sdn 화이트박스 스위치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16885159

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16885159

Country of ref document: EP

Kind code of ref document: A1