VNF migration to VIM

Abstract

Mechanisms are provided for migrating VNFs to VIMs in a communication network. A method is performed by a migration controller, the method including obtaining network complexity information for each VNF, VM usage information for each VNF, and processing capability information for compute nodes of each VIM. The method includes determining a mapping between the VNFs and the VIMs. The mapping defines at which of the VIMs each of the VNFs is instantiable. The method includes ranking the VNFs in a list by matching the network complexity information for each VNF and the VM usage information for each VNF with the processing capability information for the compute nodes of each VIM and taking into account the mapping between the VNFs and the VIMs. The method includes initiating migration of the VNFs to the VIMs in an order defined by the list.

Description

Technical Field

[0001] The embodiments presented herein relate to methods, migration controllers, computer programs, and computer program products for migrating Virtual Network Functions (VNFs) to Virtual Infrastructure Managers (VIMs) in a communication network. Background Technology

[0002] In computing, a virtual machine (VM) is a simulation of a computer system. VMs are based on a computer architecture and provide the functionality of a physical computer. Their implementation can involve specialized hardware, software, or a combination thereof. VMs are typically software programs that present the same interface as a physical computer.

[0003] Virtual machines (VMs) have many applications. One example is their use in providing computing support within core network nodes of cellular telecommunications systems. A single core network node may contain several types of VMs running together. The cooperating VMs and the virtual networks connecting them form what is commonly referred to as VNFs.

[0004] When a VNF is deployed on an actual computer, this deployment typically occurs across multiple physical machines or compute nodes. One or more of these compute nodes can be managed by a VIM. In systems with multiple VIMs (or other methods of coordinating compute nodes, such as container managers like Kubernetes), one issue concerns how to best deploy the VNF. This is typically handled by a separate node called the orchestrator.

[0005] In a system that stores records of VMs, VMs can run independently of their records and are unaffected by changes to those records. Generally, the only times a VM interacts with its records simultaneously are: when the VM starts, stops, or is instantiated (either during VNF instantiation or at a separate time such as a scaling operation); when the VM changes (which can be done by scaling up or down, where the VM's processor and / or memory capacity can change, or when configuration changes, such as the addition of a new network or the VM's address changing due to the VM being moved to another physical device); or when the VM terminates.

[0006] If changes occur that require VM records to be modified due to, for example, a database management system (DBMS) upgrade, then the VM records will also need to be modified, for example, to adapt to the new DBMS format. When performing such changes, the orchestrator may need to query the VM's configuration, for example, to determine if the configuration has changed in a way that requires it to be integrated into the updated records due to the creation of the original records.

[0007] However, when a large number of VMs or VNFs must be migrated, and some or all of the information in the infrastructure where VMs or VNFs are deployed (e.g., in VIM) needs to be verified, there is a risk of placing a considerable load on VIM because queries about all aspects of the VMs and the VNFs they constitute must be served. While such queries are almost unavoidable, they can be distributed as a constant background load to avoid peak loads on VIM.

[0008] This can be achieved in several ways, such as by traffic shaping of the requests, but this is problematic because a request can easily be broken down into several subsequent requests that must be served within the scope of the original request. That is, a VM can be attached to one or more networks, where each network or VNF must be queried to obtain the virtual network adapters it comprises, and these virtual network adapters must be queried to obtain the VMs they are connected to, and so on.

[0009] Therefore, improvements are still needed in handling the migration of VNFs in communication networks. Summary of the Invention

[0010] One objective of the embodiments described herein is to provide efficient migration from VNF to VIM in a communication network.

[0011] According to the first aspect, a method for migrating a Virtual Network Function (VNF) to a Virtual Memory (VIM) in a communication network is proposed. This method is executed by a migration controller. The method includes obtaining network complexity information for each VNF, VM usage information for each VNF, and processing capability information of the compute nodes for each VIM. The method includes determining the mapping between VNFs and VIMs. This mapping defines where each VNF is instantiable within the VIM. The method includes sorting the VNFs in a list by matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes for each VIM, taking into account the mapping between VNFs and VIMs. The method includes initiating the migration from VNFs to VIMs according to the order defined in the list.

[0012] According to the second aspect, a migration controller for migrating VNFs to VIMs in a communication network is proposed. The migration controller includes processing circuitry. The processing circuitry is configured to enable the migration controller to obtain network complexity information for each VNF, VM usage information for each VNF, and processing capability information of the compute nodes for each VIM. The processing circuitry is configured to enable the migration controller to determine the mapping between VNFs and VIMs. This mapping defines where each VNF is instantiable within the VIM. The processing circuitry is configured to enable the migration controller to sort the VNFs in a list by matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes for each VIM, taking into account the mapping between VNFs and VIMs. The processing circuitry is configured to enable the migration controller to initiate the migration of VNFs to VIMs in the order defined in the list.

[0013] According to the third aspect, a migration controller for migrating VNFs to VIMs in a communication network is proposed. The migration controller includes an acquisition module configured to acquire network complexity information for each VNF, VM usage information for each VNF, and processing capacity information of the compute nodes for each VIM. The migration controller includes a determination module configured to determine the mapping between VNFs and VIMs. This mapping defines where each VNF is instantiable within the VIM. The migration controller includes a sorting module configured to sort the VNFs in a list by matching the network complexity information and VM usage information of each VNF with the processing capacity information of the compute nodes for each VIM, taking into account the mapping between VNFs and VIMs. The migration controller includes an initiation module configured to initiate the migration of VNFs to VIMs in the order defined in the list.

[0014] According to the fourth aspect, a computer program is provided for migrating a VNF to a VIM in a communication network, the computer program including computer program code that, when run on a migration controller, causes the migration controller to perform the method according to the first aspect.

[0015] According to the fifth aspect, a computer program product is proposed, comprising a computer program according to the fourth aspect and a computer-readable storage medium storing the computer program. The computer-readable storage medium may be a non-transitory computer-readable storage medium.

[0016] Advantageously, these aspects enable efficient migration from VNF to VIM in communication networks.

[0017] Other objects, features, and advantages of the appended embodiments will become apparent from the following detailed disclosure, the appended dependent claims, and the accompanying drawings.

[0018] Generally, unless otherwise expressly stated herein, all terms used in the claims are to be interpreted according to their ordinary meaning in the art. Unless otherwise expressly stated, all references to “a / an / the said element, device, component, apparatus, module, action, etc.” should be openly interpreted as referring to at least one instance of an element, device, component, apparatus, module, action, etc. Unless expressly stated otherwise, the actions of any method disclosed herein need not be performed strictly in the exact order disclosed. Attached Figure Description

[0019] The inventive concept will now be described by way of example with reference to the accompanying drawings, in which:

[0020] Figure 1 This is a schematic diagram illustrating a communication network according to an embodiment;

[0021] Figure 2 and Figure 5 This is a flowchart of the method according to the embodiment;

[0022] Figure 3 and Figure 4 A migration controller according to an embodiment is schematically illustrated;

[0023] Figure 6 A migration controller configured to provide a list as a batch file to a batch control function is illustrated schematically according to an embodiment.

[0024] Figure 7 The diagram schematically illustrates a migration controller configured, according to an embodiment, to provide a list as a rules file to the Congress driver;

[0025] Figure 8 This is a schematic diagram of the functional units of the migration controller according to an embodiment;

[0026] Figure 9 This is a schematic diagram illustrating the functional modules of the migration controller according to an embodiment; and

[0027] Figure 10 An example of a computer program product including a computer-readable storage medium according to an embodiment is shown. Detailed Implementation

[0028] The inventive concept will now be described more fully below with reference to the accompanying drawings, which illustrate certain embodiments thereof. However, the inventive concept can be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Throughout the specification, similar reference numerals refer to similar elements. Any action or feature indicated by dashed lines should be considered optional.

[0029] As mentioned above, there is a need to improve the handling of migrating VNFs in communication networks.

[0030] More specifically, the current mechanisms used to handle this migration do not optimize queries for external entities (e.g., VIMs) that the database object depends on. The current mechanisms for issuing VIM requests make no effort to optimize the volume of requests that depend on interconnect components. This can be particularly problematic if multiple VNFs exist that span multiple VIMs.

[0031] Figure 1 This is a schematic diagram of a communication network 100, in which a migration controller 200 is configured to migrate VNF 110a:110M to VIM 120a:120N. According to... Figure 1 For example, “VNFs1” will be migrated to “VIM n”, etc. As will be disclosed below, migration controller 200 is configured to create a list according to which VNF 110a:110M will be migrated to VIM120a:120N, such that VNF ​​110a:110M is migrated to VIM120a:120N based on the compute requirements of VNF 110a:110M, the number of VMs per VNF, the compute resources of VIM 120a:120N, and the order in which VNF 110a:110M is migrated to VIM 120a:120N. This enables load balancing or processing time balancing among VIM 120a:120N. In some respects, VNF 110a:110M and / or VIM 120a:120N are grouped such that there are the same number of VNFs and VIMs, i.e., where N = M.

[0032] The embodiments disclosed herein specifically relate to a mechanism for migrating VNF110a:110M to VIM120a:120N in a communication network 100. To achieve this mechanism, a migration controller 200, a method executed by the migration controller 200, and a computer program product comprising code, such as code in the form of a computer program, which, when executed on the migration controller 200, causes the migration controller 200 to perform the method.

[0033] Figure 2 This is a flowchart illustrating an embodiment of a method for migrating VNF 110a:110M to VIM 120a:120N in a communication network 100. These methods are executed by a migration controller 200. These methods are advantageously provided as a computer program 1020.

[0034] S102: The migration controller 200 obtains network complexity information for each VNF, VM usage information for each VNF, and processing capacity information for each VIM's compute nodes. An example of this information is provided below.

[0035] S104: The migration controller 200 determines the mapping between VNFs 110a:110M and VIMs 120a:120N. This mapping defines at which location in VIMs 120a:120N each of the VNFs 110a:110M is instantiable for each of the VNFs 110a:110M. In this regard, it is assumed that each VNF 110a:110M is instantiable for at least one location in VIMs 120a:120N.

[0036] S106: The migration controller 200 sorts the VNFs 110a:110M in a list by matching the network complexity information and VM usage information of each VNF with the processing power information of the compute nodes of each VIM. When performing the matching, the migration controller 200 considers the mapping between VNFs 110a:110M and VIMs 120a:120N. The latter ensures that VNFs 110a:110M do not match VIMs 120a:120N that are not instantiable by VNFs 110a:110M. The migration controller 200 is thus configured to determine which VNFs 110a:110M will be migrated to which VIMs 120a:120N and the order in which VNFs 110a:110M will be migrated to VIMs 120a:120N. Other aspects of how the matching might be performed are described below.

[0037] S108: The migration controller 200 initiates the migration from VNF 110a:110M to VIM 120a:120N in the order defined in the list. The following will disclose aspects of the further actions that may be performed once the migration from VNF 110a:110M to VIM 120a:120N has been initiated.

[0038] The migration controller 200 thereby minimizes or at least uniformly distributes the load on the VIM120a:120N instantiated from the VNF 110a:110M.

[0039] More specifically, this approach enables the load on different VIMs to be minimized, or at least evenly distributed across each VIM and across VIM 120a:120N, not only during instantiation but also during other lifecycle management operations such as large-scale operations, for example when one or more new VMs, VNF 110a:110M and / or VIM 120a:120N are added to the communication network 100.

[0040] An embodiment relating to further details of the migration of VNF110a:110M to VIM 120a:120N in communication network 100, performed by migration controller 200, will now be disclosed.

[0041] Here, intermediate reference Figure 3 . Figure 3 A migration controller 200a and entities operatively connected to it are schematically illustrated. The migration controller 200 is operatively connected to a VNF database 310a holding information about VNFs 110a:110M, a VIM database 310b holding information about VIMs 120a:120N, and an optional performance feedback record 310c holding performance feedback. The migration controller 200 provides a list 320 (as in S106) using inputs from databases 310a and 310b (as in S102 and S104) and the optional performance feedback record 310c (as in optional S114 below), based on which a migration from VNFs 110a:110M to VIMs 120a:120N is initiated.

[0042] The VNF database 310a may hold network complexity information and VM usage information for each VNF. This network complexity information and / or VM usage information for each VNF can be defined by a VNF description (VNFD). The VNFD can be registered in a VNF record (VNFR). The VNFR can be stored by one or more Network Function Virtualization Orchestrators (NFVOs). The VIM database 310b may hold processing power information for the compute nodes of each VIM.

[0043] Different methods can be used to perform matching in S106. Related aspects, embodiments, and examples will now be disclosed.

[0044] According to the embodiment, the matching includes: matching VNF 110a:110M, ordered from highest to lowest network complexity and from highest to lowest VM usage, with VIM 120a:120N, ordered from highest / fastest to lowest / slowest processing power of the VIM's compute nodes. Each VNF is matched only with any VIM 120a:120N that the VNF can instantiate. In other words, it is assumed that VNF ​​110a:110M is first sorted from highest to lowest network complexity, and that VNF ​​110a:110M is then sorted from highest to lowest VM usage, and that VIM 120a:120N is sorted from the highest / fastest processing power of its compute nodes to the lowest / slowest processing power of its compute nodes. Then, under the condition that each VNF is matched only with VIMs that VNFs can instantiate, those VNFs 110a:110M with high network complexity and high VM usage can be matched with those VIMs 120a:120N with high / fast processing capabilities and migrated to those VIMs 120a:120N with high / fast processing capabilities, and so on.

[0045] In some examples, VNF 110a:110M and / or VIM 120a:120N are associated with weighting factors used during matching in S106. For example, for network complexity, each VNF may have one weighting factor. That is, according to an embodiment, a corresponding network complexity weighting factor is assigned to each VNF based on its network complexity information. For example, for VM usage, each VNF may have one weighting factor. That is, according to an embodiment, a corresponding usage weighting factor is assigned to each VNF based on its VM usage information. For example, for processing capacity, each VIM may have one weighting factor. That is, according to an embodiment, a corresponding processing weighting factor is assigned to each VIM based on its computing node processing capacity information. The matching in S106 may then involve matching the weighting factors. That is, according to the embodiment, matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes of each VIM (as in S106) involves matching the network complexity weighting factor and usage weighting factor with the processing weighting factor. Using weighting factors can address the problem that may occur when the ordering of VNFs 110a:110M from highest to lowest network complexity does not correspond to the ordering of VNFs 110a:110M from highest to lowest VM usage.

[0046] In some aspects, different pieces of information, such as those obtained in S102, are provided in the lists. The network complexity information for each VNF is provided in a first list of VNFs 110a:110M, which sorts the VNFs 110a:110M according to their network complexity. The VM usage information for each VNF is provided in a second list of VNFs 110a:110M, which sorts the VNFs 110a:110M according to their VM usage. The processing power information of the compute nodes for each VIM is provided in a third list of VIMs 120a:120N, which sorts the VIMs 120a:120N according to their compute node processing power. The matching in S106 can then be based on matching against these lists. That is, according to the embodiment, sorting VNF 110a:110M in the list includes: sorting VNF 110a:110M in the fourth list by matching the first list and the second list with the third list and taking into account the mapping between VNF 110a:110M and VIM 120a:120N.

[0047] Different examples of network complexity, VM usage, and processing power may exist. In some examples, information about network complexity includes at least one of the following: network policy per VNF, network traffic patterns, and network topology. In some examples, VM usage includes at least one of the following: the number of hosted VMs, the complexity required to host VMs, and the processing intensity required to host VMs. In some examples, processing power includes at least one of the following: the number of processing units on compute nodes, the type of processing units on compute nodes, and the computation speed of compute nodes.

[0048] Different examples of the list may exist. In some examples, the list serves as input to one or more batch control functions. That is, according to an embodiment, the list defines the contents of a batch file that is provided to at least one batch control function as part of initiating a migration. In some examples, the list serves as input to one or more Congress drivers. That is, according to an embodiment, the list defines the contents of a rules file that is provided to at least one Congress driver as part of initiating a migration.

[0049] According to the list, different actions may be required once the VNF 110a:110M has been migrated to the VIM 120a:120N.

[0050] In some respects, the migrated VNF 110a:110M was actually deployed. Therefore, according to the embodiment, the migration controller 200 is configured to perform (optional) action S110:

[0051] S110: Migration controller 200 deploys VNF 110a:110M or at least initiates such deployment at those VIM120a:120Ns to which VNF 110a:110M has been migrated.

[0052] In other respects, the VNF 110a:110M for migration was not deployed. Therefore, according to the embodiment, migration was initiated without deploying VNF 110a:110M at VIM120a:120N.

[0053] Furthermore, simulated deployment can still be performed even in scenarios where the migration of VNF 110a:110M has not actually been deployed. Therefore, according to the embodiment, the migration controller 200 is configured to perform (optional) action S112:

[0054] S112: The migration controller 200 simulates the deployment of VNF 110a:110M at those VIM120a:120Ns to which VNF 110a:110M has already been migrated. In this respect, the simulation does not need to be performed at VIM 120a:120N, but can be performed using other computing resources.

[0055] Regardless of whether the migrated VNF 110a:110M is actually deployed, in some respects, performance feedback regarding the actual or simulated deployment of VNF 110a:110M is collected from VIM120a:120N. Therefore, according to an embodiment, the migration controller 200 is configured to perform (optional) action S114:

[0056] S114: The migration controller 200 obtains performance feedback from those VIM120a:120Ns to which the VNF 110a:110M has been migrated.

[0057] Performance feedback can be obtained from performance feedback block 310e.

[0058] Action S114 can be entered when action S110 or action S112 has already been executed. Performance feedback may involve network complexity information experienced or simulated for each VNF, VM usage information experienced or simulated for each VNF, and / or processing capacity information experienced or simulated for each VIM's compute node.

[0059] The VNF 110a:110M can then be reordered based on performance feedback. Therefore, according to an embodiment, the migration controller 200 is configured to execute (optional) action S116:

[0060] S116: The migration controller 200 reorders the VNF 110a:110M in the list based on performance feedback, and then re-initiates the migration from VNF 110a:110M to VIM 120a:120N in the order defined by the reordered list.

[0061] In some respects, S116 involves the same operation as in S106, but with the use of performance feedback. That is, upon completion of reordering VNF 110a:110M in the list based on performance feedback, action S108 can be entered again to migrate VNF 110a:110M to VIM 120a:120N in the order defined by the reordered list.

[0062] Reordering VNFs 110a:110M in the list results in at least some of them being migrated to other VIMs 120a:120N, rather than to other VIMs 120a:120N according to the original order used when the migration was initiated in action S108. One reason for reordering VNFs 110a:110M may be that performance feedback indicates some VIMs 120a:120N are underutilized, while others are overutilized in terms of load, processing time, etc., resulting in an imbalance in load, processing time, etc., among VIMs 120a:120N. Therefore, in some examples, performance feedback includes preferred VIM-VNF combinations (i.e., examples of which VNFs 110a:110M should be matched with which VIMs 120a:120N).

[0063] Reference here Figure 4 . Figure 4An embodiment of the migration controller 200 including a learning block 410 configured to obtain performance feedback from a performance feedback record 310c is illustrated schematically. As described above, the performance feedback can originate from an actual deployment of VNF 110a:110M or a simulated deployment of VNF 110a:110M. The learning block 410 further includes a VIM measurement value block 420a, a VIM value prediction block 420b, a VIM model adaptation block 420c, and a VIM input / output block 420d. The learning block 410 can perform machine learning on a model of VIM behavior and use the performance feedback to output an updated match between VNF 110a:110M and VIM 120a:120N. The output can be a list of preferred VIM-VNF combinations. For this purpose, the learning block 410 can be configured to update any of the aforementioned weighting factors. The VIM measurement value block 420a is configured to obtain the current value of the VIM from the performance feedback. The VIM value prediction block 420b is configured to predict the future value of the VIM. VIM model adaptation block 420c is configured to adapt a model to VIM behavior. VIM input / output block 420d is configured to define the inputs and outputs of the VIM behavior model thus adapted. In some aspects, iterations are performed on VIM measurement block 420a, VIM value prediction block 420b, VIM model adaptation block 420c, and VIM input / output block 420d using different performance feedback blocks until a best fit is achieved. Learning block 410 is connected to list reordering block 430, which reorders list 320 based on the output of learning block 410 to produce a reordered list 320'.

[0064] Embodiments of a method for migrating VNF 110a:110M to VIM 120a:120N in communication network 100, performed by migration controller 200 based on at least some of the embodiments disclosed above, will now be disclosed.

[0065] A1: The migration controller 200 identifies the network connected to each VNF and from the VNFR.

[0066] A2: The migration controller 200 locates networks (in the network records in NFVO, or by inspecting networks in VIM) and determines their extent and which other entities are connected to each network.

[0067] A3: The migration controller 200 sorts the VNFs 110a:110M in the first list in order from the most complex network to the least complex network.

[0068] A4: For each VNF, the migration controller 200 identifies the type of the VNF from the Virtual Network Function Description (VNFD) registered in the VNFR. The VNFD describes all instantiation parameters for each VNF and can be stored or accessed by the NFVO.

[0069] A5: The migration controller 200 uses VNFD as input to sort the VNF110a:110M in the second list from those VNF110a:110M with the most VMs to those VNF110a:110M with the fewest VMs, and / or from those VNF110a:110M with the most complex and / or processing-intensive VMs to those VNF110a:110M with the least complex and / or processing-least-intensive VMs.

[0070] A6: The migration controller 200 obtains configuration information for each VIM by querying the VIM or the VIM record in the NFVO. This provides information about the processing capabilities of each VIM; that is, a VIM deployed on a 386 single-core processor by the virtual controller (vCIC) will perform slower than a VIM deployed on a multi-core Itanium processor.

[0071] A7: The migration controller 200 sorts the VIM 120a:120N in the third list from those with the highest / fastest processing capabilities to those with the lowest / slowest processing capabilities.

[0072] A8: The migration controller 200 obtains information about which VNFs 110a:110M can be instantiated at which VNFs 110a:110M. VNFs are sorted according to VIMs, where a VIM can be instantiated according to an NFVO.

[0073] A9: The migration controller 200 checks the first list, the second list, and the third list against information about which VNF 110a:110M can be instantiated at which VNF 110a:110M.

[0074] The list defined in A10:A9 is used to create a list of VNFs 110a:110M to be migrated to each VIM, and the order in which such migrations will occur (i.e., from the VNF to be migrated first to the VNF to be migrated last).

[0075] Now for reference Figure 5 . Figure 5A flowchart is shown of an embodiment of a method for migrating VNF 110a:110M to VIM 120a:120N in a communication network 100, performed by migration controller 200 based on at least some of the embodiments disclosed above.

[0076] Information about VIM 120a:120N and VNF 110a:110M is obtained (S201, S202) as their respective inputs. VIM 120a:120N is sorted according to processing power from highest / fastest to lowest / slowest (S203). It is checked whether VNF110a:110M is associated with a weighting factor (S204), and if so, whether the weighting factor reflects the complexity of the VNF 110a:110M network (S205). Otherwise, the weighting factor is applied (S206). These weighting factors are structured to reflect network complexity, for example, making a single input / output virtualization (SR-IOV) network have a higher weighting factor than a regular network because it requires more time and resources to create an SR-IOV network. The weighting factors are either applied as part of the input itself or derived from known network complexity.

[0077] The available capacity and performance of the virtualization environment are compared with the complexity of the requested operations (S207). A slow VIM with an older processor and limited memory will not be able to perform actions at the same speed as a VIM with a modern processor and large memory capacity. On the other hand, creating a VM is relatively fast, but creating a VM with several attached Virtual Network Interface Cards (VNICs) and different Virtual Networks (VNs) attached to them takes more time. Special features further increase the complexity, such as networking using SR-IOV, which is more complex to implement than simple networking.

[0078] The consolidated capacity of VNF is matched with the weighted list of VIM (S208).

[0079] The list is sorted according to the input (S209) so that different operations can be appropriately ordered. For example, if the virtualization environment runs using batch commands, the creation of all networks can be combined together, the creation of all VMs can be combined together, and so on. However, if the virtualization environment targeted by the batch operation runs sequentially, the list can be sorted according to dependencies, i.e., first create the network, then create all VMs that depend on it, and then create the second network and the VMs that depend on the second network, and so on. The derived command sequence is constructed based on the sorted list to be best suited for the target virtualization environment.

[0080] Initiate a migration based on the sorted list (S210). If the sorted list is provided to the Congress system, it is provided to the Congress driver; otherwise, if the sorted list is specifically targeted at a particular virtualization environment, it is provided to that virtualization environment in an appropriate manner.

[0081] Now for reference Figure 6 and Figure 7 The lists are used as inputs for batch control functions and the Congress driver, respectively.

[0082] Figure 6 An embodiment is schematically illustrated in which migration controller 200 provides list 320 as a batch file to batch control function 610. Batch control function 610 is operatively connected to NFVO 620, which holds VNFR 630. NFVO 620 is operatively connected to Virtualization Network Function Manager (VNFM) 640, which is operatively connected to at least some of VIMs 120a:120N, represented here by VIM 120n having two VIM instances 640n1 and 640n2. The batch file is input to batch control function 610 and then used to manage interactions with VIM 120n. Batch control function 610 interacts with NFVO 620, which controls the placement of VNFs 110a:110M in the virtualization infrastructure. NFVO 620 requests the creation of one or more VNFs 110a:110M from VNFM 640, which interacts with one or more VIMs. A Network Service (NS) is defined in the Management and Orchestration (MANO) standard as a combination of VNFs spanning multiple VIMs.

[0083] Figure 7 An embodiment is schematically illustrated in which migration controller 200 provides list 320 as a rule file to Congress driver 710. Congress driver 710 is operatively connected to NFVO 720, which holds VNFR 730. NFVO 720 is operatively connected to OpenStack application programming interfaces (APIs; Neutron, Nova, etc.). 720 is operatively connected to at least some of VIMs 120a:120N, represented here by VIM 120n having two VIM instances 740n1 and 740n2. The rule file is input to Congress driver 710 and then used to manage interactions with VIM 120n. Congress driver 710 interacts with OpenStack API 720, which controls the placement of VNFs 110a:110M in the virtualization infrastructure.

[0084] Figure 8 The components of the migration controller 200 according to an embodiment are schematically shown in a manner that represents multiple functional units. A product 1010 capable of executing computer programs (such as...) is used. Figure 10 The processing circuitry 210 may be provided as any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., storing software instructions in a medium (e.g., in the form of storage medium 230). The processing circuitry 210 may also be provided as at least one application-specific integrated circuit (ASIC) or field-programmable gate array (FPGA).

[0085] Specifically, processing circuitry 210 is configured to cause migration controller 200 to perform a set of operations or actions as disclosed above. For example, storage medium 230 may store the set of operations, and processing circuitry 210 may be configured to obtain the set of operations from storage medium 230 to cause migration controller 200 to execute the set of operations. The set of operations may be provided as a set of executable instructions.

[0086] Therefore, the processing circuitry 210 is thus arranged to perform the methods disclosed herein. The storage medium 230 may also include a persistent storage device, which may be any single memory or any combination of magnetic storage, optical storage, solid-state storage, or even remotely mounted memory. The migration controller 200 may also include a communication interface 220, which is at least configured to communicate with… Figure 1 , Figure 3 , Figure 4 , Figure 6 , Figure 7 The communication interface 220 communicates with the entities disclosed herein. Therefore, the communication interface 220 may include one or more transmitters and receivers, comprising analog and digital components. The processing circuitry 210 controls the overall operation of the migration controller 200, for example, by sending data and control signals to the communication interface 220 and the storage medium 230, by receiving data and reports from the communication interface 220, and by obtaining data and instructions from the storage medium 230. Other components and related functions of the migration controller 200 are omitted to avoid obscuring the concepts presented herein.

[0087] Figure 9 The components of the migration controller 200 according to an embodiment are schematically shown in the manner of multiple functional modules. Figure 9The migration controller 200 includes multiple functional modules: an acquisition module 210a, configured to execute action S102; a determination module 210b, configured to execute action S104; a command module 210c, configured to execute action S106; and an initiation module 210d, configured to execute action S108. Figure 9 The migration controller 200 may also include multiple optional functional modules, such as any of the following modules: a deployment module 210e configured to perform action S110, a simulation module 210f configured to perform action S112, an acquisition module 210g configured to perform action S114, and a reordering module 210h configured to perform action S116.

[0088] Generally, in one embodiment, each functional module 210a to 210h may be implemented solely in hardware, while in another embodiment it is implemented by means of software; that is, the latter embodiment has computer program instructions stored on storage medium 230 that, when executed on processing circuitry, cause migration controller 200 to perform the above-described combination. Figure 9 The corresponding actions mentioned. It should also be mentioned that even modules corresponding to parts of a computer program need not be separate modules; rather, their software implementation depends on the programming language used. Preferably, one or more or all functional modules 210a-210h can be implemented by processing circuitry 210, possibly in cooperation with communication interface 220 and / or storage medium 230. Therefore, processing circuitry 210 can be configured to obtain instructions from storage medium 230 provided by functional modules 210a-210h and execute these instructions, thereby performing any actions disclosed herein.

[0089] The migration controller 200 can be provided as a standalone device or as part of at least one other device. A first portion of the instructions executed by the migration controller 200 may be executed in a first device, while a second portion of the instructions executed by the migration controller 200 may be executed in a second device; the embodiments disclosed herein are not limited to any particular number of devices on which the instructions executed by the migration controller 200 can be executed. Therefore, the method according to the embodiments disclosed herein is suitable for execution by a migration controller 200 residing in a cloud computing environment. Thus, although in Figure 8 A single processing circuit 210 is shown, but the processing circuit 210 can be distributed across multiple devices or nodes. This also applies to... Figure 9 Functional modules 210a to 210h and Figure 10 Computer program 1020.

[0090] Figure 10An example of a computer program product 1010 including a computer-readable storage medium 1030 is shown. On this computer-readable storage medium 1030, a computer program 1020 may be stored, which can cause processing circuitry 210 and entities and devices operatively coupled to the processing circuitry 210 (e.g., communication interface 220 and storage medium 230) to perform the methods according to the embodiments described herein. Computer program 1020 and / or computer program product 1010 can therefore provide means for performing any of the actions disclosed herein.

[0091] exist Figure 10 In the example, computer program product 1010 is shown as an optical disc, such as a CD (Compact Disc), DVD (Digital Versatile Disc), or Blu-ray Disc. Computer program product 1010 may also be embodied as memory, such as random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or electrically erasable programmable read-only memory (EEPROM), and more specifically as a non-volatile storage medium of a device in the form of external memory, such as USB (Universal Serial Bus) memory or flash memory (e.g., compact flash memory). Therefore, although computer program 1020 is schematically shown herein as tracks on the depicted optical disc, computer program 1020 may be stored in any manner suitable for computer program product 1010.

[0092] The inventive concept has been primarily described above with reference to some embodiments. However, it will be readily apparent to those skilled in the art that other embodiments besides those disclosed above are also within the scope of the inventive concept as defined by the appended claims.

Claims

1. A method for migrating Virtual Network Functions (VNFs) (110a:110M) to Virtual Infrastructure Managers (VIMs) (120a:120N) in a communication network, the method being performed by a migration controller (200), the method comprising: (S102) Obtain network complexity information for each VNF, virtual machine (VM) usage information for each VNF, and processing capability information for each VIM's compute node, wherein the network complexity information involves at least one of the following: network policy, network traffic pattern, and network topology. Determine (S104) the mapping between the VNF (110a:110M) and the VIM (120a:120N), wherein the mapping defines at which location in the VIM (120a:120N) each of the VNFs (110a:110M) is instantiable; By matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes of each VIM, and considering the mapping between the VNFs (110a:110M) and the VIMs (120a:120N), the VNFs (110a:110M) are sorted in the list (S106); and Initiate (S108) the migration of the VNF (110a:110M) to the VIM (120a:120N) in the order defined in the list.

2. The method according to claim 1, wherein, Based on the network complexity information of each VNF, the corresponding network complexity weighting factor is assigned to that VNF.

3. The method according to claim 1 or 2, wherein, Based on the VM usage information of each VNF, a corresponding usage weighting factor is assigned to that VNF ​​according to the VM usage of each VNF.

4. The method according to claim 3, wherein, Based on the processing capacity information of each VIM's computing nodes, a corresponding processing weighting factor is assigned to the VIM according to the processing capacity of each VIM's computing nodes.

5. The method according to claim 4, wherein, Matching the network complexity information and VM usage information of each VNF with the processing capability information of each VIM's compute node includes: matching the network complexity weighting factor and the usage weighting factor with the processing weighting factor.

6. The method according to claim 1 or 2, wherein, The use of VMs involves at least one of the following: the number of managed VMs, the complexity required for managed VMs, and the processing power required for managed VMs.

7. The method according to claim 1 or 2, wherein, The processing capacity involves at least one of the following: the number of processing units of the computing node, the type of processing unit of the computing node, and the computing speed of the computing node.

8. The method according to claim 1 or 2, further comprising: Deploy (S110) the VNF (110a:110M) at those VIMs (120a:120N) to which the VNF (110a:110M) has been migrated.

9. The method according to claim 1 or 2, wherein, The migration was initiated without deploying the VNF (110a:110M) at the VIM (120a:120N).

10. The method of claim 9, further comprising: Simulate (S112) the deployment of the VNF (110a:110M) at those VIMs (120a:120N) to which the VNF (110a:110M) has been migrated.

11. The method of claim 8, further comprising: (S114) Performance feedback is obtained from the VIMs (120a:120N) to which the VNFs (110a:110M) have been migrated; as well as Based on the performance feedback, the VNFs (110a:110M) in the list are reordered (S116), and then the migration of the VNFs (110a:110M) to the VIMs (120a:120N) is re-initiated in the order defined by the reordered list.

12. The method according to claim 11, wherein, The performance feedback includes a preferred VIM-VNF combination.

13. The method according to claim 1 or 2, wherein, The list defines the contents of the batch file, which is provided to at least one batch control function as part of initiating the migration.

14. The method according to claim 1 or 2, wherein, The list defines the contents of a rules file, which is provided to at least one Progress driver as part of initiating the migration.

15. The method according to claim 1 or 2, wherein, The network complexity information for each VNF (110a:110M) is provided in the first list of VNFs, and the VNFs (110a:110M) are sorted according to the network complexity of each VNF based on the first list.

16. The method according to claim 15, wherein, The second list of VNFs (110a:110M) provides VM usage information for each VNF, which is sorted according to VM usage for each VNF.

17. The method according to claim 16, wherein, The third list of VIMs (120a:120N) provides the processing capability information of the computing nodes of each VIM. According to the third list, the VIMs (120a:120N) are sorted according to the processing capability of the computing nodes of each VIM.

18. The method of claim 17, wherein, Sort the VNFs (110a:110M) in the list by: matching the first list and the second list with the third list and taking into account the mapping between the VNFs (110a:110M) and the VIMs (120a:120N), and sorting the VNFs (110a:110M) in the fourth list.

19. The method according to claim 1 or 2, wherein, The matching process includes matching VNFs (110a:110M) in order of network complexity from highest to lowest and VM usage from highest to lowest with VIMs (120a:120N) in order of computing node processing power from highest to lowest, wherein each VNF is matched only with any one of those VIMs (120a:120N) that can instantiate that VNF.

20. A migration controller (200) for migrating Virtual Network Functions (VNFs) (110a:110M) to Virtual Infrastructure Managers (VIMs) (120a:120N) in a communication network, the migration controller (200) including processing circuitry (210) configured to cause the migration controller (200) to: Obtain network complexity information for each VNF, VM usage information for each VNF, and processing capacity information for each VIM's compute nodes. The network complexity information includes at least one of the following: network policy, network traffic pattern, and network topology; Determine the mapping between the VNF (110a:110M) and the VIM (120a:120N), wherein the mapping defines at which location in the VIM (120a:120N) each of the VNFs (110a:110M) is instantiable; By matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes of each VIM, and considering the mapping between the VNFs (110a:110M) and the VIMs (120a:120N), the VNFs (110a:110M) are sorted in the list; and Initiate the migration from the VNF (110a:110M) to the VIM (120a:120N) in the order defined in the list.

21. A migration controller (200) for migrating Virtual Network Functions (VNFs) (110a:110M) to Virtual Infrastructure Managers (VIMs) (120a:120N) in a communication network, the migration controller (200) comprising: The acquisition module (210a) is configured to acquire network complexity information for each VNF, virtual machine (VM) usage information for each VNF, and processing capability information for each VIM's compute node, wherein the network complexity information involves at least one of the following: network policy, network traffic pattern, and network topology. The determining module (210b) is configured to determine the mapping between the VNFs (110a:110M) and the VIMs (120a:120N), wherein the mapping defines at which location in the VIMs (120a:120N) each of the VNFs (110a:110M) is instantiable; The sorting module (210c) is configured to: sort the VNFs (110a:110M) in a list by matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes of each VIM, and taking into account the mapping between the VNFs (110a:110M) and the VIMs (120a:120N); and The initiation module (210d) is configured to initiate the migration of the VNF (110a:110M) to the VIM (120a:120N) in the order defined in the list.

22. The migration controller (200) according to claim 20 or 21 is further configured to perform the method according to any one of claims 2 to 19.

23. A computer program (1020) for migrating Virtual Network Functions (VNFs) (110a:110M) to Virtual Infrastructure Managers (VIMs) (120a:120N) in a communication network, the computer program comprising computer code that, when executed on the processing circuitry (210) of a migration controller (200), causes the migration controller (200) to: Obtain (S102) the network complexity information of each VNF, the virtual machine (VM) usage information of each VNF, and the processing capacity information of the compute nodes of each VIM, wherein, The network complexity information includes at least one of the following: network policy, network traffic pattern, and network topology; Determine (S104) the mapping between the VNF (110a:110M) and the VIM (120a:120N), wherein the mapping defines at which location in the VIM (120a:120N) each of the VNFs (110a:110M) is instantiable; By matching the network complexity information and VM usage information of each VNF with the processing capability information of the compute nodes of each VIM, and considering the mapping between the VNFs (110a:110M) and the VIMs (120a:120N), the VNFs (110a:110M) are sorted in the list (S106); and Initiate (S108) the migration of the VNF (110a:110M) to the VIM (120a:120N) in the order defined in the list.

24. A computer program product (1010) comprising a computer program (1020) according to claim 23 and a computer-readable storage medium (1030) storing the computer program.

Images