WO2017131285A1 - Système de gestion de réseau conteneur et procédé de mise en réseau conteneur - Google Patents

Système de gestion de réseau conteneur et procédé de mise en réseau conteneur Download PDF

Info

Publication number
WO2017131285A1
WO2017131285A1 PCT/KR2016/002924 KR2016002924W WO2017131285A1 WO 2017131285 A1 WO2017131285 A1 WO 2017131285A1 KR 2016002924 W KR2016002924 W KR 2016002924W WO 2017131285 A1 WO2017131285 A1 WO 2017131285A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
packet
bridge
network
legacy
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2016/002924
Other languages
English (en)
Korean (ko)
Inventor
박성용
공석환
딥죠이티사이키아
정백균
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kulcloud
Original Assignee
Kulcloud
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 KR1020160008995A external-priority patent/KR101797112B1/ko
Priority claimed from KR1020160008996A external-priority patent/KR101797115B1/ko
Application filed by Kulcloud filed Critical Kulcloud
Publication of WO2017131285A1 publication Critical patent/WO2017131285A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/50—Circuit switching systems, i.e. systems in which the path is physically permanent during the communication

Definitions

  • the present invention relates to a software defined network (SDN) -based container network management system and a container networking method of a container network, to enable L2 / L3 networks between containers, to reduce unnecessary multicast and broadcast traffic,
  • SDN software defined network
  • the present invention relates to a management system and a networking method for enabling flexible network operation and enabling packet flow between a legacy network and an SDN network.
  • SDN is a basic network infrastructure abstracted from the application, logically centralized network intelligence, and separated from the control plane and data plane.
  • Open flow separates high speed packet delivery and high level routing decision functions.
  • the packet forwarding plane is still involved in the switch stage, while high-level routing decisions are involved in separate controllers, which communicate through open flow protocols.
  • Lightweight containers which are different from existing virtual machines, are used instead of virtual machines.
  • Containers do not have network management, and all containers are in the same L2 domain. This makes it difficult to manage the policy of the network and makes it difficult to manage network functions by services.
  • management of frontend / backend networks for each service is required. Only the front end is accessible from the public network, and the rest of the computing work is done only on the back end network, which is private.
  • Containers do not have such a network management mechanism, which makes it difficult to manage the network.
  • 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 is to provide a network environment for enabling container management of a container, to provide a network environment for enabling L2 / L3 networks, and to enable a private network separate from an external network under container operation. To provide.
  • Another object of the present invention is to provide a system and method for supporting a legacy network in an SDN-based container network.
  • the container network management system includes a real network interface connected to a legacy network; A software defined network (SDN) -based virtual switch that exchanges packets with a legacy network through the real network interface; A host controller generating the virtual switch; A container bridge generated by the host controller and virtually network coupled with the virtual switch through a bridge-switch network interface (NI), the container bridge having a bridge identifier identifying itself; A database for storing network subnet information and gateway information using the actual network interface as a gateway based on the bridge identifier as bridge net information; And a first host generated by the host controller, assigned with a unique IP address based on the bridge net information, and having a plurality of containers virtually network coupled to the container bridge.
  • SDN software defined network
  • NI bridge-switch network interface
  • the host comprises a real network interface connected to a legacy network; A software defined network (SDN) based virtual switch controlled by an external controller to exchange packets with a legacy network through the actual network interface; A host controller generating the virtual switch; A container bridge generated by the host controller and virtually network coupled with the virtual switch through a bridge-switch network interface (NI), the container bridge having a bridge identifier identifying itself; A database for storing network subnet information and gateway information using the actual network interface as a gateway based on the bridge identifier as bridge net information; And a plurality of containers generated by the host controller, assigned a unique IP address based on the bridge net information, and virtually network-coupled to the container bridge.
  • SDN software defined network
  • NI bridge-switch network interface
  • a container networking method of a container network includes: creating a container and creating a virtual switch based on a software defined network (SDN) in a host connected to a legacy network through an actual network interface; Networking the virtual switch with the real network interface;
  • SDN software defined network
  • the host receives a container container bridge creation request including a bridge identifier for distinguishing a network environment, gateway information using the virtual switch as a gateway, and network subnet information, generating a container bridge; Network coupling the container bridge and the virtual switch such that packets having all the same domain identifiers pass between the container bridge and the virtual switch;
  • the host receives a container creation request including a first container identifier having a bridge identifier as a key and a first same domain identifier, generating a first container having the first container identifier; Assigning an IP address to the first container based on network subnet information associated with the bridge identifier; And a bridge of the container bridge coupled to the container such that the container bridge and the first container are network
  • the present invention it is possible to manage a network of containers in an SDN-based container network, to provide L2 / L3 networking between containers, to be separated into a public network and a private network in which a service is operated, and to communicate with a legacy network.
  • This allows existing legacy network equipment to be used as is.
  • 1 is a structural diagram of an SDN network system
  • FIG. 2 is a block diagram of a controller of the network system of FIG. 1;
  • 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 block diagram of a network system including an integrated routing system according to an embodiment of the present invention.
  • FIG. 7 is a block diagram of a virtualized network of the network system of FIG.
  • FIG. 8 is a block diagram of an SDN controller according to another embodiment of the present invention.
  • FIG. 9 is a block diagram of a legacy routing container according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a method of determining legacy routing for a flow of the controller of FIG. 6.
  • FIG. 11 is a signal flow diagram according to an integrated routing method according to an embodiment of the present invention.
  • FIG. 14 is a structural diagram showing a container network management system according to an embodiment of the present invention.
  • FIG. 15 is a block diagram of a host mainly showing the internal structure of the host of FIG.
  • 16 is a flow chart of a container creation method according to an embodiment of the present invention.
  • FIG. 17 is a structural diagram showing another host internal structure of FIG. 14;
  • FIG. 18 is a structural diagram briefly showing FIG. 14;
  • FIG. 19 is a network structure diagram of FIG. 18 converted to a legacy virtual router
  • 20 through 23 are signal flow diagrams for packet flows from one container to another.
  • 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.
  • Flow may mean the packet itself to be processed by the switch.
  • Flow may also include a packet to be processed by the corresponding switch and metadata (an inlet port entered by the packet, an inlet port of the other switch when the packet comes in from another switch, etc.).
  • the “flow processing information” is information for processing a packet introduced from a switch, and may mean information necessary for modifying a packet or metadata of a packet and / or a specific network interface (port) through which the packet is leaked.
  • the flow processing information may be the same as the content of the flow entry of the flow table or the content to be applied to the flow entry, and may mean the flow entry itself.
  • Flow processing may mean that the switch processes a packet or a flow based on the flow processing information.
  • FIG. 1 is a block diagram of an SDN network system
  • FIG. 2 is a block diagram of a controller of the network system of FIG. 1
  • FIG. 3 is a block diagram of a switch of the network system of FIG.
  • An operation table showing the operation type according to the field table and the flow entry
  • FIG. 5 is a field table of the group and meter table.
  • 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 block diagram of a network system including an integrated routing system according to an embodiment of the present invention
  • FIG. 7 is a block diagram of a virtualized block diagram of the network system of FIG. 6,
  • FIG. 8 is a diagram illustrating another embodiment of the present invention.
  • 9 is a block diagram of a legacy routing agent according to an embodiment of the present invention.
  • the network shown in FIG. 6 includes an SDN-based network including a controller 10 for controlling the flow of an open flow switch among a switch group consisting of a plurality of switches SW1-SW5, and first to third legacy routers R1-1.
  • the legacy network of R3) is mixed.
  • the SDN-based network means an independent network composed of only an open flow switch or an open flow switch and an existing switch.
  • the SDN-based network is composed of an open flow switch and an existing switch, it is preferable that the SDN-based network is composed of an open flow switch disposed at an edge of the network domain.
  • the SDN-based integrated routing system may include a switch group including first to fifth switches SW1 to SW5, a controller 10, and a legacy routing agent 300. have. Detailed descriptions of the same or similar components refer to FIGS. 1 to 5.
  • the first and third switches SW1 and SW5 which are edge switches connected to an external network among the first to fifth switches SW1 to SW5, are open flow switches that support an open flow protocol.
  • Openflow switches can be physical hardware, virtualized software, or a mix of hardware and software.
  • the first switch SW1 is an edge switch connected to the first legacy router R1 through the eleventh port port 11, and the third switch SW3 is a 32nd and 33rd port 32.
  • port 33 is an edge switch connected to the second and third legacy routers R2 and R3.
  • the switch group may further include a plurality of network devices (not shown) connected to the first to fifth switches.
  • the controller 10 may include a switch communication unit 110, a control unit 100, and a storage unit 190 communicating with the switch 20.
  • the controller 100 of the controller includes a topology management module 120, a path calculation module 125, an entry management module 135, a message management module 130, a message determination module 140, and a legacy interface module 145. can do.
  • Each module may be configured in hardware in the controller 100, or may be configured in software separate from the controller 100. Description of elements of the same reference numerals is made with reference to FIG. 2.
  • 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 can communicate with the legacy routing agent 300.
  • the legacy interface module 145 may transmit the topology information of the switch group established by the topology management module 120 to the legacy routing agent 300.
  • the topology information may include connection relationship information of the first to fifth switches SW1 to SW5 and connection or connection information of a plurality of network devices connected to the first to fifth switches SW1 to SW5.
  • the message management module 130 may transmit the flow to the legacy routing agent 300 through the legacy interface module 145. have.
  • the flow may include a packet received by the open flow switch and port information of the switch that received the packet.
  • the processing rule of the flow cannot be generated, there may be a case in which the received packet is configured by the legacy protocol and cannot be interpreted, and the path calculation module 125 cannot calculate the path for the legacy packet.
  • the legacy routing agent 300 may include an SDN interface module 345, a virtual router generator 320, a virtual router 340, a routing processor 330, and a routing table 335. have.
  • the SDN interface module 345 can communicate with the controller 10. Each of the legacy interface module 145 and the SDN interface module 345 may serve as an interface between the controller 10 and the legacy routing agent 300. The legacy interface module 145 and the SDN interface module 345 may communicate in a specific protocol or in a specific language. The legacy interface module 145 and the SDN interface module 345 may translate or interpret messages exchanged between the controller 10 and the legacy routing agent 300.
  • the virtual router generation unit 320 may generate and manage the virtual router 340 by using topology information of the switch group received through the SDN interface module 345.
  • a switch group may be treated as a legacy router in an external legacy network, that is, the first to third routers R1 to R3.
  • the virtual router generation unit 320 may generate a plurality of virtual routers 340.
  • FIG. 7 (a) shows a case where a virtual legacy router v-R0 is one virtual router 340
  • FIG. 7 (b) shows a case where multiple virtual legacy routers v-R1 and v- have multiple virtual routers 340.
  • the case of R2) is shown.
  • the virtual router generation unit 320 may allow the virtual router 340 to have a router identifier, for example, a lookback IP address.
  • the virtual router generator 320 may allow the virtual router 340 to have virtual router ports corresponding to edge ports of the switch group, that is, edge ports of the first and third edge switches SW1 and SW3.
  • ports of the v-R0 virtual legacy router are ports 11 of the first switch SW1 and ports 32 and 33 of the third switch SW3.
  • the information of (port 32, port 33) can be used as it is.
  • the port of the virtual router 340 may be associated with identification information of the packet.
  • the identification information of the packet may be tag information such as vLAN information of the packet and a tunnel ID added to the packet when connected through a mobile communication network.
  • multiple virtual router ports can be created with one actual port of the OpenFlow edge switch.
  • the virtual router port associated with the identification information of the packet may contribute to allowing the virtual router 340 to operate as a plurality of virtual legacy routers. If you create a virtual router with only physical ports (physical ports) on the edge switch, you are limited by the number of physical ports. However, this restriction is eliminated when associating with packet identification information. It can also behave similarly to the flow of legacy packets in legacy networks. You can also run a virtual legacy router for each user or group of users.
  • the user or user group may be divided into packet identification information such as vLAN or tunnel ID.
  • the switch group is virtualized into a plurality of virtual legacy routers v-R1 and v-R2, and each port vp 11 of the plurality of virtual legacy routers v-R1 and v-R2. 13 and vp 21 to 23 may be associated with identification information of the packet, respectively.
  • the connection between the plurality of virtual legacy routers v-R1 and v-R2 and the legacy router is connected to several sub-interfaces in which one physical interface of the first legacy router R1 is separated. Or like a second and a third legacy router (R2, R3) can be connected to a plurality of real interfaces.
  • the virtual router generation unit 320 may include an external network (vN) in which a plurality of network devices connected to the virtual router 340 are connected to a plurality of network devices connected to the first to fifth switches SW1 to SW5. Can be treated as). This allows legacy networks to access network devices in the OpenFlow Switch Group.
  • the virtual router generation unit 320 generates a 0th port (port 0) in the 0th virtual legacy router v-R0.
  • the virtual router generation unit 320 generates the tenth and twentieth ports vp 10 and vp 20 in the first and second virtual legacy routers v-R1 and v-R2. .
  • Each generated port (port 0, vp 10, vp 20) may have information such as a plurality of network devices connected to the switch group.
  • the external network vN may consist of all or part of a plurality of network devices.
  • the information of the virtual router ports may have port information of the legacy router.
  • the port information for the virtual router may include the MAC address, IP address, port name, network address range to which it is connected, legacy router information, and further include vLAN range, tunnel ID range, and so on.
  • the port information may inherit edge port information of the first and third edge switches SW1 and SW3 or may be designated by the virtual router generation unit 320.
  • the data plane of the network of FIG. 6 by the virtual router 340 generated in the virtual router 340 may be virtualized as shown in FIG. 7 (a) or 7 (b).
  • FIG. 7A in the virtualized network, the first to fifth switches SW1 to SW5 are virtualized to the virtual legacy router v-R0, and the virtualized network of the zeroth virtual legacy router v-R0.
  • Ports 11v, 32v, and 33v are connected to the first to third legacy routers R1 to R3 and the 0th ports of the 0th virtual legacy routers v-R0 port 0) may be connected to an external network (vN) that is at least part of a plurality of network devices.
  • vN external network
  • the routing processor 330 may generate the routing table 335 when the virtual router 340 is generated.
  • the routing table 335 is a table used for referencing routing in legacy routers.
  • the routing table 335 may consist of some or all of RIB, FIB, and ARP tables.
  • the routing table 335 may be modified or updated by the routing processor 330.
  • the routing processor 330 may generate a legacy routing path for the flow inquired by the controller 10.
  • the routing processor 330 uses legacy packets by using some or all of the received packets received from the open flow switch included in the flow, port information into which the received packets are introduced, virtual router 340 information, and the routing table 335. Information can be generated.
  • the routing processor 330 may include a third party routing protocol stack to determine legacy routing.
  • FIG. 10 is a flowchart illustrating a method of determining legacy routing for a flow of the controller of FIG. 6. Reference is made to FIGS. 6 to 9.
  • the legacy routing determination method for the flow means whether the controller 10 should perform general SDN control on the flow received from the open flow switch or should inquire the legacy routing agent 300 for flow control.
  • the controller 10 determines whether the flow inlet port is an edge port (S510). If the flow inlet port is not the edge port, the controller 10 may perform SDN-based flow control, such as calculating a path for a general open flow packet (S590).
  • the controller 10 determines whether the packet of the flow can be interpreted (S520). If the packet cannot be interpreted, the controller 10 may transfer the flow to the legacy routing agent 300 (S550). This is because, in case of a protocol message that a packet uses only in a legacy network, the SDN-based general controller cannot interpret the packet.
  • the SDN-based controller 10 cannot calculate the routing path of the incoming legacy packet. Therefore, if the controller 10 cannot calculate the path, such as legacy packets, the controller 10 should send the legacy packet to the legacy routing agent 300. However, knowing the edge port to be leaked of the legacy packet and the final processing method of the legacy packet, the controller 10 can process the legacy packet through the flow modification. When the packet can be interpreted, the controller 10 searches for the flow path such as whether the path of the flow can be calculated or whether an entry exists in the entry table (S530). If the path cannot be retrieved, the controller 10 may transfer the flow to the legacy routing agent 300 (S550).
  • the controller 10 searches for the flow path such as whether the path of the flow can be calculated or whether an entry exists in the entry table (S530). If the path cannot be retrieved, the controller 10 may transfer the flow to the legacy routing agent 300 (S550).
  • the controller 10 may generate a packet-out message specifying the output of the packet and transmit the packet-out message to the open flow switch inquiring the packet (S540). A detailed example thereof will be described later with reference to FIGS. 11 and 12.
  • FIG. 11 is a signal flow diagram according to the integrated routing method according to an embodiment of the present invention
  • FIG. 12 is a signal flow diagram according to the integrated routing method according to another embodiment of the present invention
  • FIG. 13 is according to an embodiment of the present invention. Flow table. Reference is made to FIGS. 6 to 10.
  • FIG. 11 illustrates a flow of processing legacy protocol messages in an SDN-based network to which the present invention is applied.
  • FIG. 11 illustrates an example of receiving a hello message of an Open Shortest Path First (OSPF) protocol from the first edge switch SW1.
  • OSPF Open Shortest Path First
  • the first legacy router R1 transmits a hello message Hello1 of the OSPF protocol to the first edge switch SW1. It may be (S410).
  • the first edge switch SW1 Since there is no flow entry for the received packet in the table 291 of the first edge switch SW1, the first edge switch SW1 sends a packet-in message to the controller 10 informing of an unknown packet. (S420).
  • the packet-in message preferably includes a flow having a Hello1 packet and incoming port (port 11) information.
  • the message management module 130 of the controller 10 may determine whether to generate a processing rule for the flow (S430). See FIG. 10 for details of the determination method. In this example, since the OSPF protocol message is a packet that cannot be interpreted by the controller 10, the controller 10 may transfer the flow to the legacy routing agent 300 (S440).
  • the SDN interface module 345 of the legacy routing agent 300 may transmit the Hello1 packet received from the controller 10 and the virtual router 340 corresponding to the inlet port port 11 of the first edge switch SW1 provided in the flow. Can be sent to port 11v.
  • the routing processor 330 may generate legacy routing information of the Hello1 packet based on the routing table 335 (S450).
  • the routing processing unit 330 generates a Hello2 message corresponding to the Hello1 message, and designates a routing path for designating an output port as the 11v port so as to transmit the Hello2 packet to the first legacy router R1. Can be generated.
  • the Hello2 message has a destination that is the first legacy router R1 and a predetermined virtual router identifier.
  • the legacy routing information may include a Hello2 packet and an output port which is an eleventh port.
  • the Hello1 packet is introduced into the virtual router 340, but the present invention is not limited thereto.
  • the routing processor 330 may generate legacy routing information using the information of the virtual router 340.
  • the SDN interface module 345 may transfer the generated legacy routing information to the legacy interface module 145 of the controller 10 (S460). Any one of the SDN interface module 345 and the legacy interface module 145 may convert the eleventh port port 11v, which is an output port, into an eleventh port 11 of the first edge switch SW1. Alternatively, port conversion may be omitted by making the names of the eleventh port and the eleventh port the same.
  • the route calculation module 125 of the controller 10 may output the Hello2 packet to the eleventh port port 11 of the first legacy router R1 using the legacy routing information received through the legacy interface module 145.
  • the path may be set (S470).
  • the message management module 130 generates a packet-out message for outputting the Hello2 packet to port 11, which is an incoming port, by using the established route and legacy routing information, and transmits the packet-out message to the first legacy router R1. It may be (S480).
  • the legacy routing agent 300 may generate an OSPF hello message that is actively output to the edge port of the edge switch, and send it to the controller 10.
  • the controller 10 may transmit the hello packet to the openflow switch in a packet-out message.
  • the present embodiment can be implemented by setting the OpenFlow switch to follow the instruction of the packet-out message even for a packet-out message that does not correspond to the packet-in message.
  • FIG. 12 illustrates a case where a general legacy packet is transmitted from the first edge switch SW1 to the third edge switch SW3.
  • the first edge switch SW1 starts by receiving a legacy packet P1 whose destination IP address does not belong to the openflow switch group from the first legacy router R1 (S610).
  • the first edge switch SW1 may transmit the packet P1 to the controller 10 and inquire of a flow process (packet-in message) (S620).
  • a flow process packet-in message
  • the message management module 130 of the controller 10 may determine whether SDN control of the flow is possible (S630). In this example, the packet P1 is interpretable but directed towards the legacy network, so the controller 10 cannot create a path for the packet P1. Accordingly, the controller 10 may transmit the packet P1 and the eleventh port, which is an incoming port, to the legacy routing agent 300 through the legacy interface module 145 (S640).
  • the routing processing unit 330 of the legacy routing agent 300 generates the legacy routing information of the packet P1 with respect to the packet P1 received from the controller 10 based on the information of the virtual router 340 and the routing table 335. Can be (S650). In this example, it is assumed that packet P1 should be output to port 32v of the virtual router.
  • the legacy routing information includes an output port that is a 32v port (port 32v) for the packet P1, a destination MAC address that is a MAC address of the second legacy router R2, and a source MAC that is a MAC address of the 32v port. May contain an address. This information is header information of the packet output from the legacy router.
  • the header information of the packet P1 is as follows. Since the source and destination IP addresses are the same as the header information when the packet P1 is generated, they will be omitted in this description.
  • the source MAC address of the packet P1 is the MAC address of the output port of the router R1.
  • the destination MAC address of the packet P1 is the MAC address of the eleventh port port 11v of the virtual legacy router v-R0. If the existing router, the packet P1 'output to the 32v port (port 32v) of the virtual legacy router (v-R0) may have the following header information.
  • the source MAC address of the packet P1 ' is the MAC address of the 32v port (port 32v) of the virtual legacy router (v-R0), and the destination MAC address is the MAC address of the inlet port of the second legacy router. That is, part of the header information of the packet P1 is changed during legacy routing.
  • the routing processor 330 may generate the packet P1 ′ in which the header information of the packet P1 is adjusted and include it in the legacy routing information.
  • the routing processing unit 330 does not generate the packet P1 'which changes the header information of the packet P1.
  • the controller 10 or the legacy routing agent 300 must process the incoming packet for the same packet or a similar packet having the same destination address range each time. Therefore, the step of transforming the packet into the format after the existing routing is performed by the packet switch at the edge switch (in this example, the third edge switch SW3) which outputs the packet to the external legacy network rather than the legacy routing agent 300. It is preferable.
  • the legacy routing information described above may include a source and a destination MAC address.
  • the controller 10 may use the routing information to transmit a flow-mod message to change the header information of the packet P1 to the third edge switch.
  • the SDN interface module 345 may transfer the generated legacy routing information to the legacy interface module 145 of the controller 10 (S660). In this step, the output port can be converted to an edge port to be mapped.
  • the controller 10 may generate a flow processing rule inside the openflow switch group by using the legacy routing information received through the legacy interface module 145, in particular, the legacy path of the legacy routing information.
  • the path calculation module 125 of the controller 10 may calculate a path to be output from the first edge switch SW1 to the 32nd port of the third edge switch SW3 by using the legacy path (S670).
  • the message management module 130 transmits a packet-out message specifying an output port for the packet P1 to the first edge switch SW1 based on the calculated path (S680) and flows to the openflow switch of the corresponding path.
  • a change (flow-Mod) change message may be transmitted (S690 and S700).
  • the message management module 130 may also transmit a flow-mod message to define the processing for the same flow to the first edge switch SW1.
  • the flow entry according to the flow processing rule is preferably based on an identifier identifying that it is a data-packet corresponding to the flow managing the path of the packet P1. That is, the flow processing for the packet P1 is preferably performed based on the identifier for identifying the legacy flow.
  • the packet-out message transmitted to the first edge switch SW1 includes a packet P1 to which a legacy ID is added, and the flow change message includes a flow entry for adding a legacy ID to the packet-out message. It can be included. See FIG. 13 for an example of a flow table of each switch.
  • FIG. 13A is a flow table of the first edge switch SW1. For example, Table 0 of FIG.
  • 13 (a) adds tunnel2 to the flow with a legacy identifier to the flow destined for the second legacy router R2 and moves the flow to Table 1.
  • Legacy identifiers may be written in metafields or other fields.
  • Table 1 has a flow entry for outputting the flow having tunnel2 to the 14th port (port information of the first switch SW1 connected to the fourth switch SW4).
  • 13B is an example of a flow table of the fourth switch SW4.
  • the table of FIG. 13 (b) allows the flow having the legacy identifier of tunnel2 to be output to port 43 connected to the third switch SW3.
  • 13C is an example of a flow table of the third switch SW3.
  • Table 0 of FIG. 13C removes the legacy identifier of the flow whose legacy identifier is tunnel2 and moves the flow to Table 1.
  • FIG. Table 1 outputs the flow to the 32nd port. Using multiple tables in this way can reduce the number of cases. This enables quick searching and can reduce resource consumption such as memory.
  • the first edge switch SW1 may add a legacy ID (tunnel ID) to the packet P1 (S710) or transmit a packet to which the legacy ID (tunnel ID) is added to the core network (S720).
  • the core network refers to a network composed of open flow switches SW2, SW4, and SW5, not edge switches SW1 and SW3.
  • the core network may transmit the flow to the third edge switch SW3 (S730).
  • the third edge switch SW3 may remove the legacy identifier and output the packet P1 to the designated port (S740).
  • the flow table of the third switch SW3 preferably includes a flow entry for changing the destination and source MAC addresses of the packet P1.
  • FIG. 14 is a structural diagram showing a container network management system according to an embodiment of the present invention
  • FIG. 15 is a block diagram of a host mainly showing the internal structure of the host of FIG. 14, and
  • FIG. 16 is an embodiment of the present invention.
  • 17 is a structural diagram illustrating another host internal structure of FIG. 14,
  • FIG. 18 is a schematic diagram of FIG. 14, and
  • FIG. 19 is a network structural diagram of FIG. 18 converted to a legacy virtual router. to be. See FIGS. 1 to 13.
  • the container network management system includes an orchestrator 1, a controller 10, a legacy routing agent 300, and a plurality of hosts 800-1 and 800-2; Or to specify all).
  • the orchestrator 1 allows container creation / deletion to each host 800-1 and 800-2 according to a user request or policy, controls the internal network environment, and controls each host 800-1 and 800-2. Manage networks between containers.
  • the orchestrator 1 may control each host 800-1 and 800-2 through the controller 10.
  • the legacy routing agent 300 may generate legacy routing information of the corresponding packet and transmit the packet to the controller 10. If necessary, the legacy routing agent 300 may generate legacy protocol conversion information for the packet to conform to the legacy protocol or convert the packet to conform to the legacy protocol.
  • Legacy protocols include legacy routing protocols.
  • the generated routing information or protocol conversion information may be stored as a table in the controller 10 or each host 800-1 and 800-2, in which case the controller 10 processes the packet to the legacy routing agent 300. There is no need to contact.
  • the host 800 may provide an SDN-based virtual switch and container.
  • the host 800 may be a server having a physically based computing function, but is not limited thereto.
  • the host 800 includes a host controller 810, an SDN-based virtual switch 820 (vSW), a container bridge 830, a container 840, a host storage unit 860 (DB), And real network interfaces 850 and 852.
  • the host storage unit 860 may store a program for processing and controlling the host controller 810.
  • the host storage unit 860 may store bridge net information and container net information, which will be described later, in a DB format list.
  • the host storage unit 860 may store data necessary for the virtual switch 820 or store various identifiers.
  • the host controller 810 may control the operation of each element of the host 800 to control the overall operation of the host 800.
  • the host controller 810 may generate a virtual switch 820, a container bridge 830, and a container 840.
  • the host controller 810 may network couple the virtual switch 820, the container bridge 830, the container 840, and the like so that the network can be networked with each other.
  • the host controller 810 may exchange data with the controller 10 and / or the external public network 5 (eg, the 'Internet') through the first and second physical network interfaces 850 and 852. .
  • the first and second real network interfaces 850 and 852 may be implemented as one network interface.
  • the virtual switch 820 may correspond to the switch 20 of FIG. 1.
  • the virtual switch 820 may correspond to an edge switch in particular of the switch group of FIG. 6.
  • the virtual switch 820 may be virtually generated by the host controller 810.
  • the virtual switch 820 may exchange a message with the controller 10 through the first physical network interface 850.
  • the virtual switch 820 may exchange packets with the external network 5 through the second physical network interface 852.
  • the second physical network interface 852 can operate like the network interface of the virtual switch 820.
  • the virtual switch 820 may perform an L2 / L3 network between containers within the same host and / or between each container of another host.
  • the container bridge 830 is generated by the host controller 810 and may serve as a bridge between containers in the same server (host).
  • the container bridge 830 may serve as a hub, a bridge, and / or a switch among existing network equipment.
  • the container bridge 830 may perform an L2 network function between containers.
  • Container bridge 830 may include routing between containers belonging to different domains (networks), networks with containers belonging to different hosts, when the destination of packets is associated with virtual switch 820, and / or incoming packets from containers. If there is no processing information, the incoming packet from the container may be transmitted to the virtual switch 820.
  • the container bridge 830 may be virtually network coupled with the virtual NI 821 of the virtual switch 820 via a bridge-switch NI (Network Interface) 832.
  • the container bridge 830 may be network coupled with the virtual NI 841 of the container 840 via the bridge-container 831.
  • Container bridge 830 may have a bridge identifier that identifies itself.
  • the bridge identifier may distinguish the sub network environment established by the container bridge 830 from other network environments.
  • the bridge identifier may be connected with network subnet information and gateway information.
  • Network subnet information is needed for the IP address to be assigned to the container 840, and gateway information is needed for routing.
  • the gateway information may initially have information (IP address, Mac address, etc.) for the second real network interface 852 connected with the external network 5 by default.
  • Network subnet information and gateway information connected based on the bridge identifier may be DBized as bridge net information.
  • the network subnet information may be provided with a plurality of pieces of information such that two or more sub networks are established.
  • the plurality of network subnet information may be divided into domain tags to be described later.
  • the container 840 is a kind of virtual machine in which applications operate independently, but unlike the existing virtual machine, the container 840 is a kind of lightweight virtual machine that can operate lighter than the virtual machine by sharing an OS.
  • the container 840 may provide one or more services.
  • the container 840 may establish an independent network environment on the OS, and configure a network topology through a virtual interface in the network environment. If the OS is Linux, an independent network environment can be implemented with namespace technology.
  • the invention relates in particular to a method of networking between containers 840.
  • Container 840 has a container identifier.
  • the container 840 may inherit the bridge identifier of the upper container bridge 830.
  • the container 840 may have the same domain identifier indicating the same domain.
  • the container 840 has an IP address, and the IP address may be generated based on the bridge net information by a DHCP server (not shown).
  • the DHCP server is preferably located outside the host 800. This is because you need to generate an IP address for other hosts.
  • the DHCP server may be implemented virtually, in which case the DHCP server may be created inside the controller 10 and / or the legacy routing agent 300. Using the container identifier as a key, the IP address and the same domain identifier may be stored as a container net information list.
  • the container bridge 830 may designate the domain tag corresponding to the same domain identifier to the bridge-container NI 831 based on the same domain identifier of the container 840.
  • the same domain identifier and the domain tag may be the same.
  • the container bridge 830 may tag a tag designated to the bridge-container NI 831 to which the packet flows in a packet flowing from the container 840.
  • the domain tag may use packet fields such as vLAN, vxLAN, or metadata.
  • Container bridge 830 may leak the packet to a domain-tagged bridge-container NI 831 tagged with the packet. As a result, the container bridge 830 may provide container communication in the same host and the same network. As a result, unnecessary broadcast or multicast traffic can be reduced. Outgoing and / or outgoing packets at the bridge-switch NI 832 of the container bridge 830 may go in and out regardless of the domain tag of the outgoing packet.
  • Bridge-container NI 831 and bridge-switch NI 832 may each have an associated MAC address.
  • the bridge-container NI 831 may use the ARP protocol or know the MAC address of each container from the information received from the controller 10.
  • the MAC information received from the controller 10 may be obtained from container net information previously stored as a member of the list.
  • the bridge-switch NI 832 may have the MAC address of the gateway (the second physical network interface 852 or the virtual Mac address, described below), and the MAC address of a container belonging to the same domain of another host.
  • the container bridge 830 may exit the incoming packet to the appropriate NI of the bridge-container NI 831 and the bridge-switch NI 832 through the destination MAC address of the incoming packet. If none of the bridge-container NI 831 and bridge-switch NI 832 is associated with the MAC address of the incoming packet, then the container bridge 830 may exit the incoming packet to the bridge-switch NI 832.
  • the host controller 810 may generate a virtual switch 820 (S900).
  • the virtual switch 820 may be generated when the host 800 is booted, or may be generated when the container creation message or the container bridge creation message is received from the orchestrator 1 or the controller 10.
  • the host controller 810 may include the virtual switch 820 and the second physical network interface 852 so that the virtual switch 820 may exchange packets with the external network 5 through the second physical network interface 852. Can be connected (S905).
  • the host controller 810 may generate the container bridge 830 (S910).
  • the container bridge creation message may include a bridge identifier, gateway information, and network subnet information. If there is an identical bridge identifier, the host controller 810 may transmit a failure message to the controller 10.
  • the network subnet information may establish sub-networks equal to or greater than the number of domain tags.
  • the plurality of subnet information for constructing two or more sub-networks may be associated with a domain tag or the same domain identifier.
  • the container bridge generation message may further include the same domain identifier (or domain tag) list. Elements of the domain tag list and each of the plurality of subnet information of the network subnet information are associated with each other.
  • the host controller 810 may network couple the virtual NI of each of the virtual switch 820 and the container bridge 830 (S915).
  • the packet may be forwarded from the container bridge 830 to the virtual switch 820 regardless of its domain tag.
  • the host controller 810 may generate a container 840 (S930).
  • the container creation message may include a bridge identifier, a container identifier, and the same domain identifier.
  • the host controller 810 may process an error when the same container identifier exists or the bridge identifier does not exist.
  • the host controller 810 may allocate a unique IP address to the container 840 using the DHCP function (S935).
  • the host controller 810 may network couple the container bridge 830 and the container 840 (S840).
  • the host controller 810 may designate a domain tag associated with the same domain identifier of the container 840 to the bridge-container NI 831 (S845).
  • the host 800 may be implemented in an embodiment having various virtual switches and container bridges. Referring to FIG. 17, two container bridges may be provided in one virtual switch like the first host 800-3 or two virtual switches may be provided like the third host 800-5. The first and third hosts 800-3 and 800-5 may be treated like the second host 800-4. This may be implemented by configuring a connection structure between the bridge-switch NI 832 and the virtual NI 821 of the virtual switch 820 as a trunk structure or a plurality of subchannels. You can also control two or more hosts as if they were one host.
  • Two or more hosts are connected to other external switches, such as the first host (800-3) and the second host (800-4), or the second host (800-4) and the third host (800-5) It can be connected through tunneling across other networks, such as:
  • the other network may be the same as the external network 5 connected to the second host 800-4.
  • the virtual switch vSW not directly connected to the external network 5 of FIG. 17 may correspond to a switch constituting the core network of FIG. 6.
  • the first and second hosts h1 and h2 are connected through one legacy router R0, and the first host h1 is connected to the first virtual switch vSW1 and the first container bridge CT.Br.1. ), And first to third containers ct1, ct2, and ct3, and the second host h2 includes a second virtual switch vSW2, a second container bridge CT.Br.2, and a fourth To fifth containers ct4 and ct5.
  • the domain tag will use vLAN, and the first, second, and fourth containers (ct 1, 2, 4) are connected to the bridge-container NI with vLAN 100, respectively, and the third and fifth containers (ct3). ct5) are each connected to a bridge-container NI with vLAN 200.
  • the first and second hosts h1 and h2 of FIG. 17 may be interpreted by the legacy routing agent 300 as a topology structure as shown in FIG. 19 in the legacy router R0.
  • the first and second hosts h1 and h2 are virtual ports 1-0 and 2-0 virtual routers (vR.), Each of which has a physical network interface connected to the legacy router R0 as a virtual port, as shown in FIG. I.0, vR.II.0) or first-first, first-second, second-first, and second-second virtual routers generated by domain tags as shown in FIG. 19 (b).
  • the first to fifth containers ct1 to ct5 may correspond to the external network vN of FIG. 7.
  • Virtual port information (P.vR.I.0, P.vR.) connected to the legacy router (R0) of the 1-0 and 2-0 virtual routers (vR.I.0, vR.II.0). II.0) preferably comprises the actual network interfaces (IP address and MAC address) of the first and second hosts h1 and h2, respectively.
  • the virtual port information (P.vR.I.1, P.vR.I.2, P.vR.II.1, P.vR.II.2) connected to the router R0 has a virtual MAC address. It is preferable to have an IP address having the same network as the legacy router R0.
  • FIGS. 20 through 23 are signal flow diagrams for packet flows from one container to another. Reference is made to FIGS. 1 to 19, in particular FIGS. 14 to 19.
  • FIGS. 1 to 19 the network topology structure of FIG. 18 is assumed and described with reference to FIG. 19A.
  • each container, container bridge, and / or virtual switch knows the MAC address of an ARP message or controller 10 (ctr) from another container belonging to the same domain, and assumes that the container has only one virtual port. do.
  • FIG. 20 illustrates a packet flow from a first container ct1 belonging to the same host and the same domain to a second container ct2. Since the first and second containers ct1 and ct2 belong to the same domain, the first packet pk1 generated by the first container ct1 is the IP of the second container ct2 and the aerosols a2 and m2. Has the destination IP and MAC address.
  • the first container ct1 may transfer the first packet pk1 to the first container bridge CT.Br. 1 (S1010). Since the first container bridge CT.Br. 1 knows the bridge-container NI associated with the beer yard m2, the first container bridge CT.Br.1 may directly transfer the first packet pk1 to the second container ct2 (S1020).
  • FIG. 21 illustrates packet flow from a first container ct1 belonging to the same host and a heterogeneous domain to a third container ct3. Since the first and third containers ct1 and ct3 belong to different domains, the first container ct1 converts the MAC address of the destination into a gateway address, that is, the MAC address of the actual network interface of the first host h1 (m. A second packet pk2 of h1) can be generated. The first container ct1 may transfer the generated second packet pk2 to the first container bridge CT.Br. 1 (S1110).
  • the first container bridge CT.Br.1 may tag the domain tag 100 associated with the first container ct1 to the vLAN field (S1115).
  • the first container bridge CT.Br.1 is a second packet (pk2 [100]) having a vLAN of 100 to the first virtual switch vSW1 through the bridge-switch NI associated with the gateway, ie, m.h1. It may be delivered (S1120).
  • the first virtual switch vSW1 may determine whether there is a flow entry of the destination IP address of the second packet pk2 [100]. If there is no flow entry, the first virtual switch vSW1 may transmit a second packet pk2 [100] to the controller 10 to request flow processing information (S1130).
  • Step S1135 may be performed at the first virtual switch vSW1.
  • the first container bridge CT.Br.1 may remove the vLAN information of the second packet pk2 and then transfer it to the second container ct2.
  • FIG. 22 illustrates a packet flow from a heterogeneous host and a first container ct1 belonging to the same domain to a fourth container ct4. Since the first and fourth containers ct1 and ct4 belong to the same domain, the first container ct1 receives the third packet pk3 whose MAC address of the destination is the MAC address m4 of the fourth container ct4. Can be generated. The first container ct1 may transfer the generated third packet pk3 to the first container bridge CT.Br. 1 (S1210).
  • the first container bridge CT.Br.1 may tag the domain tag 100 associated with the first container ct1 in the vLAN field.
  • the MAC address learning of the fourth container ct4 is not performed in the first container bridge CT.Br.1 or the MAC address m4 is bridged through the MAC address learning or information received from the controller 10.
  • the switch NI is specified, the outgoing port of the packet becomes the bridge-switch NI. Accordingly, the first container bridge CT.Br.1 transmits the third packet pk3 through the bridge-switch NI to the first virtual switch vSW1 with the third packet pk3 [100]. Can be delivered (S1215).
  • the first virtual switch vSW1 may determine whether there is a flow entry of the destination IP address of the third packet pk3 [100]. If there is no flow entry, the first virtual switch vSW1 may transmit a third packet pk3 [100] to the controller 10 to request flow processing information (S1220).
  • the controller 10 knows the network information of the second container ct2. Accordingly, the controller 10 may convert the third packet pk3 into a domain tag associated with the domain identifier to which the second container belongs (S1225). Since the third packet pk3 will be delivered to the external network 5, it is preferable to designate another vLAN even in the same domain. However, the third packet pk3 may maintain the original vLAN.
  • the controller 10 determines whether there is legacy protocol conversion information of the third packet pk3, and if not, the controller 10 transmits the legacy packet to the legacy routing agent 300. 3 packets (pk3 [10]) can be delivered (S1230).
  • the legacy routing agent 300 converts the destination MAC address of the third packet pk3 [10] into the MAC address (m.R1) of the network interface of the legacy router R9 connected with the first host h1, and the source The MAC address may be converted into a MAC address (m.h1) of the actual network interface of the first host (S1235). This step may be performed in the controller 10 or the first virtual switch vSW1.
  • the converted third packet pk3 [10] may be delivered to the controller 10 and the first virtual switch vSW1 (S1240 and S1245), and may be delivered from the first virtual switch vSW1 to the legacy router R0. There is (S1250).
  • the legacy router R0 connects the destination and source MAC address of the third packet pk3 with the MAC address m.h2 of the actual network interface of the second host h2 and the second host of the legacy router R0. Can be converted into the MAC address (m.R2) of the interface (S1255).
  • the legacy router R0 may transmit the third packet pk3 [10] to the second virtual switch vSW2 (S1260).
  • the second virtual switch vSW2 converts the domain tag (vLAN is 100) associated with vLAN 10, which is the domain tag of the third packet pk3, and converts the destination / source MAC address from (m.h2 / m.R2) to ( m2 / m1) (S1265).
  • the converted third packet pk3 [100] may be transmitted from the second virtual switch vSW2 to the fourth container ct4 through the second container bridge CT.Br.2 (S1270). S1275).
  • FIG. 23 illustrates a packet flow from a first container ct1 belonging to a heterogeneous host and a heterogeneous domain to a fifth container ct5. Since the first and fifth containers ct1 and ct5 belong to different domains, the first container ct1 converts the MAC address of the destination into a gateway address, that is, the MAC address of the actual network interface of the first host h1 (m. A fourth packet pk4 referred to as h1) can be generated. The first container ct1 may transfer the generated fourth packet pk4 to the first container bridge CT.Br. 1 (S1310).
  • the first container bridge CT.Br.1 may tag the domain tag 100 associated with the first container ct1 in the vLAN field.
  • the first container bridge CT.Br.1 is a fourth packet (pk4 [100]) having a vLAN of 100 to the first virtual switch vSW1 through the bridge-switch NI associated with the gateway, ie, m.h1. Can be delivered (S1315).
  • the first virtual switch vSW1 may determine whether there is a flow entry of the destination IP address of the fourth packet pk4 [100]. If there is no flow entry, the first virtual switch vSW1 may transmit a fourth packet pk4 [100] to the controller 10 in order to request flow processing information (S1320).
  • the controller 10 knows the network information of the fifth container ct5. Accordingly, the controller 10 may convert the domain tag of the fourth packet pk4 into a domain tag associated with the domain identifier to which the fifth container ct5 belongs (S1325). Since the fourth packet pk4 will be delivered to the external network 5, it is preferable to designate another vLAN even in the same domain. It is also desirable to use domain tags to distinguish them from packets that are homogeneous hosts and homogeneous domains. For example, if the source container of the packet to the fifth container ct5 is in the same domain as the fifth container ct5, the vLAN value of the fourth packet pk4 is set to 20, and in the heterogeneous domain, the fourth packet pk4 is used. ) Can be set to 21. Since the first and fifth containers ct1 and ct5 are heterogeneous domains, the controller 10 may convert the domain tag of the fourth packet pk4 to 21.
  • the controller 10 determines whether there is legacy protocol conversion information of the third packet pk3, and if not, the third packet pk3 is transmitted to the legacy routing agent 300. pk3 [10]) (S1330).
  • the legacy routing agent 300 converts the destination MAC address of the third packet pk3 [10] into the MAC address (m.R1) of the network interface of the legacy router R9 connected with the first host h1, and the source The MAC address may be converted into a MAC address (m.h1) of the actual network interface of the first host (S1335). This step may be performed in the controller 10 or the first virtual switch vSW1.
  • the converted fourth packet pk4 [21] may be delivered to the controller 10 and the first virtual switch vSW1 (S1340 and S1345), and may be delivered from the first virtual switch vSW1 to the legacy router R0. There is (S1350).
  • the legacy router R0 may connect the destination and source MAC addresses of the fourth packet pk4 with the MAC address m.h2 of the actual network interface of the second host h2 and the second host of the legacy router R0.
  • the MAC address of the interface (m.R2) can be converted (S1355).
  • the legacy router R0 may transmit the fourth packet pk4 [21] to the second virtual switch vSW2 (S1360).
  • the second virtual switch vSW2 converts the domain tag (vLAN is 200) associated with vLAN 21, which is the domain tag of the fourth packet pk4, and converts the destination / source MAC address from (m.h2 / m.R2) to ( m2 / m.h1) (S1365).
  • the converted fourth packet pk4 [200] may be transmitted from the second virtual switch vSW2 to the fifth container ct5 through the second container bridge CT.Br.2 (S1370). S135).
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un système de gestion de réseau conteneur à base de réseau défini par logiciel (SDN) et un procédé de mise en réseau conteneur d'un réseau conteneur, le système de gestion de réseau conteneur et le procédé de mise en réseau conteneur activant un réseau L2/L3 entre conteneurs, ce qui permet de réduire les trafics inutiles de multidiffusion et de radiodiffusion, et de permettre une flexibilité d'exploitation du réseau. Le système de gestion peut comprendre : une véritable interface réseau connectée à un réseau existant; un commutateur virtuel à base de SDN destiné à émettre/recevoir un paquet vers/depuis le réseau existant par l'intermédiaire de la véritable interface réseau; une unité de commande hôte destinée à générer le commutateur virtuel; un pont de conteneur généré par l'unité de commande hôte, couplé virtuellement en réseau au commutateur virtuel par l'intermédiaire d'une interface réseau (NI) pont-commutateur, et ayant un identificateur de pont lui permettant de s'identifier; et un premier hôte généré par l'unité de commande hôte, permettant à une adresse IP unique d'être attribuée sur la base des informations de réseau du pont, et comprenant une pluralité de conteneurs couplés virtuellement en réseau au pont de conteneur.
PCT/KR2016/002924 2016-01-25 2016-03-23 Système de gestion de réseau conteneur et procédé de mise en réseau conteneur Ceased WO2017131285A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2016-0008996 2016-01-25
KR10-2016-0008995 2016-01-25
KR1020160008995A KR101797112B1 (ko) 2016-01-25 2016-01-25 컨테이너 네트워크 관리 시스템
KR1020160008996A KR101797115B1 (ko) 2016-01-25 2016-01-25 컨테이너 네트워크의 컨테이너 네트워킹 방법

Publications (1)

Publication Number Publication Date
WO2017131285A1 true WO2017131285A1 (fr) 2017-08-03

Family

ID=59398231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/002924 Ceased WO2017131285A1 (fr) 2016-01-25 2016-03-23 Système de gestion de réseau conteneur et procédé de mise en réseau conteneur

Country Status (1)

Country Link
WO (1) WO2017131285A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109495594A (zh) * 2017-09-11 2019-03-19 华为技术有限公司 一种数据传输方法、pnf sdn控制器、vnf sdn控制器及系统
CN111556136A (zh) * 2020-04-26 2020-08-18 全球能源互联网研究院有限公司 一种电力边缘物联代理内部容器间的数据交互方法
CN111654559A (zh) * 2020-05-29 2020-09-11 深圳前海微众银行股份有限公司 一种容器数据传输方法及装置
CN113067739A (zh) * 2021-04-29 2021-07-02 中国工商银行股份有限公司 一种高密度容器网络部署方法及系统
CN114257473A (zh) * 2021-12-10 2022-03-29 北京天融信网络安全技术有限公司 资源池中多个透明桥的实现方法、装置、设备和介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130058250A1 (en) * 2010-07-06 2013-03-07 Martin Casado Hierarchical managed switch architecture
US20140115706A1 (en) * 2012-10-19 2014-04-24 ZanttZ,Inc. Network infrastructure obfuscation
US20140201374A1 (en) * 2013-01-11 2014-07-17 Futurewei Technologies, Inc. Network Function Virtualization for a Network Device
US20150263899A1 (en) * 2014-03-14 2015-09-17 Nicira, Inc. Managed gateways peering with external router to attract ingress packets
US20150370586A1 (en) * 2014-06-23 2015-12-24 Intel Corporation Local service chaining with virtual machines and virtualized containers in software defined networking

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130058250A1 (en) * 2010-07-06 2013-03-07 Martin Casado Hierarchical managed switch architecture
US20140115706A1 (en) * 2012-10-19 2014-04-24 ZanttZ,Inc. Network infrastructure obfuscation
US20140201374A1 (en) * 2013-01-11 2014-07-17 Futurewei Technologies, Inc. Network Function Virtualization for a Network Device
US20150263899A1 (en) * 2014-03-14 2015-09-17 Nicira, Inc. Managed gateways peering with external router to attract ingress packets
US20150370586A1 (en) * 2014-06-23 2015-12-24 Intel Corporation Local service chaining with virtual machines and virtualized containers in software defined networking

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109495594A (zh) * 2017-09-11 2019-03-19 华为技术有限公司 一种数据传输方法、pnf sdn控制器、vnf sdn控制器及系统
US11265244B2 (en) 2017-09-11 2022-03-01 Huawei Technologies Co., Ltd. Data transmission method, PNF SDN controller, VNF SDN controller, and data transmission system
CN111556136A (zh) * 2020-04-26 2020-08-18 全球能源互联网研究院有限公司 一种电力边缘物联代理内部容器间的数据交互方法
CN111556136B (zh) * 2020-04-26 2022-08-30 全球能源互联网研究院有限公司 一种电力边缘物联代理内部容器间的数据交互方法
CN111654559A (zh) * 2020-05-29 2020-09-11 深圳前海微众银行股份有限公司 一种容器数据传输方法及装置
CN111654559B (zh) * 2020-05-29 2023-04-07 深圳前海微众银行股份有限公司 一种容器数据传输方法及装置
CN113067739A (zh) * 2021-04-29 2021-07-02 中国工商银行股份有限公司 一种高密度容器网络部署方法及系统
CN113067739B (zh) * 2021-04-29 2022-08-30 中国工商银行股份有限公司 一种高密度容器网络部署方法及系统
CN114257473A (zh) * 2021-12-10 2022-03-29 北京天融信网络安全技术有限公司 资源池中多个透明桥的实现方法、装置、设备和介质
CN114257473B (zh) * 2021-12-10 2022-10-21 北京天融信网络安全技术有限公司 资源池中多个透明桥的实现方法、装置、设备和介质

Similar Documents

Publication Publication Date Title
CN102271082B (zh) 用于设置虚拟局域网的交换装置和方法
WO2020130158A1 (fr) Système de réseau fronthaul ouvert
WO2017131285A1 (fr) Système de gestion de réseau conteneur et procédé de mise en réseau conteneur
KR20160121087A (ko) Sdn 기반의 통합 라우팅 방법 및 그 시스템
WO2022019720A1 (fr) Procédé de commande d'accélération du réseau de plate-forme périphérique et dispositif électronique l'utilisant
WO2014209075A1 (fr) Système et procédé multi-connexion pour exécuter des services au moyen du protocole internet
WO2021141291A1 (fr) Procédé et appareil de collecte de trafic réseau dans un système de communication sans fil
WO2017122849A1 (fr) Système de réseau de l'internet des objets
WO2015030491A1 (fr) Procédé de fourniture de bande passante sur la base d'un groupement de plusieurs flux
EP2928122B1 (fr) Dispositif de commutation, procédé et programme de gestion de configuration d'un vlan
WO2016148527A1 (fr) Procédé et appareil de génération d'un paquet dans un système de communications mobiles
KR101797112B1 (ko) 컨테이너 네트워크 관리 시스템
KR101797115B1 (ko) 컨테이너 네트워크의 컨테이너 네트워킹 방법
WO2015080525A1 (fr) Procédé et appareil destinés à la régulation dynamique du trafi dans un environnement sdn
KR20180058594A (ko) Sdn/tap 어플리케이션
WO2011136538A2 (fr) Procédé et appareil de transmission de données ethernet par l'intermédiaire d'une interface audio/vidéo
WO2020027378A1 (fr) Contrôleur sdn basé sur un réseau défini par logiciel, et système d'ingénierie de trafic et procédé d'ingénierie de trafic l'utilisant
WO2015065003A1 (fr) Procédé de contrôle de qos via une gestion de trafic dépendant du service
KR20180058593A (ko) Sdn 화이트박스 스위치
KR20180058592A (ko) Sdn 제어기
US10574481B2 (en) Heterogeneous capabilities in an overlay fabric
KR20180087561A (ko) 동적 가상망 서비스를 제공하기 위한 시스템 인터페이스
JP2017175522A (ja) ネットワークシステム、制御装置、方法およびプログラム
WO2017122847A1 (fr) Procédé pour système de réseau sdn prenant en charge une pluralité de locataires, et système associé
WO2017122848A1 (fr) Système de réseau basé sdn pour prendre en charge une pluralité de locataires, et procédé de prise en charge d'une pluralité de locataires

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: 16888261

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: 16888261

Country of ref document: EP

Kind code of ref document: A1