Priority based resource management in a network functions virtualization (NFV) environment

A virtual network function (VNF) controller (or module) instantiates two or more VNFs in a communication network to support a network service where the two or more VNFs include at least a first VNF and a second VNF. The VNF controller assigns a priority value to each VNF base on an overall network impact, a physical location of at least one network resource allocated to the respective VNF, a type of service to be implemented by the respective VNF and a customer impact based on how many customers would be using the respective VNF. The VNF controller monitors network resources allocated to each VNF. The VNF controller further determines the first VNF requires additional network resources and releases the network resources allocated to the second VNF based on respective priority values. The VNF controller further allocates the network resources released by the second VNF to the first VNF.

TECHNICAL FIELD

This disclosure relates generally to communications systems, more particularly, to managing resources in a Network Functions Virtualization (NFV) environment.

BACKGROUND

In the telecommunication industry, products were traditionally developed and deployed according to rigorous standards to ensure stability, protocol adherence, quality of service, and the like. However, such rigorous standards led to long product cycles and a reliance on proprietary hardware. Due, in part, to increasing competition from service providers operating over public networks (e.g., the Internet), industry leaders developed and adopted virtual network architectures, such as Network Functions Virtualization (NFV), which virtualize network node functions using software. In operation, these virtual network architectures can employ one or more Virtualized Network Functions (VNFs), which decouple conventional network functions from proprietary hardware and create network structures compatible with commodity hardware (e.g., industry standard servers, switches, storage devices, etc.). In turn, the VNFs reduce a time-to-market for services and reduce capital/operating expenditures. However, certain challenges arise when leveraging these virtual network architectures and/or virtual network functions to achieve or maintain network service objectives (e.g., provide Service Level Agreement (SLA) assurance, perform scaling/healing operations, and the like).

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

According to one or more embodiments of the disclosure, a VNF controller (or module) instantiates two or more VNFs in a communication network to support a network service where the two or more VNFs include at least a first VNF and a second VNF. The VNF controller assigns a priority value to each VNF and monitors network resources allocated to each VNF. The VNF controller further determines the first VNF requires additional network resources (e.g., virtual resources such as network, compute, memory, etc.) and releases the network resources allocated to the second VNF based on respective priority values. The VNF controller further allocates the network resources released by the second VNF to the first VNF.

Description

FIG.1illustrates an example communication environment100illustratively comprising a network105, which can represent an enterprise network, data center network, and the like. Such network105may be accessible by devices communicating over other networks (e.g., the Internet), not shown. It is appreciated that various other types of networks and/or sub-divisions within these networks are often present; however, communication environment100is illustrated and described herein for purposes of discussion and simplicity.

Network105include nodes/devices200(e.g., routers, switches, servers, and the like) interconnected by communication links106. Communication links106may be wired links or shared media (e.g., wireless links, etc.) where certain devices may be in communication with other nodes/devices based on, for example, distance, signal strength, network/node topology, current operational status, location, etc. Data packets140(e.g., traffic and/or messages) may be exchanged among the nodes/devices200in communication environment100using predefined network communication protocols such as certain known wired protocols (e.g., Interior Gateway Protocol (IGP), Exterior Border Gateway Protocol (E-BGP), TCP/IP, etc.), wireless protocols (e.g., IEEE Std. 802.15.4, WiFi, Bluetooth®, etc.), Programmable Logic Controller (PLC) protocols, or other shared-media protocols where appropriate. In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Those skilled in the art will also understand that any number of computing resources, devices, links, etc. may be used in network105, and that the view shown herein is for simplicity.

FIG.2is a schematic block diagram of device200, which may be used with one or more embodiments described herein (e.g., in communication environment100). Device200may comprise one or more network interfaces210, at least one processor220, and a memory240interconnected by a system bus250. Network interface(s)210contain the mechanical, electrical, and signaling circuitry for communicating data over links coupled to one or more of the networks shown in communication environment100. Network interfaces210may be configured to transmit and/or receive data using a variety of different communication protocols, as will be understood by those skilled in the art.

Memory240comprises a plurality of storage locations that are addressable by processor220for storing software programs and data structures associated with the embodiments described herein. Processor220may comprise necessary elements or logic adapted to execute the software programs and manipulate data structures245. An operating system242, portions of which are typically resident in memory240and executed by processor220, functionally organizes the device by, inter alia, invoking operations in support of software processes and/or services executing on the device. These software processes and/or services may comprise an illustrative “VNF priority” process/service244, as described herein. Note that while VNF priority process/service244is shown in centralized memory240, some embodiments provide for these processes/services to be operated in a distributed computing network.

It will be apparent to those skilled in the art that other processor and memory types, including various computer-readable media, may be used to store and execute program instructions pertaining to the techniques described herein. For example, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with VNF priority process244, which may contain computer executable instructions executed by the processor220to perform functions relating to the techniques described herein. Also, while this disclosure describes various processes, it is expressly contemplated such processes may be embodied as modules configured to operate in accordance with the techniques herein (e.g., according to the functionality of a similar process). Further, while the processes have been shown separately, those skilled in the art will appreciate that processes may be routines or modules within other processes. For example, processor220can include one or more programmable processors, e.g., microprocessors or microcontrollers, or fixed-logic processors. In the case of a programmable processor, any associated memory, e.g., memory240, may be any type of tangible processor readable memory, e.g., random access, read-only, etc., that is encoded with or stores instructions that can implement program modules. Processor220can also include a fixed-logic processing device, such as an application specific integrated circuit (ASIC) or a digital signal processor that is configured with firmware comprised of instructions or logic that can cause the processor to perform the functions described herein. Thus, program modules may be encoded in one or more tangible computer readable storage media for execution, such as with fixed logic or programmable logic, e.g., software/computer instructions executed by a processor, and any processor may be a programmable processor, programmable digital logic, e.g., field programmable gate array, or an ASIC that comprises fixed digital logic, or a combination thereof. In general, any process logic may be embodied in a processor or computer readable medium that is encoded with instructions for execution by the processor that, when executed by the processor, are operable to cause the processor to perform the functions described herein.

As discussed above, industry leaders developed virtual network architectures, which include an example NFV Management And Organization (MANO) model, adopted by the European Telecommunication Standards Institute Industry Specification Group (ETSI-ISG).

FIG.3particularly illustrates a NFV MANO model302. NFV MANO302provides a framework for managing and orchestrating resources in a data center network305. NFV MANO302facilitates deploying and connecting services as they are decoupled from dedicated physical devices and moved to virtual machines (VMs). NFV MANO302includes a number of network elements, however, for purposes of simplicity and discussion herein, we focus on three functional blocks—i.e., an NFV Orchestrator (NFV-O)310, a VNF Manager (VNFM)315, and a Virtualized Infrastructure Manager (VIM)320—which deploy and connect functions and services throughout data center network305.

NFV-O310particularly supports and manages on-boarding, resources and policies, and integrate new network services and VNFs into a virtual framework. NFV-O310also validates and authorizes NFV Infrastructure (NFVI) resource requests (not shown).

VNFM315operates in conjunction with NFV-O310and VIM320and generally provides lifecycle management for VNFs as well as supports interoperability of software-defined network elements. For example, VNFM315can instantiate one or more new VNFs, scales VNFs, update and/or upgrade VNFs, and also terminate VNFs. In addition, VNFM315monitors key performance indicators (KPIs) during VNF lifecycles, which are important when performing scaling operations, healing operations, and the like. In this fashion, VNFM315maintains virtualized resources and supports VNF functionality.

VIM320controls and manages the NFV infrastructure, including network resources such as compute, storage, network, and the like. VIM320is flexible and may be configured to handle a certain type of NFVI resource (e.g. compute-only, storage-only, networking-only), and/or it may be capable of managing multiple types of NFVI resources (e.g. in NFVI nodes). In operation, VIM320orchestrates allocation, upgrades, releases, and reclaims of NFVI resources, manages associations between virtual and physical elements, and maintains an inventory of allocated virtual/physical resources.

While NFV MANO302virtualizes network components, certain challenges arise in the context of performing healing, scaling, and similar operations. For example, many service providers employ a number of Virtualized Network Functions (VNFs) (e.g., virtual machines executing software/processes), which are managed by a single infrastructure manager (e.g., VIM320) in order to achieve network service objectives (E.g., Service Level Agreement (SLA) requirements (e.g., redundancy, scaling, differing service requirements for certain services, etc.)). In some situations, issues may arise from dynamic and changing network environments/conditions such as power failures, server failures, storage failures, resource bottlenecks and/or changes to network resource availability (e.g., due to sudden spikes in service usage), changes in customer requirements/services, and the like. In such situations, some network resources allocated to a particular VNF may go unused (e.g., virtual resources such as compute, storage/memory, network, etc.). In addition, network resource allocation between VNFs (e.g., between different services) may cause a disproportionate subscriber/service impact (e.g., a resource failure for a gateway service VNF may impact a large number of subscribers and bring down basic connectivity as compared to a premium service VNF used by a small number of subscribers). Accordingly, the techniques disclosed herein address the dynamic and changing network conditions by prioritizing and orchestrating VNF operations (e.g., deployment, recovery, etc.) in a hosted environment. Indeed, the techniques disclosed herein establish a priority framework that ensures critical VNFs are running in the event of a failure, re-distributes resources between VNFs to maintain certain SLA objectives, and provides a flexible and scalable framework for implementing VNFs.

FIG.4illustrates a communication network (e.g., a data center network405), which employs VNF prioritization techniques according to one exemplary embodiment of this disclosure. As shown, data center network405includes an NFV Orchestrator (VNF-O)410, a VNF Manager (VNFM)420, and a Virtualized Infrastructure Manager (VIM)420.

VNF-O410supports and manages VNFs, including the illustrated “VNF-1” and “VNF-2”. Here, VNF-O410communicates with VNF Element Managers (VNF-EM(s))425and430, which comprise allocated network resources (e.g., virtual machines (VMs)). VNFM415operates in conjunction with VNF-O410and VIM420and provides lifecycle management for VNFs as well as supports interoperability of software-defined network elements. For example, VNFM315instantiates VNFs, terminates VNFs, and maintains virtualized resources for VNFs. VIM320controls and manages the NFV Infrastructure (NFVI), including compute, storage, and network resources. VIM320is flexible and may be configured to handle different types of NFVI resource (e.g. compute-only, storage-only, networking-only), and/or it may be capable of managing multiple types of NFVI resources (e.g. in NFVI nodes). VIM420also orchestrates allocation, upgrades, releases, and reclaims of NFVI resources, manages associations between virtual and physical elements, and maintains an inventory of allocated virtual/physical resources.

In operation, the VNF prioritization techniques generally provide a mechanism to evaluate and redistribute resources for a network service across multiple VNFs. Accordingly, the VNF prioritization techniques are typically employed by a VNF controller or a network manager/orchestrator component such as the illustrated VNF-O410, VNFM415, VIM420, a combination of these components, and/or functionality similar components. Accordingly, while certain VNF prioritization operations are discussed and described with respect to a specific component, it is appreciated such operations may be performed by a single component or module such as a VNF controller (e.g., a module that can emulate operations of VNF-O410, VNFM415, and/or VIM420).

For example, the VNF controller operatively instantiates VNFs to support a network service, assigns priority values to each VNF, monitors the network resources allocated to each VNF. The VNF controller further determines one of the VNFs requires additional network resources (e.g., in response to a network condition such as a component failure, scaling operations, changes to network resource availability, etc.) and releases the network resources allocated to another, lower priority VNF. Further, the VNF controller instructs or otherwise allocates the released network resources to the VNF that requires additional network resources.

As one non-limiting example, and referring again toFIG.4, VNF-1requires additional network resources (e.g., a Virtual Machine (VM)) (e.g., due to a change in the data center network, a power failure, scaling operations, updated Service Level Agreement (SLA), etc.). In this example, VNF-O410, VNFM415, and VIM420cooperate to evaluate priority values assigned to multiple VNFs (i.e., VNF-1and VNF-2), determine VNF-1has a higher priority over VNF-2(priority value 1 being more important than a priority value 2), release network resources from VNF-2to VIM420, and allocate the released resources to VNF-1.

Details regarding signal flows and component-specific communications for the foregoing VNF prioritization operations are illustrated in a signal flow diagram500illustrated byFIG.5.

Signal flow diagram500begins with a signal505from VNF-EM425to VNFM415. Signal505indicates a request for additional resources for a new VNF/VM. For example, VNF-EM425may require additional resources due to a network resource failure (e.g., power failure, component failure, etc.).

VNFM415receives the request and sends a request message510to VIM420for resource allocation. VIM420determines its resource availability at signal515and, at signal520, indicates no resources are available. VNFM415indicates this lack of resources to VNF-EM425at signal525, which causes VNF-EM425to send an “out-of-resources” signal530to VNF-O410. VNF-O410evaluates, at signal535, a priority amongst VNFs—here, amongst VNF-1and VNF-2- and instructs, at signal540, VNF-EM430(which is responsible for VNF-2) to release one of its VMs. As discussed above, VNF-2is assigned a lower priority value (a priority value 2) than VNF-1(a priority value 1). With respect to priority values, VNF-O410, VNF-EM425, and/or VNF-EM430can assign respective VNFs—here, VNF-1and VNF-2—a priority value based on a customer impact (e.g., one VNF may serve a larger/smaller number of customers), a type of service (basic service, premium service, etc.), a load of the service, overall network impact, and/or a physical location for network resources allocated to each VNF.

After receiving the request to release resources, VNF-EM430sends a request, at signal545, to scale down or release resources to VNFM415, which further communicates with VIM420to facilitate the resource release. In particular, VNFM415requests the resource release at signal550, VIM420releases the resources, shown by signal555, and notifies VNFM415the resources are released at signal560. In addition, VNF-O410instructs VNF-EM425to request an allocation of resources at signal561. In response, VNF-EM425requests a scale up (e.g., resource allocation of the now-released resources) from VNFM415at signal562. VNFM415sends a resource request at signal565to VIM420and VIM420allocates the resources at signal566and further indicates, to VNFM, the resources are allocated at signal570. VNFM415further grants the resources to VNF-EM430at signal571.

As discussed above, signaling diagram500illustrates operations performed by specific components to assign and evaluate priority(ies), release resources, and allocate released resources, however, it is appreciated such operations may also be performed by one or more components or modules. For example, it is specifically contemplated certain operations performed by VNFM415, VNF-O410, VNF-EM425, and/or VNF-EM430may be combined into a single Virtual Network Functions (VNF) controller or module, as is appreciated by those skilled in the art.

In addition, while signaling diagram500illustrates VNF prioritization operations to manage resources based on a static priority value (e.g., VNF-1(associated with VNF-EM430) has a priority value of 1 while VNF-2(associated with VNF-EM425) has a priority value of 2), it is also appreciated this VNF prioritization scheme may be applied (or extended) in a more granular fashion. That is, it is appreciated in some embodiments that multiple VNFs may be assigned or associated with a same priority value. In such embodiments, the above-discussed VNF prioritization operations may include dynamic decision processes based on a policy at “run” time (e.g., decide to kill one VNF based on a current service impact. For example, a PGW service can manage10M subs for each. In this example, one sub is failing, which can trigger a dynamic decision based on a dynamic runtime policy. Here, one VNF may have 8 M subs active while another VNF has 1 M subs. Accordingly, the VNF with 1 M subs may be killed to minimize the service impact on the VNF having 8 M subs.

FIG.6illustrates another communication network605, showing a VNF controller612(or module) that performs VNF-O and VNFM operations. In particular, VNF controller612is configured to perform the above-discussed operations of VNF-O410and VNFM415. In addition, VNF-1and VNF-2are represented with different component resources or functional blocks, including a control function and a service function (VNF-1) as well as a firewall, deep packet inspection, and VOM (VNF-2). Notably, while the above-discussed operations generally include resource distribution amongst multiple VNFs, it should be noted VNF controller612can re-distribute network resources after a network condition is resolved (e.g., power is returned, a network resource is replaced after failure, and the like).

FIG.7an example simplified procedure700for managing resources in a communication network based on a VNF priority, particularly from the perspective of a VNF controller (or module) (e.g., VNF controller612).

Procedure700begins at step705and continues on to step710where, as discussed above, the VNF controller instantiates two or more VNFs in a communication network (e.g., a datacenter network) to support a network service.

The VNF controller further determines, in step715, a priority value for each VNF based on, for example, a customer impact, a type of service (basic service, premium service, etc.), a load of the service, a physical location of the network resources, and the like. Alternatively, or in addition, the priority value may be established according to a Service Level Agreement (SLA) policy. The VNF controller assigns the priority value to each VNF in step720and monitors the network resources allocated to each VNF in step725.

In step730, the VNF controller determines one—e.g., a “first”—VNF requires additional network resources. For example, as discussed above, the first VNF may request additional network resources due to a shortage of network resources (e.g., power failure, scaling operations, healing operations, updated SLA(s), and the like). The VNF controller further evaluates, in step735, the priority assigned to each VNF to determine the priority value assigned to the second VNF is lower than the priority value assigned to the first VNF.

The VNF controller also releases, in step740, one or more network resources allocated to the second VNF based on its priority value. In operation, the VNF controller instructs the second VNF (e.g., an element manager for the second VNF) to release the one or more network resources. The VNF controller further allocates, in step745, the one or more network resources released by the second VNF to the first VNF. For example, the VNF controller may coordinate with and/or instruct a Virtualized Infrastructure Manager (VIM) (e.g., VIM420) to allocate the one or more network resources.

Procedure700subsequently ends in step750, but may continue on to step710where, as discussed above, the VNF controller instantiates VNFs in a communication network to support a network service. It should be noted that certain steps within procedure700may be optional, and further, the steps shown inFIG.7are merely examples for illustration—certain other steps may be included or excluded as desired. Further, while a particular order of the steps is shown, this ordering is merely illustrative, and any suitable arrangement of the steps may be utilized without departing from the scope of the embodiments herein. In addition, although procedure700is described with respect to a VNF controller, certain operations may be executed in cooperation with other devices or modules, as discussed above.

The techniques herein provide a Virtual Network Functions priority techniques to distribute network resources amongst multiple VNFs in response to changes to network conditions (e.g., network resource failure, healing operations, scaling operations, and the like). These techniques allows a customer to define SLA policies and organize/prioritize VNFs and enforce such SLA policies in a given priority order at a VNF level. The techniques are flexible and can employ automatic mechanisms to quickly and efficiently redistribute network resources in order to maintain important services during adverse network conditions. For example, during any failure, resource crunch (threshold crossing) or scaling, a VNF controller (e.g., a service orchestrator) evaluates VNF priority while making healing/scaling decisions across VNFs. In this fashion, service providers can align the available resources to minimize overall impact.

While there have been shown and described illustrative embodiments and processes executed by a VNF controller/module, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, the embodiments have been shown and described herein with relation to one VNF controller; however, the embodiments in their broader sense are not as limited, and may, in fact, be used with any number of controllers organized in a distributed computing network.

The foregoing description has been directed to specific embodiments. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. For instance, it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium, devices, and memories (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof. Further, methods describing the various functions and techniques described herein can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on. In addition, devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example. Instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the embodiments herein. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the embodiments herein.