Methods and Systems for Virtualizing Network Functions and Computer-Readable Media

Abstract

Example implementations involve generating a virtualized network function by identifying mappable and non-mappable elements of a virtualized network function template based on a network function virtualization model. The mappable elements can be mapped to the network function virtualization model. The mappable elements can be transformed based on the mapping. The non-mappable elements are filtered based on a black-white list. A transformed virtualized network function definition including the transformed elements and the filtered elements is generated. Based on the transformed virtualized network function definition, the virtualized network function is generated.

Description

Background Art

[0001] Network Function Virtualization (NFV) is a technology for delivering communication services. More specifically, NFV is the application of virtualization and automation technologies for providing network services in a communication service provider network. In this way, communication service providers can transform their communication networks from dedicated hardware infrastructures into general-purpose infrastructures that use virtualized network functions (VNFs) to provide network services. With network function virtualization, much of the hardware in the communication network can be replaced by software that performs the same functionality. Compared with a communication network deployed using only hardware switches, routers, etc., a communication network incorporating VNFs can offer greater flexibility, lower costs, and the ability to introduce new network services in less time. Brief Description of the Drawings

[0002] The present disclosure can be understood from the following detailed description when read in conjunction with the accompanying drawings. In accordance with standard practice in the industry, various features are not drawn to scale. In fact, for clarity of discussion, the dimensions of various features may be arbitrarily increased or decreased.

[0003] Some examples of the present application are described with respect to the following drawings:

[0004] Figure 1 is an example system for generating virtualized network functions.

[0005] Figure 2 is a data flow diagram of an example system for generating virtualized network functions.

[0006] Figure 3 is an example method for generating virtualized network functions.

[0007] Figure 4 is an example method for generating virtualized network functions.

[0008] Figure 5 is an example system having a tangible non-transitory computer-readable medium that stores code for generating virtualized network functions. Detailed Description

[0009] The European Telecommunications Standards Institute (ETSI) has defined models for the NFV architecture. The NFV architecture includes a Virtualized Infrastructure Manager (VIM), a Virtualized Network Function Manager (VNFM), and a Network Function Virtualization Orchestrator (NFVO). The VIM can be responsible for managing the computing, storage, and network resources used to create virtualized network functions. The VNFM can be responsible for the management of individual VNFs. The NFVO can be responsible for combining VNFs and Physical Network Functions (PNFs) to create network services provided by the NFVI. A physical network function can be a network function implemented using hardware devices.

[0010] The VIM (e.g., OpenStack) can use an NFVO called the HEAT orchestrator. In one example implementation, a HEAT orchestration template (HOT file) can be used to define virtualized network functions. The HOT file can be input into the HEAT orchestrator to generate virtualized network functions. However, HOT files have limitations that can result in the generation of virtualized network functions that violate the policies used to manage their standardization or otherwise negatively impact other VNFs. Thus, examples can provide a transformation (translation) of the HOT file to prevent policy violations, prevent malicious use of the HOT file, and / or other potential negative impacts. For example, the HOT file can enable the creation and management of various resources available in the VIM installation. Thus, if the HEAT orchestrator accepts the HOT file, the HEAT orchestrator may not have control over the resources created. Misuse of this capability (maliciously or incorrectly) can negatively impact other VNFs and virtual machines running on the VIM platform.

[0011] Figure 1 is an example system 100 for generating virtualized network functions. System 100 can include a service provider 102, a VIM 104, and a network service 106 connected via a network 120. The service provider 102 can be a communications service provider that provides the network service 106 to its customers. The network service 106 can be a communications service such as email, Voice over Internet Protocol, printing, file sharing, directory services, video on-demand, video telephony, etc. In the example, the network service 106 can include virtualized network functions (VNFs) 108. In one example, these VNFs can be defined by a HEAT orchestration template 110 that can be provided (e.g., by a customer) to the service provider 102. The HEAT orchestration template 110 can define specific resources, such as virtual machines, virtual networks, etc., for building the virtualized network functions 108.

[0012] VIM 104 is a Virtualization Infrastructure Manager (VIM) that can mediate and support the interaction with the physical infrastructure that enables Network Function Virtualization using components such as the Cloud Computing Fabric Controller 112, the Networking Manager 114, and the HEAT Orchestrator 116. The Cloud Computing Fabric Controller 112 (e.g., Nova) can manage a pool of computing resources. The Networking Manager 114 (e.g., Neutron) can manage networks and Internet Protocol (IP) addresses. The HEAT Orchestrator 116 can coordinate calls to the Cloud Computing Fabric Controller 112, the Networking Manager 114, and other VIM services. The NFVO can manage NFV infrastructure components such as the Virtualized Network Function 108. The VNFM can help standardize the functions of virtual networking and improve the interoperability of software-defined networking elements. The HEAT Orchestrator 116 can perform these functions based on the definitions provided in the HEAT Orchestration Template 110.

[0013] However, the HEAT Orchestration Template 110 can only define NFVI components such as virtual machines and virtual networks. In contrast, the Virtualized Network Function 108 and the Network Service 106 can follow a more complex model managed by the Virtualized Network Function Manager (VNFM) and the NFVO. The models managed by the VNFM and the HEAT Orchestrator 116 can impose relationships and policies on the NFVI that are not defined in the HEAT Orchestration Template 110. Therefore, the Transformer 118 can merge the information from the HEAT Orchestration Template 110 with the models of the VNFM and the HEAT Orchestrator 116 to generate a transformed version of the HEAT Orchestration Template 110. The transformed HEAT Orchestration Template 110 can be input into the HEAT Orchestrator 116 to generate the Virtualized Network Function 108 or the Network Service 106.

[0014] For example, a customer may provide a HEAT orchestration template 110 to service provider 102 for network service 106. In one example, network service 106 may be a video-on-demand service. The HEAT orchestration template 110 for the video-on-demand service may define multiple virtualized network functions 108. In one example, the virtualized network functions 108 for the video-on-demand service may include a virtual network with seventy virtual machines, where each virtual machine may include two central processing units (CPUs), a one terabyte (TB) sized disk drive, eight gigabytes (GB) of random access memory (RAM), and four interconnected network ports. However, the models for the VNFM and HEAT orchestrator 116 may include legal traffic interception for specific virtual machines on the virtual network of the service provider. Legal traffic interception may refer to when a telecommunications network is subject to a court order to wiretap a specific customer and provide the network communications for that customer to law enforcement agencies. Thus, in an example, the converter 118 may generate a new HEAT orchestration template 110, where the virtual machines specified in the original HEAT orchestration template 110 are modified to include additional virtual ports for connection to legal traffic interception. Thus, the converted HEAT orchestration template 110 may be input into the HEAT orchestrator 116 to generate the video-on-demand service requested by the customer.

[0015] Figure 2 is a data flow diagram of an example system 200 for generating virtualized network functions. In the example, a HOT file 202 and additional information 204 may be input into an ingestion process 206. The HOT file 202 may be a HEAT orchestration template (such as HEAT orchestration template 110) that defines virtualized network functions and network services (such as virtualized network functions 108 and network service 106). The additional information 204 may represent scripts that may run on the virtual machines defined in the HOT file 202. In the ingestion process 206, the HOT file 202 may be broken down into individual elements (such as virtual machines, virtual networks, ports, etc.) to build an internal model 208. The internal model 208 may include elements that would be created if the HOT file 202 and additional information were deployed using an orchestrator (such as HEAT orchestrator 116). In an alternative example, the ingestion process 206 may accept input in a format different from the HOT format of the HOT file 202 and may use existing tools to convert the input into the HOT format before further processing.

[0016] The internal model 208 can be input into the transformation process 210. During the transformation process 210, a converter (such as converter 118) can map individual elements and relationships in the internal model 208 to an internal model (not shown) of the HEAT orchestrator 116. The internal model of the HEAT orchestrator 116 can include prescribed parameters for potential VNFs 108 that can be defined in the HOT file 202. The mapped elements and relationships can be recorded in a set of orchestrator-modeled resources 214. The orchestrator-modeled resources 214 can apply prescribed elements from the internal model of the HEAT orchestrator 116 to individual elements of the HOT file 202. When there is no possible direct mapping between individual elements of the internal model 208 and the internal model of the HEAT orchestrator 116, the individual elements are converted into HOT fragments 212, which are elements that describe the details of the unmapped elements and include pointers to elements in other HOT fragments 212 and orchestrator-modeled resources 214. In an alternative example, the transformation process 210 can accept additional inputs that affect the transformation. One example of an additional input can be a mapping file that guides the separation of resources within the complex HOT file 202 into separate VNFs 108.

[0017] The HOT fragments 212 and the orchestrator-modeled resources 214 can be input into the validation and transformation process 216. During the validation and transformation process 216, the HEAT orchestrator 116 can accept or reject the orchestrator-modeled resources 214. Alternatively, the HEAT orchestrator 116 can automatically apply changes so that the policy 220 is satisfied. The policy 220 can specify conditions for implementing a particular type of VNF 108. For example, one policy 220 can specify that for each virtual machine that processes end-user traffic, an additional port that is connected to the network and dedicated to lawful interception can be added.

[0018] The HOT fragments 212 can also be rejected or accepted based on the whitelist and blacklist 218, or defined transformations. The whitelist can specify virtualized network functions 108 that are permitted by the service provider 102. In contrast, the blacklist can specify virtualized network functions 108 that are disabled by the service provider 102. Additionally, where automation is not possible, the HOT fragments 212 can undergo a manual approval process, whereby the complete HOT file 202 can be isolated until the manual approval process 222 is complete.

[0019] The HOT fragment 212 and the orchestrator-modeled resources 214 output from the validation and transformation process 216 can be input into an onboarding process 226. The onboarding process 226 can involve the creation of the VNF 108 and the network service 106 as defined in the HOT fragment 212 and the orchestrator-modeled resources 214. During the onboarding process 226, the HOT fragment 212 and the orchestrator-modeled resources 214 are updated with additional information 224. The additional information 224 is information that supplements the NFVI defined in the HOT fragment and the orchestrator-modeled resources 214 and further defines the VNF 108 and the network service 106. The additional information can include element manager scripts, forwarding graphs, and other resources specified by the service provider 102 that may not have been considered by the customer. The fully virtualized network function 108 and the network service 106 modeled in this way can hold the HOT fragment 212 for those features that are not included in the internal model of the HEAT orchestrator 116 and are accepted (either automatically or through a manual approval process 222). The onboarding process 226 generates a VNF and a HOT fragment 228, which are input into a deployment process 230.

[0020] During the deployment process 230, the VNF and the HOT fragment 228 can be reviewed for any potential warnings or confirmations. If the VNF and the HOT fragment 228 contain a blacklisted HOT fragment, a warning can be provided, or confirmation can be requested from the service provider 102 before deploying the VNF 108. If the VNF and the HOT fragment 228 do not include any HOT fragments, the deployment process 230 proceeds as specified by the HEAT orchestrator 116. If there are HOT fragments 212, the HEAT orchestrator can build a new HOT file 232 from the artifacts in the internal model of the HEAT orchestrator 116 and merge these artifacts with the HOT fragment 212. The HEAT orchestrator 116 of the VIM 234 can then deploy the VNF 108 and the network service 106 accordingly.

[0021] Alternatively, even if the VNF and the fragment 228 include the HOT fragment 212, the normal mechanism of the HEAT orchestrator 116 can be used. The HEAT orchestrator 116 can then perform discovery and mediation steps to obtain the values of the created VNF 108 and the network service 106. Additionally, the HEAT orchestration template 110 that contains only the HOT fragment 212 can be deployed via the HEAT orchestrator 116.

[0022] In another example, the validation and transformation process 216 can mark the HOT fragment 212 as isolated. Thus, in the deployment process 230, the isolated HOT fragment can be deployed to a different virtualization infrastructure manager, and thus the VNF 108 defined by the isolated HOT fragment 212 can be monitored for verification. For example, verification can involve ensuring that the isolated HOT fragment does not violate any policies 220.

[0023] Advantageously, merging the information from the HEAT orchestration template 110 with the internal model of the NFVO allows for the instantiation of other VIMs without using the HEAT orchestrator 116. Additionally, elements that are repeatedly described in multiple HEAT orchestration templates 110 (such as flavors) can be transformed into common shared resources based on the specified policies 220 and additional information 224. A flavor can define the compute, memory, and storage capacity of a virtual server. Additionally, this merging enables the service provider to blacklist specific HEAT features, for example, due to security rules. Also, merging in this way makes it possible to enhance and enforce policies. For example, the service provider 102 can implement a policy to provide at least one connection to a backup network to each virtual machine. In another example, a policy that is restricted by an allowed network address mask can be enhanced to mitigate the issue of IPV4 address space conservation.

[0024] Figure 3 is an example method 300 for generating virtualized network functions. The method 300 can be executed by an NFVO (such as the HEAT orchestrator 116) and a converter (such as the converter 118). At block 302, the converter 118 can build an internal model of the virtualized network function 108 based on the HEAT orchestration template 110.

[0025] At block 304, the converter 118 can map the elements and relationships of the internal model built by the converter 118 to the internal model of the HEAT orchestrator 116. Elements and relationships of the internal model built by the converter 118 that cannot be mapped to the internal model of the HEAT orchestrator 116 can be transformed into HOT fragments, such as the HOT fragment 212. The HOT fragment 212 can describe the details of the elements and the pointers related to the elements.

[0026] At block 306, the HEAT orchestrator 116 can verify and transform the mapping. In other words, the HEAT orchestrator 116 can accept, reject, or automatically apply changes to the elements and relationships mapped to the internal model of the HEAT orchestrator 116. In this way, the policy can be enhanced. For example, a policy related to permissions can state that "organization X cannot use image Z to deploy more than Y simultaneous virtual machines". In the example, such a policy can only be enhanced by looking at the files to be deployed and all previously deployed files. Additionally, the HEAT orchestrator 116 can accept or reject HOT fragments 212 based on a whitelist or blacklist, such as whitelist and blacklist 218. Alternatively, the HOT fragments 212 can be isolated before the manual approval process is implemented.

[0027] At block 308, the HEAT orchestrator 116 can supplement the mapped elements and relationships with additional information, such as element manager scripts, forwarding graphs, etc. At block 310, the HEAT orchestrator 116 can generate a warning for any HOT fragment 212 that is blacklisted. At block 312, for any HOT fragment 212 that is whitelisted, the HEAT orchestrator 116 can generate a new HOT file 232 that merges the whitelisted HOT fragment with the elements mapped to the internal model.

[0028] At block 314, the HEAT orchestrator 116 can generate new virtualized network functions 108 and network services 106 described in the newly generated HEAT orchestration template 110.

[0029] It should be understood that Figure 3 the process flow diagram is not intended to indicate that method 300 includes all of the blocks shown in Figure 3 each case. Additionally, depending on the details of the specific implementation, any number of additional blocks can be included within method 400. Further, it should be understood that Figure 3 the process flow diagram is not intended to indicate that method 300 proceeds only in the order indicated by the Figure 3 blocks in each case. For example, block 304 can be rearranged to occur before block 302.

[0030] Figure 4This is an example method 400 for generating virtualized network functions. Method 400 can be executed by an NFVO (such as the HEAT orchestrator 116) and a converter (such as the converter 118). At block 402, the HEAT orchestrator 116 can identify the mappable and unmappable elements of a virtualized network function template based on a network function virtualization model. The virtualized network function template can include, for example, the HEAT orchestration template 110.

[0031] At block 404, the HEAT orchestrator 116 can map the mappable elements to the network function virtualization model. At block 406, the converter 118 can transform the mappable elements based on the mapping to generate one or more transformed elements. As previously stated, the converter 118 can map individual elements and relationships in the internal model 208 to the internal model of the HEAT orchestrator 116. The mapped elements and relationships can be recorded in the orchestrator-modeled resources 214, and the orchestrator-modeled resources 214 can apply the specified elements from the internal model 208 to the individual elements of the HOT file 202. Additionally, when there is no direct mapping between the elements of the internal model 208 and the internal model of the HEAT orchestrator 116, the converter 118 generates the HOT fragment 212.

[0032] At block 408, the converter 118 can filter the unmappable elements based on a black-white list to generate one or more filtered elements. For example, the converter 118 can use a filter (such as the white list-black list 218).

[0033] At block 410, the HEAT orchestrator 116 can generate a transformed virtualized network function definition that includes the transformed elements and the filtered elements. The transformed virtualized network function definition can include, for example, a new HOT file 232. At block 412, the HEAT orchestrator 116 can generate a virtualized network function based on the transformed virtualized network function definition.

[0034] It should be understood that Figure 4 the process flow diagram is not intended to indicate that method 400 must include all of the blocks shown in Figure 4 each case. Additionally, depending on the details of a particular implementation, any number of additional blocks can be included within method 400. Further, it should be understood that Figure 4 the process flow diagram is not intended to indicate that method 400 proceeds only in the order indicated by the Figure 4 blocks in each case. For example, block 404 can be rearranged to occur before block 402.

[0035] Figure 5is an example system 500 having a tangible, non-transitory computer-readable medium 506 that stores code for generating virtualized network functions. The tangible, non-transitory computer-readable medium is generally referred to by reference numeral 506. The tangible, non-transitory computer-readable medium 506 may correspond to any typical computer memory that stores computer-implemented instructions, such as programming code, etc. For example, the tangible, non-transitory computer-readable medium 506 may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and that can be accessed by a computer. As used herein and as used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and disc, where a disk generally reproduces data magnetically, while a disc uses lasers to reproduce data optically.

[0036] The tangible, non-transitory computer-readable medium 506 can be accessed by a processor 502 via a computer bus 504. A region 508 of the tangible, non-transitory computer-readable medium stores computer-executable instructions that identify mappable and non-mappable elements of a virtualized network function template based on a network function virtualization model. A region 510 of the tangible, non-transitory computer-readable medium stores computer-executable instructions that map the mappable elements to the network function virtualization model. A region 512 of the tangible, non-transitory computer-readable medium stores computer-executable instructions that transform the mappable elements based on the mapping to generate one or more transformed elements. A region 514 of the tangible, non-transitory computer-readable medium stores computer-executable instructions that filter the non-mappable elements based on a black-white list to generate one or more filtered elements. A region 516 of the tangible, non-transitory computer-readable medium stores computer-executable instructions that generate a transformed virtualized network function definition that includes the transformed elements and the filtered elements. A region 518 of the tangible, non-transitory computer-readable medium stores computer-executable instructions that generate a virtualized network function based on the transformed virtualized network function definition.

[0037] Although shown as contiguous blocks, the software components can be stored in any order or configuration. For example, if the tangible, non-transitory computer-readable medium 506 is a hard drive, the software components can be stored in non-contiguous, or even overlapping, sectors.

[0038] For purposes of explanation, the foregoing description uses specific terms to provide a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that the systems and methods described herein may be practiced without the use of specific details. The foregoing description of specific examples is presented for purposes of illustration and description. They are not intended to be exhaustive of the present disclosure or to limit the present disclosure to the precise forms described. Obviously, many modifications and variations are possible in light of the above teachings. For the purpose of best explaining the principles of the present disclosure and its practical applications, examples have been shown and described so that others skilled in the art can best utilize the present disclosure and various examples with various modifications suitable for the particular purposes contemplated. The scope of the present disclosure is intended to be defined by the claims and their equivalents.

Claims

1. A method for virtualizing network functions, comprising: Identifying one or more mappable elements and one or more unmappable elements of a virtualized network function template based on a network function virtualization model; Mapping the mappable elements to the network function virtualization model; Converting the mappable elements based on the mapping to generate one or more converted elements; Filtering the unmappable elements based on a black - white list to generate one or more filtered elements, wherein the unmappable elements are converted to indicate details of the corresponding unmappable elements and pointers to related elements; Generating a converted virtualized network function definition including the converted elements and the filtered elements; and Generating the virtualized network function based on the converted virtualized network function definition.

2. The method according to claim 1, comprising: Generating multiple virtualized network functions based on the converted virtualized network function definition.

3. The method according to claim 2, comprising: Generating a network service including the multiple virtualized network functions.

4. The method according to claim 1, wherein the virtualized network function template includes a HEAT orchestration template.

5. The method according to claim 1, comprising: Generating a HEAT orchestration template based on the virtualized network function template, wherein the mappable elements are mapped based on the HEAT orchestration template.

6. The method according to claim 1, wherein the virtualized network function is generated by a HEAT orchestrator.

7. The method according to claim 1, wherein the black - white list includes a blacklist specifying one or more blacklisted elements, and the one or more blacklisted elements are not generated for the virtualized network function.

8. The method according to claim 1, wherein the black - white list includes a whitelist specifying one or more whitelisted elements, and the one or more whitelisted elements are generated for the virtualized network function.

9. A system for virtualizing network functions, comprising: A processor; And A memory device, the memory device including computer - implemented code to: Identify one or more mappable elements and one or more unmappable elements of a virtualized network function template based on a network function virtualization model; Map the mappable elements to the network function virtualization model; Convert the mappable elements based on the mapping to generate one or more converted elements; Filter the unmappable elements based on a black - white list to generate one or more filtered elements, wherein the unmappable elements are converted to indicate details of the corresponding unmappable elements and pointers to related elements; Generate a converted virtualized network function definition including the converted elements and the filtered elements; and Generate the virtualized network function based on the converted virtualized network function definition.

10. The system according to claim 9, wherein the memory device includes computer - implemented code to generate multiple virtualized network functions based on the converted virtualized network function definition.

11. The system according to claim 10, wherein the memory device includes computer - implemented code to generate a network service including the multiple virtualized network functions.

12. The system according to claim 9, wherein the virtualized network function template includes a HEAT orchestration template.

13. The system according to claim 9, wherein the memory device includes computer-implemented code to generate a HEAT orchestration template based on the virtualized network function template, and wherein the mappable elements are mapped based on the HEAT orchestration template.

14. The system according to claim 9, wherein the virtualized network function is generated by a HEAT orchestrator.

15. The system according to claim 9, wherein the black-white list includes a black list specifying one or more blacklisted elements that are not generated for the virtualized network function.

16. The system according to claim 9, wherein the black-white list includes a white list specifying one or more whitelisted elements that are generated for the virtualized network function.

17. A non-transitory computer-readable medium storing computer-executable instructions that, when executed, cause a computer to: Identify one or more mappable elements and one or more unmappable elements of a virtualized network function template based on a network function virtualization model; Map the mappable elements to the network function virtualization model; Transform the mappable elements based on the mapping to generate one or more transformed elements; Filter the unmappable elements based on a black-white list to generate one or more filtered elements, where the unmappable elements are transformed to indicate details of the corresponding unmappable elements and pointers to related elements; Generate a transformed virtualized network function definition including the transformed elements and the filtered elements; and Generate the virtualized network function based on the transformed virtualized network function definition.

18. The medium according to claim 17, wherein the computer-executable instructions, when executed, cause the computer to generate a plurality of virtualized network functions based on the transformed virtualized network function definition.

19. The medium according to claim 17, wherein the computer-executable instructions, when executed, cause the computer to generate a network service including the plurality of virtualized network functions.

20. The medium according to claim 19, wherein the virtualized network function template includes a HEAT orchestration template.

Images