Patent Description:
Due to recent network focused advancements in computing hardware, services that were previously only capable of being delivered by proprietary, application-specific hardware can now be provided using software running on computing hardware by utilizing virtualization techniques that run on high-volume server, switch, and storage computing hardware to virtualize network functions. By leveraging virtualization technology to consolidate different types of network equipment onto the computing hardware, switches, storage, and network functions, such as network address translation (NAT), firewalling, intrusion detection, domain name service (DNS), load balancing, caching, and the like can be decoupled from computing hardware and can instead be run as software. This virtualization of network functions on commodity hardware is sometimes referred to as Network Functions Virtualization (NFV).

Network Functions Virtualization (NFV) refers to a technology that is used to design a network structure with industry standard servers, switches, and storage that are provided as devices at a user end. That is, the NFV technology implements network functions as software that can be run in existing industry standard servers and hardware. NFV technology may also be supported by a cloud computing technology and in some cases, may also utilize various industry-standard high volume server technologies.

In an effort to develop a fully virtualized infrastructure, leading service providers have collaborated together to create the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) for Network Functions Virtualization (NFV) working group. This group has helped create the architecture and associated requirements for virtualizing various functions within telecommunications networks. Benefits of NFV include reduced capital expenditure (e.g., by reducing the need to purchase purpose-built hardware), operating expenditure (e.g., by reducing space, power, and cooling requirements), reduced time-to-market (e.g., accelerated deployment), improved flexibility to address constantly changing demands, and the like.

<CIT> describes, according to its abstract, a computer-implemented method, carried out by one or more processors, for managing resources in a server environment. The method includes determining, by one or more processors, to shut down a first resource consumer, wherein the first resource consumer is assigned a first virtual resource with a first set of one or more host resources. It is determined, by one or more processors, whether a second virtual resource assigned to a second resource consumer requires the first set of one or more host resources. If the second virtual resource assigned to the second resource consumer does not require the first set of one or more host resources, it is determined, by one or more processors, not to deactivate the one or more host resources assigned to the first virtual resource.

The disclosure will be readily understood by the following detailed description in conjunction with the accompanying drawings in which:.

Disclosed are systems, methods and computer-readable devices related to a virtual network function (VNF) service that, when a VNF is un-deployed with the intention of changing or tuning some configuration and instantiating it again, the underlying resources used to support that VNF are not released to be used by other VNFs. Many scenarios exist where the VNF needs to be un-deployed (e.g., brought down) to fix or change a configuration mistake that was done while instantiating the VNF. Embodiments of the present disclosure provide a system, method, and computer-readable instructions to maintain the resources in a dedicated condition in relation to the VNF so that, after the VNF has been un-deployed, the VNF may again be re-deployed on those dedicated resources.

Additional systems, methods and computer-readable devices provide a user interface that displays existing VNFs and a means to un-deploy the VNF instances. When users are finished reconfiguring and making changes to the VNF, they can reinstate the VNF. While un-deployed, the NFV orchestration framework does not release the resources, such as central processing units (CPUs), memory, disk space, and the like, back to the cloud. Additionally, the user interface provides means for releasing the resources back to the cloud in the event that the VNF is no longer needed or desired.

<FIG> illustrates an example network functions virtualization (NFV) environment <NUM> in which a virtual network function (VNF) management system <NUM> for releasing and retaining cloud resources may be embodied. The system <NUM> includes a NFV orchestrator <NUM> that communicates with a client computing device <NUM> to configure and deploy a VNF <NUM> on one or more resources <NUM> in the NFV environment <NUM>. According to embodiments of the present disclosure, the NFV orchestrator <NUM> provides a technique for, when a previously deployed VNF <NUM> is to be temporarily un-deployed for some reason, such as to fix a configuration mistake in the VNF <NUM>, the resources <NUM> used to support the VNF <NUM> are maintained in a dedicated condition in relation to the VNF <NUM> so that the VNF <NUM> may again be deployed on those same resources. In additional embodiments, the system <NUM> also provides a user interface <NUM> for displaying the VNF <NUM> in a deployed or an un-deployed condition, receiving user input to re-deploy the VNF <NUM>, and/or un-deploy the underlying resources when use of the VNF <NUM> is no longer needed or desired.

In general, VNFs <NUM> configured in a NFV environment are typically deployed using a technique as specified according to a specification, such as the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) for Network Functions Virtualization (NFV) working group. The ETSI/ISG/NFV specification specifies a certain sequence of operations that should be performed so that, among other things, the resulting VNFs <NUM> function properly in a consistent manner, and that the resources used to support those functions have ample performance capabilities. Additionally, when the VNF <NUM> is un-deployed, the specification specifies certain other operations that should be performed so that the VNF <NUM> is properly un-deployed, and that the resources allocated to the VNF <NUM> is given back to a resource pool so that those resources may be used by other VNFs.

In some cases, it would be beneficial to temporarily un-deploy the VNF <NUM>. For example, the VNF <NUM> may have been deployed using a port assignment that is incompatible with another VNF <NUM>, such as via a static Internet protocol (IP) address, or a target IP address/port for a remote destination that is mis-configured during deployment of the VNF <NUM>. To fix these problems, the VNF <NUM> could un-deployed and re-deployed; however, conventional techniques for deploying VNFs <NUM>, such as those promulgated by the ETSI/ISG/NFV specification, specifies that the underlying resources are also de-allocated when the VNF <NUM> is un-deployed, thus releasing the resources <NUM> back to a common pool to be used by other VNFs <NUM>.

Although de-allocating the underlying resources used to support a VNF may appear to provide an adequate solution, it may engender other problems. For example, the physical location of the allocated resources <NUM> may be proximate to and/or have similar performance characteristics to other resources <NUM> used to support another VNF <NUM> that is to be used with the subject VNF <NUM>. Thus, in this case, it would be beneficial to keep those resources <NUM> dedicated for use with the VNF <NUM> so that, when the VNF <NUM> is temporarily un-deployed, those resources <NUM> may again be used for supporting the VNF <NUM> in the NFV environment. Additionally, de-allocation and re-allocation of the underlying resources can be a time consuming task that often is an inefficient and cumbersome endeavor.

Certain embodiments of the present disclosure provide a solution to this problem by providing a system that allows a VNF <NUM> to be un-deployed and re-deployed using a technique that maintains the underlying resources used to support the VNF <NUM> in a dedicated state relative to the VNF <NUM>. Thus, a VNF <NUM> can be un-deployed and re-deployed to leverage the advantages of any initialization processes configured for that VNF <NUM>, while ensuring that the underlying resources remain available to support that VNF <NUM> when it is re-deployed.

The resources <NUM> on which the VNF <NUM> may be deployed may be embodied on any suitable computing architecture having multiple resources <NUM> for supporting the VNF <NUM>. For example, the NFV environment <NUM> may include a unified computing system, a fabric-based computing system, a dynamic infrastructure, and/or a combination thereof. In a particular example, the NFV environment <NUM> may include a virtualized computing environment having one or more physical resources 114a that execute one or more virtual machine (VM) resources 114b. It should be understood that the NFV environment <NUM> may include other components, such as gateways for secure management of data used by the VNF <NUM>, communication nodes for communication among multiple computing systems, and/or other devices that support the overall operation of the NFV environment <NUM>.

The NFV environment <NUM> may involve multiple computing components pre-integrated into an optimized computing solution. The computing components of the NFV environment <NUM> may include servers, data storage components, networking equipment and software for managing the integrated components. To assist in the scalability, management and sharing of resources, particularly in large computing system environments, the NFV environment <NUM> may include a pool of server, storage and networking resources, typically virtualized, that can be shared by multiple VNFs <NUM>.

Example hardware resources 114a of the NFV environment <NUM> may include any type of hardware that provides physical resources for the virtual computing environment, while the virtual resources 114b include logical entities, such as virtual machines, virtual switches, virtual storage units, containers, and other forms of partitioning constructs. Virtual resources 114b may also include logical configuration constructs, such as storage partitions, port groups, virtual private clouds, virtual local area networks (LANs), private virtual data centers (PVDCs), that may be individually allocated to one or more VNFs. These hardware resources 114a and virtual resources 114b function in a collaborative manner to support the VNFs <NUM>.

The resources <NUM> of the NFV environment <NUM> may be managed by a resource manager <NUM>. Generally speaking, the resource manager <NUM> communicates with the physical resources 114a and virtual resources 114b (e.g., VMs) of the NFV environment <NUM> to manipulate the operation of the resources <NUM>, as well as obtain status information, and report the status information to a user. In some embodiments, the resource manager <NUM> may function according to an OpenStack™ software platform. For an example in which the NFV environment <NUM> includes a virtualized computing environment, the compute resources may be managed by an element management application <NUM>, such as a Unified Compute System Management (UCSM) application that is available from Cisco Systems.

The VNF manager <NUM> may include any type that manages the operation of the VNF <NUM>, and communicates with the NFV orchestrator <NUM> for deploying the VNF <NUM> on the resources <NUM> of the NFV environment <NUM> through an VNF element manager <NUM>. In some embodiments, the VNF manager <NUM> functions according to an operational support system (OSS) that manages various operations of the VNF <NUM> as well as other VNF related devices in the NFV environment <NUM>. The VNF element manager <NUM> may be included to, among other things, provide network configuration of each or a combination of VNFs <NUM>, network inventory of VNFs <NUM> in the NFV environment <NUM>, network configuration of VNFs in the NFV environment <NUM>, and fault management of VNFs in the NFV environment <NUM>.

<FIG> illustrates a call flow diagram <NUM> showing how the system <NUM> deploys the VNF <NUM> in the NFV environment according to some embodiments of the present disclosure. At step <NUM>, the NFV orchestrator <NUM> receives a request from the client computing device <NUM> for deploying the VNF <NUM>. Thereafter at step <NUM>, the NFV orchestrator <NUM> validates the request. For example, the NFV orchestrator <NUM> may validate the request by ensuring the client computing device <NUM> is authorized to request deployment of the VNF <NUM> and/or a type of the VNF <NUM> requested by the client computing device <NUM>. The NFV orchestrator <NUM> may also check the feasibility of the VNF deployment at step <NUM>. For example, the NFV orchestrator <NUM> may check the request against one or more rules or policies to ensure that the VNF <NUM> and/or characteristics of the VNF <NUM> are supported by the NFV environment <NUM>.

At step <NUM>, the NFV orchestrator <NUM> transmits a request to the VNF manager <NUM> to deploy the VNF <NUM>. In turn, the VNF manager responds by validating the request at step <NUM>. For example, the VNF manager <NUM> may validate the request by ensuring sufficient resource capacity exist for fulfilling the request, and/or that the NFV environment possesses the capabilities for deploying the VNF <NUM> using certain parameters to be associated with the VNF <NUM> included in the request. When the request is validated at step <NUM>, the VNF manager <NUM> transmits a response to the request back to the NFV orchestrator <NUM> requesting that certain resources <NUM> be allocated for supporting the VNF <NUM>.

At step <NUM>, the NFV orchestrator <NUM> performs one or more pre-allocation processing for deploying the VNF <NUM>. For example, the NFV orchestrator <NUM> may update records stored in its memory indicating certain characteristics of the VNF <NUM>, such as information associated with the user who issued the request through the client computing device <NUM>, accounting information (e.g., lease information) to be assessed to the user for use of the VNF <NUM>, and the like. According to some embodiments, the NFV orchestrator may also store identifying information for the resources <NUM> so that they may be dedicated for use with the VNF <NUM>.

Thereafter at step <NUM>, the NFV orchestrator <NUM> transmits a request to the resource manager <NUM> to allocate one or more resources <NUM> for the VNF <NUM>. In turn, the resource manager <NUM> allocates its internal connectivity network at step <NUM> to support the resources <NUM>. For example, the resource manager <NUM> may deploy and configure one or more virtual network resources <NUM> (e.g., a load balancer, a router, etc.) that are to be used by certain other resources <NUM> for supporting the VNF <NUM>. Thereafter at step <NUM>, the resource manager <NUM> allocates the other resources <NUM> (e.g., VMs) and attaches the resources <NUM> to the network configured at step <NUM>. The resource manager <NUM> then transmits an acknowledgement message back to the NFV orchestrator <NUM> in response to the request transmitted at step <NUM> indicating that the resources <NUM> of the NFV environment <NUM> have been allocated to support the VNF <NUM> at step <NUM>.

At step <NUM>, the NFV orchestrator <NUM> transmits an acknowledgement message back to the VNF manager <NUM> indicating that the resources <NUM> of the NFV environment <NUM> have been successfully allocated. As a result, the VNF manager <NUM> configures the VNF <NUM> with deployment specific parameters (e.g., port assignments, routing tables, routing rules, etc.). For example, the VNF manager <NUM> may communicate with certain resources <NUM> configured by the resource manager <NUM> in steps <NUM> and <NUM> with additional parameters necessary for implementing the VNF <NUM>. The VNF manager <NUM> also notifies the VNF element manager <NUM> that the VNF has been successfully deployed at step <NUM>. Thereafter at step <NUM>, the VNF element manager <NUM> configures the newly deployed VNF <NUM> with any particular parameters obtained from the VNF manager <NUM> at step <NUM>.

At step <NUM>, the VNF manager <NUM> transmits an acknowledgement message to the NFV orchestrator <NUM> indicating that the VNF <NUM> has been successfully deployed in which the NFV orchestrator <NUM> responds by transmitting an acknowledgement message to the client computing device <NUM> with the indication at step <NUM>.

At this point, the VNF <NUM> has been deployed and is available for use by the user of the client computing device <NUM>.

<FIG> illustrates an example call flow diagram <NUM> that may be performed by the system <NUM> according to some embodiments of the present disclosure. Initially, the VNF <NUM> has been previously deployed in the NFV environment <NUM>. For example, the steps of the call flow diagram <NUM> may be performed after the steps of <NUM>-<NUM> have been performed as shown and described above with respect to <FIG>.

At step <NUM>, the NFV orchestrator <NUM> receives a request from the client computing device <NUM> to un-deploy (e.g., terminate) the VNF <NUM>. Thereafter at step <NUM>, the NFV orchestrator <NUM> validates the request. For example, the NFV orchestrator <NUM> may validate the request by ensuring the client computing device <NUM> is authorized to request un-deployment of the VNF <NUM>. At step <NUM>, the NFV orchestrator <NUM> transmits a request to the VNF manager <NUM> to un-deploy the VNF <NUM>, in which the VNF manager <NUM> responds by un-deploying the VNF <NUM> at step <NUM>. The VNF manager <NUM> then transmits an acknowledgement message to the NFV orchestrator <NUM> indicating that the VNF <NUM> has been successfully un-deployed from the NFV environment <NUM> at step <NUM>.

At this point, the VNF <NUM> has been un-deployed from the NFV environment <NUM>, while the resources <NUM> remain allocated for use with the VNF <NUM>. For example, although the VNF <NUM> has been un-deployed at step <NUM>, information associated with the resources <NUM> used to support the VNF <NUM> that has been stored at step <NUM> (See <FIG>) remains persistent in the NFV orchestrator <NUM>. Thus, the VNF <NUM> can be re-deployed on those same resources <NUM> using information stored in the NFV orchestrator <NUM>. In one aspect, the resources <NUM> remain allocated to the VNF <NUM> because the resource manager <NUM> has not yet been notified that the underlying resources <NUM> used to support the VNF <NUM> has been un-deployed. Thus, the resource manager <NUM> receives no request to de-allocate the resources <NUM> used to support the VNF <NUM> and therefore does not de-allocated those resources <NUM>. Additionally, because the resources <NUM> remain allocated for use with the VNF <NUM>, other VNFs are restricted from using those resources <NUM>.

At step <NUM>, the NFV orchestrator <NUM> again deploys the VNF <NUM> using the resources <NUM> that have been previously allocated. In some embodiments, the system <NUM> may deploy the VNF <NUM> in a similar manner that the VNF <NUM> was deployed in steps <NUM>-<NUM> and <NUM>-<NUM> of <FIG>. However, rather than performing the one or more pre-allocation processing for deploying the VNF <NUM> as is performed in step <NUM>, the NFV orchestrator <NUM> obtains a unique identity of the VNF <NUM> being deployed, identifies the resources <NUM> that have been previously allocated to that VNF <NUM> according to information about the resources <NUM> stored in its memory, and selects those resources <NUM> to be used for supporting the VNF <NUM>. At this point, the VNF <NUM> is now fully deployed again using the resources <NUM> that have been previously allocated for that VNF <NUM>.

At some later point in time, it may be desired to un-deploy the VNF <NUM>. Therefore, at step <NUM>, the NFV orchestrator <NUM> may un-deploy the VNF <NUM> that has been deployed at step <NUM>. For example, the system <NUM> may un-deploy the VNF <NUM> in a similar manner that the VNF <NUM> was un-deployed in steps <NUM>-<NUM>. At this point, the VNF <NUM> has been un-deployed, but the resources <NUM> used to support the VNF <NUM> are still allocated for use with that VNF <NUM>. Thus, the VNF <NUM> may again be deployed by performing step <NUM> again, or the resources <NUM> used to support the VNF <NUM> may be de-allocated so that those resources <NUM> may be added to the common pool to be used by other VNFs as described herein below at steps <NUM>-<NUM>.

At step <NUM>, the NFV orchestrator <NUM> transmits a request to the resource manager <NUM> to de-allocate the resources <NUM> used to support the VNF <NUM>. In turn, the resource manager <NUM> de-allocates its internal connectivity network at step <NUM>. For example, the resource manager <NUM> may delete the one or more previously allocated virtual network resources <NUM> (e.g., load balancers, routers, switches, etc.) that were allocated at step <NUM>. Thereafter at step <NUM>, the resource manager <NUM> de-allocates the resources <NUM> (e.g., VMs) allocated at step <NUM>. The resource manager <NUM> then transmits an acknowledgement message back to the NFV orchestrator <NUM> indicating that the resources <NUM> have been de-allocated at step <NUM>. Upon receipt of the acknowledgement message, the NFV orchestrator <NUM> then transmits an acknowledgement message to the client computing device <NUM> with the indication at step <NUM>. At this point, the resources <NUM> have been de-allocated and are returned to the resource pool to be used to support the deployment of another VNF <NUM> by the system.

<FIG> and <FIG> illustrate an example main user interface screen <NUM> and a VNF management user interface screen <NUM>, respectively, that may be generated on the client computing device <NUM> according to some embodiments of the present disclosure. The main user interface screen <NUM> generally displays one or more icons <NUM> each representing an individual deployed VNF <NUM> in the system <NUM>. For example, icon 402a may represent a first VNF <NUM> deployed in the NFV environment <NUM>, icon 402b may represent a second VNF <NUM> deployed in the NFV environment <NUM>, while icon 402c may represent a third VNF <NUM> deployed in the NFV environment <NUM>. In a particular example, the VNFs <NUM> associated with the icons <NUM> may be generated by the NFV orchestrator <NUM> when steps <NUM>-<NUM> of <FIG> for each VNF <NUM> have been successfully completed.

The main user interface <NUM> provides for receiving user input for deploying, un-deploying, modifying, and/or monitoring VNFs <NUM> in the NFV environment. For example, the main user interface screen <NUM> may receive user input for performing steps <NUM>-<NUM> for un-deploying the VNF <NUM> and de-allocating its associated resources <NUM>. The main user interface screen <NUM> also displays an un-deployment icon <NUM> that allows the user to un-deploy the VNFs <NUM> associated with each of the icons <NUM> shown in the main user interface <NUM> without de-allocating its underlying resources <NUM>. For example, to un-deploy one of the VNFs <NUM> without de-allocating its resources <NUM>, one or more of the icons <NUM> may be selected followed by selection of the un-deployment icon <NUM>. In response to selection of the un-deployment icon <NUM>, the system <NUM> may generate the VNF management user interface screen <NUM> as shown in <FIG>.

The VNF management user interface screen <NUM> displays a detailed list of certain parameters associated with each of the icons <NUM> displayed in the main user interface screen <NUM>. The management user interface screen <NUM> may display an indication of the VNFs <NUM> in rows <NUM> in which certain parameters of each VNF <NUM> is displayed in columns <NUM>. As shown, the VNF management user interface screen <NUM> displays a name of the VNF <NUM> in a column 414b, a number of CPUs allocated to the VNF <NUM> in column 414c, an amount of volatile memory allocated to the VNF <NUM> in column 414d, and amount of persistent storage (e.g., hard disk storage) allocated to the VNF <NUM> in column 414e. Although a VNF name, a number of CPUs, an amount of volatile memory, and an amount of persistent storage are shown, it should be appreciated that any parameter may be displayed in the VNF management user interface screen <NUM> without departing from the scope of the present disclosure.

The VNF management user interface screen <NUM> also includes a column 414a having a selectable field in each row <NUM> along with a 'Release' button <NUM> and a 'Restore' button <NUM> that can be used to un-deploy or re-deploy its associated VNF <NUM> without unallocating its underlying resources <NUM>. For example, by receiving selection of a field in a row of a particular VNF, followed by selection of the 'Release' button <NUM>, the system <NUM> may perform steps <NUM>-<NUM> of <FIG> to un-deploy that particular VNF <NUM> without de-allocating its underlying resources <NUM>. Conversely, the system <NUM> may receive selection of a field in a row of the particular VNF, followed by selection of the 'Restore' button <NUM> to perform steps <NUM>-<NUM> of <FIG> for re-deploying the VNF <NUM> onto the resources <NUM> again.

Although <FIG> and <FIG> illustrate example screens that may be used for receiving user input to un-deploy and re-deploy on resources <NUM> without de-allocating those resources <NUM>, the system <NUM> may include additional, fewer, or different entry screens without departing from the scope of the present disclosure. For example, the system may include one or more other screens for facilitating display of information to the customer, and/or received user input from the customer for other operations to be performed on the VNFs <NUM>.

<FIG> illustrates several basic hardware components that can apply to system examples of the present disclosure. For example, the NFV orchestrator <NUM>, the VNF manager <NUM>, the client computing device <NUM>, the resource manager <NUM>, the VNF element manager <NUM>, and/or the physical resources <NUM> of the VNF environment <NUM> may include certain hardware components as described herein.

With reference to <FIG>, an exemplary system and/or computing device <NUM> includes a processing unit (CPU or processor) <NUM> and a system bus <NUM> that couples various system components including the system memory <NUM> such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM> to the processor <NUM>. The system <NUM> can include a cache <NUM> of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor <NUM>. The system <NUM> copies data from the memory <NUM>, <NUM>, and/or <NUM> and/or the storage device <NUM> to the cache <NUM> for quick access by the processor <NUM>. In this way, the cache provides a performance boost that avoids processor <NUM> delays while waiting for data. These and other modules can control or be configured to control the processor <NUM> to perform various operations or actions. Other system memory <NUM> may be available for use as well. The memory <NUM> can include multiple different types of memory with different performance characteristics. It can be appreciated that the disclosure may operate on a computing device <NUM> with more than one processor <NUM> or on a group or cluster of computing devices networked together to provide greater processing capability. The processor <NUM> can include any general purpose processor and a hardware module or software module, such as module <NUM><NUM>, module <NUM><NUM>, and module <NUM><NUM> stored in storage device <NUM>, configured to control the processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the processor. The processor <NUM> may be a self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric. The processor <NUM> can include multiple processors, such as a system having multiple, physically separate processors in different sockets, or a system having multiple processor cores on a single physical chip. Similarly, the processor <NUM> can include multiple distributed processors located in multiple separate computing devices, but working together such as via a communications network. Multiple processors or processor cores can share resources such as memory <NUM> or the cache <NUM>, or can operate using independent resources. The processor <NUM> can include one or more of a state machine, an application specific integrated circuit (ASIC), or a programmable gate array (PGA) including a field PGA.

The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output system (BIOS) stored in ROM <NUM> or the like, may provide the basic routine that helps to transfer information between elements within the computing device <NUM>, such as during start-up. The computing device <NUM> further includes storage devices <NUM> or computer-readable storage media such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive, solid-state drive, RAM drive, removable storage devices, a redundant array of inexpensive disks (RAID), hybrid storage device, or the like. The storage device <NUM> is connected to the system bus <NUM> by a drive interface. The drives and the associated computer-readable storage devices provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computing device <NUM>. In one aspect, a hardware module that performs a particular function includes the software component stored in a tangible computer-readable storage device in connection with the necessary hardware components, such as the processor <NUM>, bus <NUM>, an output device such as a display <NUM>, and so forth, to carry out a particular function. In another aspect, the system can use a processor and computer-readable storage device to store instructions which, when executed by the processor, cause the processor to perform operations, a method or other specific actions. The basic components and appropriate variations can be modified depending on the type of device, such as whether the computing device <NUM> is a small, handheld computing device, a desktop computer, or a computer server. When the processor <NUM> executes instructions to perform "operations", the processor <NUM> can perform the operations directly and/or facilitate, direct, or cooperate with another device or component to perform the operations.

Although the exemplary embodiment(s) described herein employs a storage device such as a hard disk <NUM>, other types of computer-readable storage devices which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks (DVDs), cartridges, random access memories (RAMs) <NUM>, read only memory (ROM) <NUM>, a cable containing a bit stream and the like, may also be used in the exemplary operating environment. According to this disclosure, tangible computer-readable storage media, computer-readable storage devices, computer-readable storage media, and computer-readable memory devices, expressly exclude media such as transitory waves, energy, carrier signals, electromagnetic waves, and signals per se.

To enable user interaction with the computing device <NUM>, an input device <NUM> represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device <NUM> can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device <NUM>. The communications interface <NUM> generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic hardware depicted may easily be substituted for improved hardware or firmware arrangements as they are developed.

For clarity of explanation, the illustrative system embodiment is presented as including individual functional blocks including functional blocks labeled as a "processor" or processor <NUM>. The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software and hardware, such as a processor <NUM>, that is purpose-built to operate as an equivalent to software executing on a general purpose processor. For example, the functions of one or more processors presented in <FIG> can be provided by a single shared processor or multiple processors. (Use of the term "processor" should not be construed to refer exclusively to hardware capable of executing software. ) Illustrative embodiments may include microprocessor and/or digital signal processor (DSP) hardware, read-only memory (ROM) <NUM> for storing software performing the operations described below, and random access memory (RAM) <NUM> for storing results. Very large scale integration (VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with a general purpose DSP circuit, may also be provided.

The logical operations of the various embodiments are implemented as: (<NUM>) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (<NUM>) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (<NUM>) interconnected machine modules or program engines within the programmable circuits. The system <NUM> shown in <FIG> can practice all or part of the recited methods, can be a part of the recited systems, and/or can operate according to instructions in the recited tangible computer-readable storage devices. Such logical operations can be implemented as modules configured to control the processor <NUM> to perform particular functions according to the programming of the module. For example, <FIG> illustrates three modules Mod1 <NUM>, Mod2 <NUM> and Mod3 <NUM> which are modules configured to control the processor <NUM>. These modules may be stored on the storage device <NUM> and loaded into RAM <NUM> or memory <NUM> at runtime or may be stored in other computer-readable memory locations.

One or more parts of the example computing device <NUM>, up to and including the entire computing device <NUM>, can be virtualized. For example, a virtual processor can be a software object that executes according to a particular instruction set, even when a physical processor of the same type as the virtual processor is unavailable. A virtualization layer or a virtual "host" can enable virtualized components of one or more different computing devices or device types by translating virtualized operations to actual operations. Ultimately however, virtualized hardware of every type is implemented or executed by some underlying physical hardware. Thus, a virtualization compute layer can operate on top of a physical compute layer. The virtualization compute layer can include one or more of a virtual machine, an overlay network, a hypervisor, virtual switching, and any other virtualization application.

The processor <NUM> can include all types of processors disclosed herein, including a virtual processor. However, when referring to a virtual processor, the processor <NUM> includes the software components associated with executing the virtual processor in a virtualization layer and underlying hardware necessary to execute the virtualization layer. The system <NUM> can include a physical or virtual processor <NUM> that receive instructions stored in a computer-readable storage device, which cause the processor <NUM> to perform certain operations. When referring to a virtual processor <NUM>, the system also includes the underlying physical hardware executing the virtual processor <NUM>.

The various aspects disclosed herein can be implemented as hardware, firmware, and/or software logic embodied in a tangible, i.e., non-transitory, medium that, when executed, is operable to perform the various methods and processes described above. That is, the logic may be embodied as physical arrangements, modules, or components. A tangible medium may be substantially any computer-readable medium that is capable of storing logic or computer program code which may be executed, e.g., by a processor or an overall computing system, to perform methods and functions associated with the examples. Such computer-readable mediums may include, but are not limited to including, physical storage and/or memory devices. Executable logic may include, but is not limited to including, code devices, computer program code, and/or executable computer commands or instructions.

It should be appreciated that a computer-readable medium, computer-readable storage device, or a machine-readable medium excludes signals or signals embodied in carrier waves.

It is believed that the present disclosure and many of its attendant advantages will be understood by the foregoing description, and it will be apparent that various changes may be made in the form, construction, and arrangement of the components without departing from the disclosed subject matter or without sacrificing all of its material advantages.

Claim 1:
A virtual network function, VNF, management system comprising: at least one non-transitory computer readable medium comprising instructions stored thereon that when executed are effective to cause at least one processor to:
deploy (<NUM>) a VNF (<NUM>) using one or more resources (<NUM>) allocated for use by the VNF, the one or more resources being allocated by communicating (<NUM>) with a resource manager (<NUM>) that manages the one or more resources;
receive (<NUM>) a request from a user interface (<NUM>) to un-deploy the VNF;
un-deploy (<NUM>) the VNF while keeping the resources allocated for use by the VNF;
wherein the instructions are further executed to not notify the resource manager that the VNF has been un-deployed;
receive a request to restore the VNF from the user interface; and
deploy (<NUM>) the VNF again using the allocated resources.