TECHNICAL FIELD

The embodiments herein relate to methods of configuring a Virtual Network Function (VNF) for Software Defined Network (SDN) operation. The embodiments further relate to a VNF performing one method and an SDN controller performing another method. The embodiments herein still further relate to computer programs for causing the VNF and SDN controller to perform the methods, and corresponding computer program products.

BACKGROUND

Over the last years, computing resources are implemented in the so called "cloud" to an ever-increasing extent. Theses cloud computing services generally consist of two main parts; cloud infrastructure such as computing, network and storage resources, and software functions executing on said infrastructure. The software functions are oftentimes implemented in what is commonly known as Virtual Network Functions (VNFs) comprising one or more Virtual Machines (VMs) executing various software to attain particular functionality, instead of using custom hardware to perform the intended functions.

Occasionally, the VNFs are implemented on top of a separate Software Defined Network (SDN) which decouples network control and forwarding functions between the VNFs and an underlying infrastructure. This makes for a flexible, manageable and cost-effective architecture. Typically, an

OpenFlow protocol is implemented for communication between the SDN and the underlying infrastructure. Today, the VNFs need to implement network functionality such as tunnelling, load balancing, routing, etc., since an SDN may or may not be available where the VNFs are executing. Furthermore, the functionality of the SDN may differ from installation to installation; from time to time, the functionality of the SDN may not be enough, thereby forcing the VNFs to implement fall-back solutions. Also, for cases when the SDN is implemented as part of a virtual switch, single root I/ O visualization (SR-IOV) becomes impossible to use since it will bypass the virtual switch.

SUMMARY

An object of the present disclosure is to relieve the VNFs from the burden of implementing excessive functionality when executing in a cloud where an SDN is not available or has limited functionality.

According to a first aspect, a method of configuring a VNF for SDN operation is provided. The method comprises acquiring an SDN plugin for enabling the VNF to perform at least one SDN function, and executing the acquired SDN plugin upon transferring data packets via the VNF, wherein the transferred data packets passes via the SDN plugin .

According to a second aspect, there is provided a VNF arranged to perform configuration for SDN operation, which VNF comprises a processing unit and a memory, said memory containing instructions executable by said

processing unit, whereby said VNF is operative to acquire an SDN plugin for enabling the VNF to perform at least one SDN function, and to execute the acquired SDN plugin upon transferring and receiving data packets via the VNF, wherein the transferred and received data packets passes via the SDN plugin . According to a third aspect, a method performed by an SDN controller of configuring at least one VNF for SDN operation is provided. The method comprises providing an SDN plugin for enabling the at least one VNF to perform at least one SDN function, the SDN plugin causing the at least one VNF to transfer and receive data packets via the SDN plugin upon execution of the SDN plugin.

According to a fourth aspect , there is provided an SDN controller arranged to configure at least one VNF for SDN operation, which SDN controller comprises a processing unit and a memory, the memory containing instructions executable by the processing unit, whereby the SDN controller is operative to provide an SDN plugin for enabling the VNF to perform at least one SDN function, the SDN plugin causing the VNF to transfer and receive data packets via the SDN plugin upon execution of the SDN plugin at the VNF.

Hence, at start-up of a VNF comprising one or more VMs, the VNF

downloads an SDN plugin - i.e. a compiled piece of program code - from a central location, such as an SDN controller/ supervisor. The SDN plugin contains program code for enabling the VNF to attain SDN functionality such as for instance tunnelling, load balancing, routing, service chaining, filters in the form of Access Control Lists (ACLs) or Policy Based Routing (PBR), etc. Now, upon the VNF executing the SDN plugin, the transferring/ receiving of payload data to/ from the VNF will pass through the SDN plugin .

Advantageously, with the disclosure, an SDN will always be available for any VNF installation, and the VNFs will all attain the same SDN functionality when executing the SDN plugin . A further advantage is that the SDN functionality can be optimized for a particular cloud of VNFs without incurring extra development cost on all VNFs. Specific SDN plugins can be developed for any cloud type, e.g. VMware and OpenStack, thereby making the solution cloud independent.

Hence, the SDN controller forms a control plane of the SDN while the SDN plugin forms a payload plane.

In one embodiment, the SDN plugin is implemented at the VNF in the form of a dynamically loadable link library. This is advantageous, since the SDN plugin can be loaded into the VNF at runtime in existing software. This is also advantageous, since the overhead of passing a packet through the SDN plugin is only in the form of a function call, which is a fast procedure.

In another embodiment, all VNFs in a particular cloud, i.e. VNFs with capacity to perform inter- communication among each other, will be provided with the same SDN plugin, thereby advantageously having the VNFs attain the same SDN functionality, no matter what revision a particular VNF currently has.

The SDN plugin acquired by a VNF can be tailored for specific cloud types, e.g., VMware, OpenStack, clouds implementing (or not implementing) SR- IOV, supporting network separation via e.g. Multiprotocol Label Switching (MPLS) clouds, Virtual Local Area Network (VLAN), Generic Routing Encapsulation (GRE) tunnelling, etc.

A further advantage is that the SDN plugin can be used as a means to optimize a specific packet path, by having the SDN controller compile or recompile a specific plugin configuration and thus optimize the plugin for a specific setup at compile time. Hence, the SDN controller can update the SDN plugin, for instance taking into account any customer demands on functionality, recompile the updated SDN plugin, and provide the resulting executable SDN plugin to the VNF(s) in order to attain the desired SDN functionality. The SDN plugin can thus advantageously be used as a means to allow a customer to extend the packet path functionality. By allowing the customer to partly or fully define program code in the SDN plugin before it is compiled at the SDN controller, the customer specific functionality can be inserted into the plugin . Technology-specific SDN plugins may advantageously be used for simplifying and accelerating communication between VNFs in terms of e.g. service chaining and load balancing. This does not incur extra complexity to the VNFs, since this functionality is provided by the SDN plugin .

In a further embodiment, any VNF wishing to communicate with another neighbouring VNF via an SDN packet data path established between the SDN plugins of the two VNFs may submit instructions to the SDN controller to update the SDN plugin of said another VNF, the SDN controller subsequently configuring the SDN plugin of said another VNF according to the submitted instructions via the SDN network in order to enable the VNF to perform required SDN functions in line with the submitted instructions. In yet a further embodiment, the SDN plugin is provided with an Application Program Interface (API) via which a VNF is capable of configuring its SDN plugin .

According to a fifth aspect, there is provided a computer program comprising computer-executable instructions for causing a device to perform steps according to an embodiment of the first and/ or third aspect when the computer-executable instructions are executed on a processing unit included in the device.

According to a sixth aspect, there is provided a computer program product comprising a computer readable medium, the computer readable medium having the computer program according to the fifth aspect embodied thereon.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein . All references to "a/ an/ the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. BRIEF DES CRIPTION OF THE DRAWINGS

The embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 shows a prior art VNF;

Figure 2 illustrates a VNF according to an embodiment, comprising an SDN plugin ;

Figure 3 illustrates an embodiment where an SDN controller supplies a plurality of VNFs with an SDN plugin; Figure 4a illustrates a method of configuring a VNF for SDN operation according to an embodiment;

Figure 4b illustrates a method of configuring a VNF for SDN operation according to another embodiment; Figure 5 illustrates a VNF and an SDN controller according to embodiments;

Figure 6 illustrates a further embodiment, where the SDN plugin further is configured with an API;

Figure 7 illustrates a further embodiment, where any VNF wishing to communicate with another neighbouring VNF in the same cloud is capable of updating the SDN plugin of the neighbouring VNF;

Figure 8 illustrates a VNF according to an embodiment; and

Figure 9 illustrates an SDN controller according to an embodiment.

DETAILED DES CRIPTION

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein . All references to "a/ an/ the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

Figure 1 shows a prior art Virtual Network Function (VNF) 10. For brevity, the VNF 10 is illustrated to comprise a network interface 11 via which all data packets passes. Packets received via the network interface 11 and handled by the VNF packet handling function 12 are referred to as ingress packets while packet transferred from the VNF packet handling function 12 via the network interface 11 and further on out to the network is referred to as egress packets. Now, as previously discussed, when the VNF 10 is executing in a cloud where SDN is not available or has scarce functionality, the VNF 10 itself has to implement one, some or even all of the SDN functions. Also, for cases when the SDN is implemented as part of a virtual switch, single root I/ O

virtualization (SR-IOV) becomes impossible to use since it will bypass the virtual switch.

Figure 2 illustrates a VNF 10 according to an embodiment, where an SDN plugin 13 is located at the network interface 11 for transferring and receiving packets via the network interface and to/ from the network. The SDN plugin 13 advantageously configures the VNF 10 such that it becomes capable of performing advanced SDN operation such as for instance tunnelling, load balancing, routing, service chaining, etc., upon executing the SDN plugin 13. Hence, at start-up of the VNF 10 , the VNF downloads the SDN plugin - i.e. a compiled piece of program code - from a central location. This central location will be embodied in the form of an SDN controller to be described subsequently.

Each time a data packet is received at, or transferred from, the VNF 10 via the network interface 11, the SDN plugin 13 is executed and each packet will pass via the SDN plugin 13 to/ from the packet handling function 12. Hence, each time the VNF 10 is to send/ receive payload data to/ from the

SDN, it will execute the acquired SDN plugin 13, which will cause the VNF 10 to attain the desired SDN functionality as exemplified hereinabove, for instance load balancing. Advantageously, with the disclosure, SDN

functionality will always be available for any VNF installation . Further advantageous is that, in case a particular cloud comprises a plurality of VNFs, they will all attain the same SDN functionality when implementing the SDN plugin .

Figure 3 illustrates an embodiment where a controller 40 supplies a plurality of VNFs 10 , 20 , 30 with an SDN plugin for facilitating the VNFs to attain SDN functionality. The plurality of VNFs 10 , 20 , 30 will in the following be considered to form part of the same cloud.

Functionally, each VNF generally comprises one or more Virtual Machines (VMs) 15, 16, 17 executing software to attain particular functionality. Thus, the functions of the first VNF 10 is illustrated to be executed by the various VMs 15, 16, 17.

Hence, in an embodiment of the disclosure, the SDN controller 40 provides an SDN plugin 13 to each one of the VNFs 10 , 20 , 30 for facilitating the VNFs to perform SDN functions. This is typically performed during startup of each VNF. When the VMs of each respective VNF 10 , 20 , 30 executes the SDN plugin 13, data packets to/ from the SDN will pass via the SDN plugin 13, and each VNF will thus advantageously attain SDN functionality as provided by the SDN plugin 13. In case the same SDN plugin 13 is provided to all VNFs 10 , 20 , 30 , the SDN functions attained upon execution of the SDN plugin 13 will advantageously be the same for all VNFs, no matter what revision a particular VNF currently has. The SDN plugin 13 is thus functionally inserted in the data packet path of each VNF.

The SDN controller 40 is illustrated to comprise a VM 41 containing a storage 42, which may comprise a variety of different SDN plugins, all configured for different scenarios, and a control entity 43 which is used to control the SDN plugins in all attached VNFs.

Further advantageous is that the SDN functionality can be optimized for a particular cloud of VNFs 10 , 20 , 30 without incurring extra development cost on all VNFs. Specific SDN plugins, e.g. contained in the storage 42 of the SDN controller 40 , can be developed for any cloud type, e.g. VMware and OpenStack, thereby making the solution cloud independent.

As further is illustrated in Figure 3, communication with any further network entity, such as e.g. a border gateway (BGW), for instance in the form of a router 50 , also occurs over the SDN network. Figure 4a and b illustrate the method of configuring a VNF for SDN operation seen from a perspective of a VNF 10 and SDN controller 40 , respectively.

In Figure 4a, the VNF 10 actively fetches the SDN plugin 13 from the SDN controller 40 in step s lO 1. Thereafter, each time a data packet is received at or transferred from the VNF 10 , the SDN plugin 13 is executed and each packet will enter or exit the VNF 10 via the SDN plugin 13.

In Figure 4b, another embodiment is illustrated where the SDN controller 40 actively provides an SDN plugin 13 for enabling the VNF 10 to perform SDN functions. The SDN plugin 13 will cause the VNF 10 to transfer and receive data packets via the SDN plugin 13 upon execution of the SDN plugin 13at the VNF 10.

With reference to Figure 5, the steps of the method performed by the VNF 10 and SDN controller 40 , respectively, according to embodiments are in practice performed by a processing unit 110 , 210 embodied in the form of one or more microprocessors arranged to execute a computer program 120 , 220 downloaded to a suitable storage medium 130 , 230 associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The respective processing unit 110 , 210 is arranged to cause the VNF 10 and the SDN controller 40 to carry out the method according to embodiments of the present disclosure when the appropriate computer program 120 , 220 comprising computer-executable instructions is downloaded to the storage medium 130 , 230 and executed by the processing unit 110 , 210. The storage medium 130 , 230 may also be a computer program product comprising the computer program 120 , 220. Alternatively, the computer program 120 , 220 may be transferred to the storage medium 130 , 230 by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program 120 , 220 may be downloaded to the storage medium 130 , 230 over a network. The processing unit 110 , 210 may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc.

Figure 6 illustrates a further embodiment, where the SDN plugin 13 further is provided with an API 17 via which the VNF 10 advantageously is capable of modifying the SDN plugin 10. Hence, in case SDN functionality is to be modified for a particular VNF 10 , the SDN plugin 13 is reconfigured accordingly via the API 17 by the VNF 10. Further, the SDN controller 40 is advantageously capable of reconfiguring the SDN plugin 13 via messaging over the SDN network. The flexibility provided by means of facilitating reconfiguration of the SDN plugin 13 is further advantageous in that the SDN plugin 13 can be used as a means to optimize a specific packet path. This can be done by having the SDN controller 40 compile or recompile a specific plugin configuration and thus optimize the plugin for a specific setup at compile time. The SDN plugin 13 can advantageously also be used as a means to allow a customer to extend the packet path functionality. By allowing the customer to partly or fully define program code in the SDN plugin 13 before it is compiled at the SDN controller 40 , the customer specific functionality can be inserted into the plugin . As previously mentioned, technology-specific SDN plugins may

advantageously be used for simplifying and accelerating communication between VNFs in terms of e.g. service chaining and load balancing. This does not incur extra complexity to the VNFs, since the SDN functionality is carried by the SDN plugin . Figure 7 illustrates a further embodiment, where any VNF wishing to communicate with another neighbouring VNF in the same cloud via the established SDN packet data path may submit instructions to the SDN controller 40 to configure the SDN plugin of said another VNF.

To illustrate, assuming that the SDN plugin 13: 1 downloaded by the first VNF 10 from the SDN controller 40 enables the first VNF 10 to form part of a service chaining application, whereas the SDN plugin 13:2 downloaded by the second VNF 20 is not configured to allow such SDN functionality.

If the first VNF 10 nevertheless wants to engage in service chaining activity with the second VNF 20 , the first VNF 10 will in this embodiment submit an "enable service chaining" instruction accordingly in step S30 1 to the SDN controller 40.

The SDN controller 40 will in step S302 update or modify the SDN plugin 13 :2 of the second VNF 20 in line with the instructions submitted by the first VNF 10. Advantageously, after the modified SDN plugin 13 :2 has been reconfigured by the second VNF 20 , it will be capable of engaging in the service chaining application with the first VNF 10 , upon execution of the reconfigured SDN plugin.

It should be noted that the SDN controller 40 itself may reconfigure the SDN plugin 13 :2 of the second VNF 20 in step S302 without having received any prior instructions from the first VNF 10.

In an embodiment, the SDN plugin 13 is implemented at the VNF 10 in the form of a dynamically loadable link library. This would have the advantage that the SDN plugin 13 can be loaded into the VNF 10 at runtime in existing software. This is also advantageous since the overhead of passing a packet through the SDN plugin is only in the form of a function call, which is a fast procedure.

Figure 8 illustrates a VNF 10 according to a further embodiment arranged to perform configuration for SDN operation. The VNF 10 comprises acquiring means 140 adapted to acquire an SDN plugin for enabling the VNF to perform SDN functions, and executing means 150 adapted to execute the acquired SDN plugin upon transferring and receiving data packets via the VNF, wherein the transferred and received data packets passes via the SDN plugin . The acquiring means 140 and executing means 150 may comprise a communications interface for receiving and providing information, and further a local storage for storing data, and may (in analogy with the description given in connection to Figure 5) be implemented by a processor embodied in the form of one or more microprocessors arranged to execute a computer program downloaded to a suitable storage medium associated with the microprocessor, such as a RAM, a Flash memory or a hard disk drive.

Figure 9 illustrates an SDN controller 40 according to a further embodiment arranged to configure at least one VNF for SDN operation. The SDN controller 40 comprises providing means 240 adapted to provide an SDN plugin for enabling the VNF to perform SDN functions, the SDN plugin causing the VNF to transfer and receive data packets via the SDN plugin upon execution of the SDN plugin at the VNF.

The providing means 240 may comprise a communications interface for receiving and providing information, and further a local storage for storing data, and may (in analogy with the description given in connection to Figure 5) be implemented by a processor embodied in the form of one or more microprocessors arranged to execute a computer program downloaded to a suitable storage medium associated with the microprocessor, such as a RAM, a Flash memory or a hard disk drive.

The disclosure has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the appended patent claims.