WO2017019018A1

WO2017019018A1 - Virtualized network function autoscaling based on lightweight threshold crossing notifications

Info

Publication number: WO2017019018A1
Application number: PCT/US2015/042271
Authority: WO
Inventors: Anatoly ANDRIANOV; Gyula Bodog
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2015-07-27
Filing date: 2015-07-27
Publication date: 2017-02-02

Abstract

Various communication systems may benefit from appropriate scaling. For example, certain virtualized network function autoscaling may benefit from suitable use of lightweight threshold crossing notifications. A method may include receiving at least one performance management counter. The method may also include determining if at least one predefmed threshold of the at least one performance management counter has been crossed. The method further include, when it is determined that the threshold has been crossed, reporting the threshold crossing to a virtualized network function manager. The notification of the at least one predefmed threshold to the virtualized network function manager can be configured to avoid providing application details of a corresponding application to the virtualized network function manager.

Description

Virtualized Network Function Autoscaling Based On Lightweight Threshold

Crossing Notifications

BACKGROUND:

Field:

[0001] Various communication systems may benefit from appropriate scaling. For example, certain virtualized network function autoscaling may benefit from suitable use of lightweight threshold crossing notifications.

Description of the Related Art:

[0002] Network Functions Virtualization (NFV) can refer to an approach that adds new capabilities to communications networks and may require a new set of management and orchestration functions to be added to the current model of operations, administration, maintenance and provisioning. In legacy networks, Network Function (NF) implementations are often tightly coupled with the infrastructure on which such legacy implementations run. NFV can decouple software implementations of Network Functions from the computation, storage, and networking resources they use. The virtualization can insulate the Network Functions from those resources through a virtualization layer.

[0003] The virtualization principle cab stimulate a multi-vendor ecosystem in which the different components of network function virtualization infrastructure (NFVI), virtualized network function (VNF) software, and NFV management and orchestration (NFV-MANO) architectural framework entities can follow different lifecycles, for example on procurement, upgrading, and so on. This flexibility may require interoperable standardized interfaces and proper resource abstraction among them.

[0004] Management and orchestration aspects of a VNF include traditional Fault Management, Configuration Management, Accounting Management, Performance Management, and Security Management (FCAPS), but the focus in European Telecommunications Standards Institute (ETSI) NFV is on the newer aspect introduced by NFV. The decoupling of network functions from the physical infrastructure that those functions use, can result in a new set of management functions focused on the creation and lifecycle management of the needed virtualized resources for the VNF, which can be collectively referred to as VNF management.

[0005] VNF management functions can be responsible for the VNF's lifecycle management including operations such as the following: instantiating VNF, including creating a VNF using the VNF on-boarding artefacts; scaling VNF, including increase in or reduction to the capacity of the VNF; updating and/or upgrading VNF, including support of VNF software and/or configuration changes of various complexity; and terminating VNF, including release of VNF-associated NFVI resources and return it to NFVI resource pool.

[0006] The deployment and operational behavior requirements of each VNF can be captured in a deployment template, and stored during the VNF on- boarding process in a catalogue, for future use. The deployment template describes the attributes and requirements necessary to realize such a VNF and captures, in an abstracted manner, the requirements to manage its lifecycle.

[0007] In ETSI NFV architecture the Virtualized Network Function (VNF) Lifecycle Management (LCM) operations such as scaling performed by the VNFM, including the scale -up, scale-down, scale-in and scale-out either at the VNF or VNFC level, may be triggered externally, for example by an element manager (EM) or NFV orchestrator (NFVO), or internally within the VNFM itself. The latter cases where scaling operations are triggered within the VNFM are also known as autoscaling.

[0008] Autoscaling decisions may be based on the values of monitoring parameters such as Virtualized Resources (VR) consumption. For example, VNFM may keep track of the VR performance measurements (PM) and when particular measurement reaches particular level or a combination of measurements reaches set of predefined values, VNFM may decide that a scaling is needed and trigger the corresponding LCM operation. However, making scaling decisions based only on the V consumption may be sub- optimal, and even wrong in some cases, because such an approach ignores the application behavior of the VNF.

SUMMARY:

[0009] According to certain embodiments, a method can include receiving at least one performance management counter. The method can also include determining if at least one predefined threshold of the at least one performance management counter has been crossed. The method can further include, when it is determined that the threshold has been crossed, reporting the threshold crossing to a virtualized network function manager. The notification of the at least one predefined threshold to the virtualized network function manager can be configured to avoid providing application details of a corresponding application to the virtualized network function manager.

[0010] In certain embodiments, a method can include receiving a notification that a threshold crossing has occurred with respect to at least one predefined threshold of at least one management counter. The method can also include checking a virtualized network function descriptor to determine a lifecycle management action based on the notification. The method can further include performing the lifecycle management action responsive to the threshold crossing.

[0011] A method, according to certain embodiments, can include identifying, for at least one performance measurement or composite key performance indicator, at least one threshold. The threshold can be configured to reflect a change in application behavior. The method can also include instructing a network element to monitor the at least one performance measurement or composite key performance indicator using the threshold.

[0012] An apparatus, in certain embodiments, can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to perform any of the preceding methods.

[0013] According to certain embodiments, a non-transitory computer- readable medium can be encoded with instructions that, when executed in hardware, perform a method. The method can be any of the preceding methods.

[0014] In certain embodiments, a computer program product can be encoded with instructions for performing a process. The process can be any of the preceding methods.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0015] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

[0016] Figure 1 illustrates a sequence diagram showing the VR PM data flow and application PM data flow between elements, according to certain embodiments.

[0017] Figure 2 illustrates a method that may be performed by an element manager, according to certain embodiments.

[0018] Figure 3 illustrates a method that may be performed by a VNFM, according to certain embodiments.

[0019] Figure 4 illustrates a system according to certain embodiments. DETAILED DESCRIPTION:

[0020] Certain embodiments are applicable to ETSI NFV defined MANO architecture. More particularly, in certain embodiments application specific behavior can be hinted to the VNFM to be used in autoscaling decisions, but without increasing the VNFM complexity and without exposing too much proprietary knowledge of VNF application details to the VNFM.

[0021] Certain embodiments may provide the VNFM with application level knowledge to select the appropriate PMs and set the appropriate thresholds for notifications to be generated. Certain embodiments may provide these and/or other benefits based on lightweight threshold notifications.

[0022] For example, certain embodiments provide a method for VNF autoscaling decisions based on the lightweight threshold crossing notifications. More particularly, certain embodiments expose just enough information about the performance state of a VNF application to support the autoscaling decisions at the VNFM without requiring any knowledge about VNF application behavior, application performance profile or VNF application internal architecture.

[0023] The autoscaling decisions at the VNFM are supported by two streams of data. A first stream can include detailed information about V consumption, such as VR PMs. This stream may, for example, be provided by the Virtualized Infrastructure Manager (VIM) as described in the ETSI NFV IFA006 and IF AO 10 specifications.

[0024] The second stream may be notifications about VNF application state, such as lightweight threshold crossing notifications. These notifications may be provided by the EM or, in certain cases, by the VNF itself. Furthermore, in certain embodiments, notification providing by the VNF may be independent of EM deployment.

[0025] The VR consumption may be considered a continuous stream of data, although in practice this stream may be implemented in the form of periodic PM jobs. The VNFM may monitor the resource consumption on a single dimensional graph or a multi-dimensional surface. The VNFM can make scaling decisions when VR utilization/consumption reaches a pre-defined region. VNFM may decide the most appropriate VR PMs based on machine learning algorithms or based on a specification provided by the VNF vendor. In either of these cases, VNFM may select the desired VR PMs, create the corresponding PM jobs on the VIM(s) controlling the relevant NFVI, and monitor the PM data. [0026] The application level lightweight threshold crossing can be under full control of the VNF provider. The VNF provider can select an existing application level PM or can create a composite application level key performance indicator (KPI). This selection and/or creation can be based on the VNF provider's proprietary knowledge of the VNF application behavior and architecture.

[0027] Also, the VNF provider may select the important, from the provider's perspective, values of these PMs/KPIs. The decision of which are important may be based for example, on the application behavior, such as that observed in other deployments or lab environment. The decision may likewise be based on a proprietary VNF application performance profile.

[0028] For example, the selected application level PM/KPI may indicate the VNF application load level and selected values may represent green, yellow, and red areas of a performance gauge. The transitions from green to yellow and from yellow to red can happen when the selected application PM/KPI crosses the pre-defined threshold(s).

[0029] The semantics of selected PMs/KPIs, the number of pre-defined thresholds and their specific values can be proprietary and can be maintained secretly by the VNF provider. In certain embodiments, there may be only one threshold per PM/KPI and two states, such as active/inactive, crossed/not crossed, or true/false. VNFM is not required to know the thresholds and their values. Thus the VNFM can avoid the burden of application level knowledge or application awareness.

[0030] VNF can expose a lightweight notifications interface allowing VNFM to know the state of each of these anonymous application level indicators and be notified whenever the state of a particular indicator changes. These notifications of changes can be referred to as lightweight threshold crossing notifications.

[0031] The notifications can be considered anonymous if, for example, they conceal the basis for the notifications, such as if the actual semantics are unknown to the VNFM. Examples of such anonymous notifications include, for example, the following: indicator A, state green; indicator B, state green; indicator C, state yellow; or indicator D, state true.

[0032] The VNF provider may specify the desired VNFM LCM operation behavior based on the combination of exposed indicators and their states. For example, the VNF provider may specify that a particular behavior is to occur upon some anonymous condition being met. An example of this behavior being specified through anonymous conditions being met can be, for example, when an indicator A is set to "true" and indicator B is set to "red", the VNF component XYZ can be specified to be scaled-up. This is simply one example of such condition setting, and should not be taken as limiting.

[0033] The set of the indicators and their values mapped to the desired LCM operations may be part of the VNF package metadata and may, for example, be contained in a virtualized network function descriptor (VNFD). The combination of the anonymous indicators with lightweight threshold crossing notifications and the map describing the desired LCM operations behavior may permit VNFM to make autoscaling decisions while maintaining certain level of flexibility based on monitored VR PMs. Moreover, such autoscaling decisions may be optimal from the application perspective.

[0034] There may be various use cases for certain embodiments. For example, a first use case may be simple VNFM autoscaling. In this case, VNFM may not need any sophisticated monitoring of VR PMs and may base all autoscaling decisions only on the lightweight threshold notifications as specified by the VNF provider in the VNF metadata. The autoscaling decisions may be sub-optimal from the VR utilization perspective, but they ensure optimal VNF application performance, for example avoiding overloaded conditions. [0035] A second use case may be sophisticated VNFM autoscaling. In this case, VNFM can take into account the lightweight threshold crossing notifications, ensuring that application performance remains unaffected. Additionally, the VNFM can keep track of the actual V PMs, identifying opportunities for optimal VR utilization.

[0036] Implementation of various embodiments can include various parts. For example, according to a first implementation part a VNF provider can identify important application PMs or composite KPIs. This identification can be based on the knowledge the VNF provider has of application performance profile and internal architecture. For each of the selected PMs/KPIs, the VNF provider can identify the significant thresholds. For example, the VNF provider can identify at least one threshold per PM/KPI. Crossing these thresholds can indicate significant changes in application behavior, for example, particular VNF component performance state. The semantics of selected PMs/KPIs and the actual values of the identified thresholds do not need to be disclosed by the VNF provider.

[0037] According to a second implementation part, the VNF provider can create a map of desired LCM operations with indicators and their states, such as selected PMs/KPIs and threshold crossed/not crossed. The VNF provider can document this map in VNF metadata, for example, in VNFD. The mapping to desired LCM operations is optional. The VNF provider may decide to just indicate the important thresholds from VNF application behavior perspective and leave the actual LCM operation decisions to the VNFM. The number of specified indicators, the number of states per indicator and level of detail in desired LCM operation mapping may depend on the complexity of VNF and provider's knowledge of an application performance profile.

[0038] According to a third implementation part, both the VNF provider and the VNFM vendor can implement an interface for the VNF to inform VNFM about current states of indicators and notify the VNFM whenever these states change. The states can be considered changed when any of the thresholds are crossed in either direction.

[0039] According to a fourth implementation part, the VNFM vendor can implement the autoscaling decision logic of the VFNM based on the application performance indicators and their states. Certain embodiments may simply follow the map of indicator states to the desired LCM operations as specified by the VNF provider. More complex implementations may consider the V PMs and try to achieve optimal VR utilization while still satisfying the VNF provider's specifications. In practice, such implementation may be considered a switch between different VR PM surfaces based on the combination of application performance indicator values or a policy (policy-like) rule-set of indicator values vs. LCM operations with or without consideration of VR PMs.

[0040] Figure 1 illustrates a sequence diagram showing the VR PM data flow and application PM data flow between elements, according to certain embodiments. As shown in Figure 1, an EM can create an application PM job with the VNF, which can result in the VNF providing application PM counter collection and periodic or aperiodic reporting of the result of such collection. The EM can determine whether a threshold has been crossed and can report such threshold crossing to a VNFM, such as a notification of PM counter A crossing a threshold. Meanwhile, the VNFM can create a VR PM job with a VIM, yielding collection and periodic or aperiodic reporting of the VR PM to the VNFM.

[0041] Upon notification of the threshold crossing, the VNFM can check VNFD to determine what LCM operation is mapped to a threshold crossing of this kind for counter A. The VNFM can do the mapped operation according to the VNFD.

[0042] Figure 2 illustrates a method that may be performed by an element manager, according to certain embodiments. As shown in Figure 2, at 210 an EM can create an application PM job. At 220, the application PM counters can be reported by a VNF to the EM. At 230, the EM can check whether any predefined PM counter's threshold has been crossed. If not, monitoring of the counters reported by VNF can continue. If a threshold has been crossed, then at 240 the EM can send a threshold crossing notification to a VNFM.

[0043] Figure 3 illustrates a method that may be performed by a VNFM, according to certain embodiments. As shown in Figure 3, a method can include, at 310, the VNFM creating a V PM job. At 320, the VR PM counters can be reported to the VNFM. The VNFM can, at 330, correlate the VR PM to one or more VNF/VNFC instance(s).

[0044] At 340, the VNFM can determine whether a threshold crossing notification has been received. If not, the VNFM can continue to correlate VR PM counters to VNF/VNFC instance(s).

[0045] Upon determining that such a notification has been received, at 350 the VNFM can check VNFD for a required LCM action. If there is no required action, then the VNFM can simply do nothing. Otherwise, the VNFM can execute the required LCM action as defined in VNFD, at 360.

[0046] Figure 4 illustrates a system according to certain embodiments of the invention. In one embodiment, a system may include multiple devices, such as, for example, at least one EM 410, at least one VNFM 420, and at least one network element 430, which may be any virtualized function or other device.

[0047] Each of these devices may include at least one processor, respectively indicated as 414, 424, and 434. At least one memory can be provided in each device, and indicated as 415, 425, and 435, respectively. The memory may include computer program instructions or computer code contained therein. The processors 414, 424, and 434 and memories 415, 425, and 435, or a subset thereof, can be configured to provide means corresponding to the various blocks of Figures 2 and 3.

[0048] As shown in Figure 4, transceivers 416, 426, and 436 can be provided, and each device may also include an antenna, respectively illustrated as 417, 427, and 437. Other configurations of these devices, for example, may be provided. For example, network element 430 may be configured for wired communication, in addition to wireless communication, and in such a case antenna 437 can illustrate any form of communication hardware, without requiring a conventional antenna.

[0049] Transceivers 416, 426, and 436 can each, independently, be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that is configured both for transmission and reception.

[0050] Processors 414, 424, and 434 can be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors can be implemented as a single controller, or a plurality of controllers or processors.

[0051] Memories 415, 425, and 435 can independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory can be used. The memories can be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory and which may be processed by the processors can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.

[0052] The memory and the computer program instructions can be configured, with the processor for the particular device, to cause a hardware apparatus such as EM 410, VNFM 420, and network element 430, to perform any of the processes described herein (see, for example, Figures 2 and 3). Therefore, in certain embodiments, a non-transitory computer-readable medium can be encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, certain embodiments of the invention can be performed entirely in hardware.

[0053] Furthermore, although Figure 4 illustrates a system including a EM, VNFM, and network element, embodiments of the invention may be applicable to other configurations, and configurations involving additional elements.

[0054] Certain embodiments can have various benefits and/or advantages. For example, certain embodiments can address the issue of LCM triggering at the generic VNFM enabling it with necessary application level knowledge supporting the LCM decisions. At the same time, certain embodiments can provide an appropriate level of separation between the application management and virtualization aspects management.

[0055] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

List of Abbreviations

VNF - Virtualized Network Function

PM - Performance Management / Performance Measurements

VNFM - VNF Manager

EM - Element Manager

V - virtualized resources

NFVI - Network Functions Virtualization Infrastructure

VIM - Virtualized Infrastructure Manager

LCM - Lifecycle Management KPI - Key Performance Indicator

NFV - Network Function Virtualization

MANO - Management and Orchestration

VNFD - Virtualized Network Function Descriptor NF - Network Function

Claims

WE CLAIM:

1. A method, comprising:

receiving at least one performance management counter;

determining if at least one predefined threshold of the at least one performance management counter has been crossed; and

when it is determined that the threshold has been crossed, reporting the threshold crossing to a virtualized network function manager,

wherein notification of the at least one predefined threshold to the virtualized network function manager is configured to avoid providing application details of a corresponding application to the virtualized network function manager.

2. The method of claim 1, wherein the method is performed by an element manager.

3. The method of claim 1 or claim 2, further comprising:

creating an application performance management job, wherein the at least one performance management counter is received in response to the created application performance management job.

4. The method of any of claims 1-3, wherein the at least one performance management counter is received from a virtualized network function.

5. The method of any of claims 1-4, wherein reporting the threshold crossing comprises providing a threshold notification that is in independent from the at least one performance management counter.

6. A method, comprising:

receiving a notification that a threshold crossing has occurred with respect to at least one predefined threshold of at least one management counter;

checking a virtualized network function descriptor to determine a lifecycle management action based on the notification; and

performing the lifecycle management action responsive to the threshold crossing.

7. The method of claim 6, wherein the method is performed by a virtualized network function manager.

8. The method of claim 6 or claim 7, further comprising:

receiving at least one further performance management counter; and correlating the at least one further performance management counter to one or more virtualized network controller instance.

9. The method of claim 8, further comprising:

creating a virtualized resource job, wherein the at least one further performance management counter is received in response to the created virtualized resource job.

10. The method of any of claims 6-9, wherein the lifecycle management action is performed based on the virtualized network function descriptor and based on a virtualized resource performance management counter.

1 1. The method of claim 9 or claim 10, further comprising:

performing a scaling decision when virtualized resource utilization reaches a predefined region of a single dimensional or multi-dimensional surface.

12. A method, comprising:

identifying, for at least one performance measurement or composite key performance indicator, at least one threshold, wherein the threshold is configured to reflect a change in application behavior; and

instructing a network element to monitor the at least one performance measurement or composite key performance indicator using the threshold.

13. An apparatus, comprising:

means for performing the methods of any of claims 1-12.

14. An apparatus, comprising:

at least one processor, and

at least one memory including computer program code,

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the method according to any of claims 1-12.

15. A non- transitory computer-readable medium encoded with instructions that, when executed in hardware, perform the method according to any of claims 1-12.

16. A computer program product encoded with instructions for performing a process, the process comprising the method according to any of claims 1-12.