KR101621720B1 - Method, apparatus and computer program for providing multipoint communication service of software defined data center by software switch - Google Patents

Abstract

The present invention relates to a computer program which is stored in a medium in order to execute a process in which a server which implements a software switch inside a software defined data center (SDDC) environment transmits a frame to multiple points. The computer program executes the functions of: receiving, by a first software switch, a frame, whose destination is a plurality of virtual machines, from a first virtual machine; and, when all software switches connected to the respective destination virtual machines are included in the same L2 network as the first software switch, copying a frame immediately before which an MAC header including tenant ID information is added a number of times equal to the number of destination virtual machines.

Description

METHOD, APPARATUS AND COMPUTER PROGRAM FOR PROVIDING MULTIPOINT COMMUNICATION SERVICE OF SOFTWARE DEFINED DATA CENTER BY SOFTWARE SWITCH,

The present invention relates to a method for implementing network virtualization in a software defined data center (SDDC) environment. More particularly, the present invention relates to a method, apparatus, and computer program for efficiently configuring tunneling for data transmission in an SDDC environment and providing a multi-point communication service.

Recently, 'software defined' technology is making new changes throughout the data center components. Software Defined Data Center (SDDC), a software-defined data center, is a concept that virtualizes servers, storage, and networking that make up a data center, thereby isolating hardware from computing resources and building a data center.

Software Defined Network (SDN), on the other hand, solves network problems that have been a problem with server virtualization in SDDC and provides structural flexibility. Software-defined network technology separates the complexity of the control plane from the data plane, processing the complex functions of the control plane with software, and the data plane is the control plane So that only a simple function of the instruction is performed. With these changes, software can develop new network functions without complex hardware constraints, while at the same time making various attempts that were not possible with previous network architectures.

The present invention aims at efficiently implementing network virtualization in an SDDC environment. In particular, it is an object of the present invention to provide a method for reducing network resources consumed in tunneling and multipoint communication in an SDDC virtual network.

A method for multipoint transmission of a frame by a server implementing a software switch in a Software Defined Data Center (SDDC) environment according to an embodiment of the present invention includes transmitting a frame having a plurality of virtual machines as a destination Receiving a first software switch from the first virtual machine; And all the software switches connected to each of the destination virtual machines are included in the same L2 network as the first software switch, the MAC header including the LAN ID information is added to the frame immediately before the frame to the number of the destination virtual machines And a step of copying.

Further, a computer program stored on a medium for executing a process of multipoint transfer of a frame by a server implementing a software switch in a software defined data center (SDDC) environment according to an embodiment of the present invention includes a plurality of virtual A function of a first software switch receiving a frame from the first virtual machine with the machine as a destination; And all the software switches connected to each of the destination virtual machines are included in the same L2 network as the first software switch, the MAC header including the LAN ID information is added to the frame immediately before the frame to the number of the destination virtual machines And a copying function is executed.

Meanwhile, a server implementing a software switch for broadcasting a frame in a Software Defined Data Center (SDDC) environment according to an embodiment of the present invention includes: a communication unit for connecting a physical network to the software switch; And to control the first software switch to receive from the first virtual machine a frame with a plurality of virtual machines as a destination, and wherein all software switches connected to each of the destination virtual machines are connected to the same L2 network The control unit controls to copy the frame added immediately before the frame with the Mac header including the current ID information by the number of the destination virtual machines.

According to the present invention, the size of the header for tunneling in the SDDC environment can be reduced by 72%, and the software switch can recognize the constituent of each VM with only the MAC header, so that the CPU overhead for processing the multipoint frame The network overhead can be drastically reduced.

Further, according to the present invention, if the receiving VMs of the multipoint communication are all running in the same L2 network, the software switch can also serve as a multicast service node, thereby reducing the network overhead for additional 1 hop to the service node There is an effect that can be.

1 is a diagram for explaining a software switch-based virtualization operation method in SDDC
2 is a diagram for explaining a VXLAN packet format used as a standard format for tunneling;
FIG. 3 is a view for explaining the L2 based Lightweight Hybrid Multicast (L2HM) protocol based on the L2 based light tunneling protocol (L2P)
4 is a diagram for explaining an example of broadcasting a frame according to the present invention;
5 is a view for explaining a difference between the present invention and the prior art;

It is to be understood that the present invention is not limited to the description of the embodiments described below, and that various modifications may be made without departing from the technical scope of the present invention. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail.

In the drawings, the same components are denoted by the same reference numerals. And in the accompanying drawings, some of the elements may be exaggerated, omitted or schematically illustrated. It is intended to clearly illustrate the gist of the present invention by omitting unnecessary explanations not related to the gist of the present invention. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram for explaining a software switch-based virtualization operation method in SDDC.

In general, network virtualization in SDDC is based on the configuration of an overlay network based on a software switch installed on a physical server, without concern for a physical network for connecting SDDC and a physical server for connecting the physical server do.

When SDDC is distributed among a plurality of physical servers, a plurality of virtual machines (VMs) and at least one software switch may be installed in each physical server. The software switch can serve as a virtual network hub that connects the VMs running on the installed server with the external physical network.

One physical server implementing the SDDC may include a communication unit and a control unit according to the present invention. 1, the communication unit 102 connects a physical network with another server, and the control unit includes a software switch 101 module serving as a network hub of a plurality of VMs 103 and 104 and VMs .

The procedure for forwarding packets at the server is as follows.

For example, when VM1 103 transmits an arbitrary packet to VM2 104, the traffic generated at 103 is transmitted to 101 via vNIC (virtual NIC) of VM1. 101 identifies the destination MAC address (L2 address) of the received traffic, and forwards the packet directly to the VM2 104 without additional encapsulation because it is the vNIC address in the same server.

However, if the VM 1 wishes to transmit a packet to a VM of another server, a tunneling procedure is required to encapsulate the packet. Through tunneling 101, the packet can be immediately forwarded to the software switch managing the incoming VM have. Tunneling means that a software switch encapsulates a packet. In a virtual network environment, tunneling allows the source software switch to forward the packet directly to the destination software switch regardless of the topology.

For example, when VM1 wants to transmit a packet to VM3 of another server, 101 can forward the packet by connecting a tunnel to a software switch that manages VM3.

Such tunneling can follow various protocols, but the VXLAN protocol is commonly used as a (de facto) standard.

The VXLAN protocol encapsulates the original network packets using the UDP protocol and supports tunneling to any IP network. Therefore, SDDC is not dependent on the physical network configuration of the physical server, but can freely implement the virtualized network as needed.

Meanwhile, it may be considered that the VM 1 wants to transmit a packet to all VMs connected to an arbitrary network or to transmit a packet to a VM belonging to an arbitrary group. That is, it is a case that an arbitrary VM in SDDC tries to perform broadcast / multicast communication.

The software switch that received the broadcast / multicast traffic likewise goes through a tunneling process that encapsulates the packet. Through tunneling, the software switch can send the packet to the multicast service node, and the multicast service node can also broadcast the encapsulated packet through the tunneling to the software switch connected to the destination VM.

2 is a diagram illustrating a VXLAN packet format used as a standard format for tunneling.

In FIG. 2, the original frame of the VM is 201, and 202 to 205 are the headers to which a software switch is added for tunneling. The VXLAN tunnel can be said to be a packet encapsulated by the software switch adding 202 to 205 header information to the original frame.

In the VXLAN packet format, 202 is allocated 8 bytes as a VXAN header, and 203 is allocated as 8 bytes as a UDP header for L4 information. In addition, 20 bytes are assigned as an IP header 204 for L3 information, and 205 bytes are assigned 14 bytes as MAC header for L2 information. That is, the size of the network header required for the VXLAN tunnel is 50 bytes in total. Information about each of the SDDC's components in the VXLAN packet format can be recorded in the VNID field of the VXAN header.

However, considering that the original frame size is at most 1500 bytes in general, the 50 bytes of VXAN is very large as the header size. Furthermore, it may be inefficient to cover all L2, L3, and L4 headers without considering the number of tunneling cases. That is, according to the VXLAN packet format, there is an overhead to generate and process a total 50 byte header for VXLAN encapsulation in all tunneled packets.

More specifically, according to the conventional VXLAN packet format, there arises a problem of resource consumption for transmitting a CPU overhead for generating a 50-byte network header and a frame added with 50 bytes in the original frame on the physical network.

Accordingly, the present invention proposes a light tunneling protocol that can solve the above-mentioned problem, that is, the problem that excessive resources are administered for tunneling while at the same time satisfying general purpose. The light tunneling protocol provided by the present invention may also include information on the VM's supported by the VXLAN packet format.

The present invention noted that most of the network traffic in SDDC moves within a server rack of the same server. Research shows that 80% of network traffic is forwarded only within the server rack. Typically, each Rack is configured with an L2 switch as the top of the rack (TOR) switch, and most of the traffic does not leave the L2 network.

Therefore, it is very inefficient to add all L2, L3, and L4 network headers to all packets to be tunneled according to the conventional VXAN format. This is because most tunneling can be performed without problems even if only the L2 header is used. Particularly, when the L2 header information is processed using the conventional Ethernet header format as it is, there is an effect that it can be interlocked with the legacy switch hardware without any problem.

On the other hand, SDDC generally supports multi-tenant. And in SDDC, it is common for a rack to implement SDDC for a single timeline rather than multiple timelines. Therefore, most of the traffic among multiple VMs belonging to one constituent does not deviate from the L2 network. Therefore, the present invention also proposes a method of processing addresses of a plurality of elements using a conventional L2 header format.

In the present invention, only the L2 header is added in this way to distinguish the VM's constituent information, and tunneling can be performed, which is referred to as an L2P tunnel or L2HM (L2 based Lightweight Hybrid Multicast) protocol. The L2HM protocol format for implementing the L2 based Light Tunneling Protocol (L2P) tunnel will be described below with reference to FIG. 3 attached hereto.

3 is a diagram for explaining the L2HM protocol based on the L2P Packet Format of the present invention.

As shown in FIG. 3, only the MAC header 302, 304, and 305 are added to the tunneled packet according to the present invention immediately before the original frame 301. In FIG. 3, 302, 304, and 305 are fields of the L2 header added for tunneling, and 303 is an option.

3, a destination address field 305, a source address field 304, and an Ethernet type / length field 304 are provided immediately in front of the original frame, Length field, 302).

More specifically, according to the present invention, 6 bytes of the destination address field 305 may include MAC address information of a network interface allocated to a software switch that manages a physical server operating a VM that is a destination of the packet.

According to the present invention, the starting address field 304 6 bytes may include MAC address information of the network interface assigned to the software switch that manages the VM which is the origin of the network packet.

According to the present invention, two bytes of type / length field 302 can be fixed to 0x8100 (Ethernet type) for interworking with a legacy switch. As a result, the header for the L2P tunneling of the present invention is only 14 bytes in total.

According to the present invention, 4 bytes of the VLAN tag field 303 may be optional. Specifically, if the physical network uses a VLAN (virtual LAN) and a VLAN is allocated for SDDC, the VLAN ID is written in 303, and if not, it is unnecessary to add 303. In the case of using the VLAN tag, the header for the L2P tunneling of the present invention increases from 14 bytes to 18 bytes.

In particular, according to the present invention, the destination address field 305 may include the SDDC's tentative ID information, and in particular, the tentative ID may be an Ethernet multicast address of the destination address field of 01: 00: 5E: 00: 00: 00 - 01: 00: 5E: 7F: FF: FF.

In the Ethernet definition, FF: FF: FF: FF: FF: FF is used for the broadcast of the L2 network, but the actual Ethernet devices transmit the traffic to the entire L2 network without distinguishing between the multicast frame and the broadcast frame . The broadcast / multicast service is provided in such a manner that the traffic is received when the Ethernet-enabled NIC matches the multicast group address contained in its multicast MAC address hash.

Therefore, even if the header of the packet includes only the multicast address, the broadcast / multicast service can be supported in the entire L2 network. Therefore, the present invention adopts a method of providing the TID information using the multicast address .

Particularly, according to the present invention, it is possible to provide the tentative ID information using the multicast address space of the IPv4 used by the Ethernet. More specifically, the present invention uses 2 ²³ multicast address areas between 01: 00: 5E: 00: 00: 00 - 01: 00: 5E: 7F: FF: FF as the tentative ID. (20 reserved addresses may be excluded). In this way, compatibility with conventional legacy Ethernet equipment can be assured.

According to the present invention, a single multicast address can be basically assigned to each country on the SDDC. According to the present invention, it is possible to support ^{22 23} virtual tent networks by setting the above-mentioned tentative ID using the lower 23-bit multicast address included in the destination address field.

The software switches that receive the packet can identify the tentative ID in the lower 23 bits of the multicast address among the header information, and recognize which of the broadcast / multicast traffic of the corresponding packet.

A concrete example in which the software switch forwards the packet using the header information of FIG. 3 will be described below with reference to FIG. 4 attached hereto.

4 is a diagram for explaining an example of broadcasting / multicasting a frame according to the present invention.

The SDDC shown in FIG. 4 is implemented in a plurality of RACKs including RACK 1 and RACK 2, and RACK 1 and RACK 2 support SDDC for the same timeline, i.e., VMs of the same timeline support RACK 1 and RACK 2 As shown in FIG.

Communication between RACK 1 and RACK 2 may be through the L3 network. Further, the RACK 1 includes the server 1 411, the server 2 412, and the server 3 413, and the communication between the servers 1, 2, and 3 may pass through the L2 network 416.

Likewise, RACK 2 includes server 4 414 and server 5 415, and communication between servers 4, 5 can be via L2 network 417. 4, A, B, C, D, and E are software switches implemented in the server, and 1, 2, 3, 4, 5, 6, and 7 are schematized VMs implemented in the server. And α and β are multicast service nodes.

A case of multicasting a packet to an arbitrary multicast group X (composed of VMs 3 and 4) in VM 1 will be described as an example.

In this case, the software switch A receives the multicast frame from the VM 1, and the mapping table, that is, the MAC address of all the software switches connected to the software switch and the network, and the MAC address of the Vnic of the VMs It checks that the multicast group X is not present in the server 1 411 and encapsulates the packet for tunneling.

According to an embodiment of the present invention, the mapping table may be a flow table composed of flow entries, and flow rules may be specified in each of the flow entries.

At this time, according to the conventional VXLAN protocol, the software switch A transmits a packet encapsulated through the VXLAN tunnel to the multicast service node α by appending a total of 50 bytes to the packet, and α is transmitted (including the header of 50 bytes) Replicates the packet and sends it to all software switches connected to the network for that particular entity, namely A, B, C, D, and E. B and C will receive the packet because they belong to multicast group X and will send the decapsulated packet to VM 3, 4, respectively.

However, according to the L2HM protocol of the present invention, since the multicast group X is included in the same L2 network 416, the software switch A transmits a packet with only a total of 16 bytes of the header (i.e., through the L2P tunnel) Lt; / RTI > Furthermore, α can transmit packets only to A, B, and C included in the same L2 network 416, not all software switches that manage the corresponding VM.

Further, according to another embodiment of the present invention, the role of the multicast service node may also be a software switch.

In the above example, the software switch A that received the packet for the multicast group X confirms that the multicast group X is included in the same L2 network 416, copies the packet, and adds a packet (Via the L2P tunnel) to the B and C managing the multicast group X, respectively.

On the other hand, when forwarding packets from VM 2 to another multicast group Y (consisting of VMs 6 and 7), the VXLAN tunnel may still be valid. According to the present invention, the software switch A that has received the packet from the VM 2 checks the mapping table to confirm that the software switch for managing the multicast group Y is E and that E is not included in its L2 network 416. In this case, A may copy the packet and forward the multicast packet encapsulated through the conventional VXLAN tunnel to the software switch E instead of the L2P tunnel.

That is, according to the present invention, a software switch that receives a multicast packet from a VM also plays a role of a multicast service node and copies a packet. When the multicast group is included in the same L2 network as itself, If not, you can multicast packets through the VXLAN tunnel. Therefore, according to the present invention, compared with the conventional standard, it is possible to reduce the overhead of 1 hop to the multicast service node and multicast packets in a general and efficient manner without any additional overhead.

Meanwhile, the software switches according to the present invention can register the multicast group only for the multicast group belonging to a country that owns the VMs managed by the software switches. This is to support multicast per-time of L2HM network.

When software switches register multicast groups only for multicast groups belonging to a group that owns VMs managed by them, multicast traffic that does not need to be processed by the software switch is transmitted from the physical NIC used by the software switch to hardware There is an effect of being filtered.

A table of the list of the target IDs to be processed by software switches can be created and updated in various ways.

For example, a list of the target IDs can be created and managed using the Proactive method. This allows the central control system such as the SDN controller to transmit the list of the list of the target ID to the software switch and to transmit the updated list information whenever there is a change in the preset period or list can do.

As another example, the list of the target IDs can be created and managed by applying the reactive method. This means that when each VM is created, it tries to connect to the software switch, and each software switch can manage the list of information in the form of adding the corresponding VM's TID to the list of TIDs.

FIG. 5 is a view for explaining the difference between the present invention and the prior art and the effect of the present invention in comparison with the prior art, by concretely explaining the first example of FIG. 4 described above.

5 shows a case of multicasting a packet to multicast group X (consisting of VM 3, 4) of FIG. 4 according to the conventional VXLAN protocol, and 503 shows a case where multicast service node Is multicast to the multicast group < RTI ID = 0.0 > X. ≪ / RTI >

If the software switch A receives a multicast frame for the multicast group X from VM1 in step 510, the software switch A, in step 511, sends 50 bytes of header (i.e., outer Ethernet header, Outer IP header, UDP header, VXLAN header) to encapsulate the packet to transmit the encapsulated frame via the VXLAN tunnel to the multicast service node alpha.

Thereafter, in step 512, the multicast service node α copies a plurality of packets and transmits packets to all the software switches A, B, C, D, and E of the corresponding primary network through the VXLAN tunnel in steps 513 to 517.

Thereafter, in steps 518 and 519, only software switches B and C will receive packets because they belong to multicast group X, and will transmit the decapsulated packets to VMs 3 and 4, respectively.

 On the other hand, according to the present invention, the software switch A receiving the multicast frame for the multicast group X from the VM 1 in step 530 can confirm that the multicast group X is in the same L2 network environment as itself.

Thereafter, in step 531, the software switch A can directly copy a plurality of packets without sending a packet to the multicast service node. That is, according to the present invention, there is an effect that the network overhead of 1 hop for forwarding a packet to a multicast service node can be reduced.

In steps 533 and 534, the software switch A encapsulates the packet by adding only the 14-byte MAC header including the ID information according to the L2P protocol of the present invention, and transmits the encapsulated packet to the software switches B and C Lt; / RTI >

That is, according to the embodiment 503 of the present invention, the steps 511, 513, 516 and 517 can be omitted in comparison with the step 501. In steps 514 and 515, it is also possible to add only 14 bytes of header .

Then, at steps 535 and 536, software switches B and C will receive packets because they belong to multicast group X, and will send the decapsulated packets to VM 3, 4, respectively.

The embodiments of the present invention disclosed in the present specification and drawings are intended to be illustrative only and not intended to limit the scope of the present invention. It will be apparent to those skilled in the art that other modifications based on the technical idea of the present invention are possible in addition to the embodiments disclosed herein.

Claims (6)

A method for multipoint transmission of a frame by a server implementing a software switch in a software defined data center (SDDC) environment,
The method comprising: receiving a first software switch from a first virtual machine with a plurality of virtual machines as a destination; And
When all the software switches connected to each of the destination virtual machines are included in the same L2 network as the first software switch, the MAC header including the LAN ID information is copied by the number of the destination virtual machines And if all the software switches connected to the destination virtual machine are not included in the same L2 network as the first software switch, the VXAN header, the UDP header, the Outer IP header, and the Outer Mac header are added in order before the frame And forwarding the frame to the multicast service node. The method of claim 1,
A Destination Address field including the TID information, a Source Address field including MAC address information of the first software switch, and an Ethernet Type field having a value of 0x8100 In addition,
The method according to claim 1, characterized in that the tentative ID has a value between 01: 00: 5E: 00: 00: 01: 00: 5E: 7F: FF: FF among the Ethernet multicast addresses of the destination address field Casting method. delete 3. The method of claim 2,
Further comprising a VLAN tag field including the VLAN ID information when a physical network connected to the server uses a VLAN and a VLAN ID is previously allocated to the software defined data center. Lt; / RTI > A computer program stored in a computer-readable medium for causing a server implementing a software switch in a Software Defined Data Center (SDDC) environment to perform a process of multipoint transfer of a frame,
A function in which a first software switch receives a frame with a plurality of virtual machines as a destination from a first virtual machine; And
When all the software switches connected to each of the destination virtual machines are included in the same L2 network as the first software switch, the MAC header including the LAN ID information is copied by the number of the destination virtual machines And if all the software switches connected to the destination virtual machine are not included in the same L2 network as the first software switch, the VXAN header, the UDP header, the Outer IP header, and the Outer Mac header are added in order before the frame And forwards the frame to the multicast service node. CLAIMS What is claimed is: 1. A server implementing a software switch for broadcasting frames within a Software Defined Data Center (SDDC)
A communication unit for connecting a physical network to the software switch; And
A first software switch is controlled to receive a frame from a first virtual machine with a plurality of virtual machines as a destination and all software switches connected to each of the destination virtual machines are included in the same L2 network as the first software switch , Copying the frame added immediately before the frame with the Mac header including the TID information by the number of destination virtual machines, and copying all the software switches connected to the destination virtual machine to the same L2 network as the first software switch And a control unit for controlling the forwarding unit to forward the frames added with the VXAN header, the UDP header, the Outer IP header, and the Outer Mac header to the multicast service node in order before the frame is included.

Images