WO2017008839A1

WO2017008839A1 - Managing resource allocation in a network functions virtualisation infrastructure

Info

Publication number: WO2017008839A1
Application number: PCT/EP2015/066001
Authority: WO
Inventors: Massimo Iovene; Oliver Speks; Francesco Mariniello
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-07-13
Filing date: 2015-07-13
Publication date: 2017-01-19

Abstract

A method (100), performed in a Network Functions Virtualisation Management and Operations (NFV M&O) element, for managing allocation of resources in a Network Functions Virtualisation Infrastructure (NFVI) is disclosed. The method comprises establishing a planned resource allocation adjustment (102) and identifying a Virtualised Network Function Manager (VNFM) managing at least one Virtualised Network Function (VNF) which will be affected by the planned resource allocation adjustment (104). The method also comprises requesting permission from the identified VNFM to perform the planned resource allocation adjustment (106), and implementing the planned resource allocation adjustment if the requested permission is received (124). Also disclosed is a method (300), performed in a VNFM, for managing a VNF that consumes resources in a NFVI, which resources are allocated to the VNF. The method comprises receiving, from a NFV M&O element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM (302), checking an operational status of the VNF (304), and responding to the request on the basis of the operational status of the VNF (318). In the event that responding to the request comprises granting the requested permission, the method may further comprise triggering preparatory actions in the VNF to mitigate the impact of the planned resource allocation adjustment, and may also comprise triggering clean up actions at the VNF after the resource allocation adjustment has been completed. Also disclosed are a NFV M&O element (500, 700), a VNFM (600, 800) and a computer program product configured to carry out methods for managing allocation of resources in a NFVI and for managing a VNF consuming resources in a NFVI.

Description

Managing resource allocation in a Network Functions Virtualisation

Infrastructure

Technical Field

The present invention relates to a method for managing resource allocation in a Network Functions Virtualisation Infrastructure (NFVI), and to a method for managing a Virtualised network Function, VNF, that consumes resources in a NFVI. The present invention also relates to a computer program product configured, when run on a computer, to carry out methods for managing resource allocation in a NFVI and for managing a VNF that consumes resources in a NFVI.

Background Conventional system architectures require all applications to execute their software on dedicated, vendor specific hardware platforms. This native deployment model is now gradually being replaced with a Network Functions Virtualisation (NFV) model. NFV makes use of standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage. This uniform and scalable hardware may be located in Data Centres, Network Nodes and/or in end user premises. A virtualised deployment model offers numerous advantages over a native deployment model, including reduction of operational and capital expense (OPEX and CAPEX). No longer being locked in to application specific hardware, telecoms operators are able to use commercial off-the-shelf (COTS) hardware and make economies of scale. In addition, owing to the significant reduction in the variety infrastructure equipment, management activities are simplified, no longer requiring specialist operators for multiple different platforms. Reduction of Time to Market (TTM) is another significant advantage offered by a virtualised deployment model. Installation of new hardware equipment is very time consuming, involving a variety of different parties within the operator domain, the regulatory domain and the supplier domain. This delay imposed by the installation of new hardware can impede the fast reaction to market needs that is desirable for business success. In addition, market success of new features and solutions is highly unpredictable and it is therefore difficult to deploy the right processing, networking and storage capacity for individual network functions at the right time. Virtualisation allows for the fast reallocation of processing, networking and storage capacity to those network functions that need it. A Network Functions Virtualisation Industry Specification Group (NFV ISG) has been created under the auspices of the European Telecommunications Standards Institute (ETSI) to create a framework and define architecture and interfaces for NFV. Two of the principle standardisation documents produced by the NFV ISG are: "Network Functions Virtualisation (NFV); Architectural Framework", ETSI GS NFV 002 V1.2.1 (2014-12) and "Network Functions Virtualisation (NFV); Management and Orchestration", ETSI GS NFV- MAN 001 V1.1 .1 (2014-12), elements of which are introduced below.

In non-virtualised deployments, Network Functions (NFs) are implemented as a combination of vendor specific software and hardware, often referred to as network nodes or network elements. NFV introduces a number of differences in the way network service provisioning is realised, which differences may be summarised as follows:

Decoupling software from hardware: as the network element is no longer a collection of integrated hardware and software entities, the evolution of both hardware and software may take place independently.

Flexible network function deployment: the detachment of software from hardware enables sharing and reassignment of infrastructure resources. Assuming that the pool of hardware or physical resources is already in place and installed at some NFVI Point of Presence (PoP), network function software instantiation may be substantially automated, making use of different cloud and network technologies which may be currently available, and significantly increasing the speed with which new network services may be deployed over the same physical platform.

Dynamic operation: the decoupling of the functionality of the network function into instantiable software components provides greater flexibility to scale the actual Virtualised Network Function (VNF) performance in a dynamic way and with fine granularity, for example according to the actual traffic for which the network operator needs to provision capacity. Network Functions Virtualisation envisages the implementation of Network Functions (NFs) as software-only entities that run over the NFV Infrastructure (NFVI). Figure 1 illustrates the high-level NFV framework, and is a zoomed out and simplified version of the reference architectural framework of Figure 2, which is reproduced from the above mentioned "Network Functions Virtualisation (NFV); Architectural Framework", ETSI GS NFV 002 V1 .2.1 (2014-12) standardisation document. Referring to Figure 1 , three main working domains are identified in NFV:

Virtualised Network Functions, which are the software implementation of one or more network functions which are capable of running over the NFVI; NFV Infrastructure (NFVI), which includes the range of physical resources and their virtualisation, and supports the execution of the VNFs and

NFV Management and Orchestration, which covers the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualisation, and the lifecycle management of VNFs; NFV Management and Orchestration focuses on all virtualisation-specific management tasks necessary in the NFV framework.

The NFV framework enables dynamic construction and management of VNF instances and the relationships between them regarding data, control, management, dependencies and other attributes. The NFV framework thus provides the capability to load, execute and move VNFs across different but standardised NFVI-PoP multivendor environments. The NFV architectural framework identifies functional blocks and the main reference points between these blocks. Some of the identified functional blocks are already present in current deployments, whilst others might be added to support the virtualisation process and consequent operation. Referring to the reference architectural framework of Figure 2, the main functional blocks of the NFV architectural framework are: Virtualised Network Function (VNF);

Element Management (EM);

NFV Infrastructure (NFVI), including Hardware and virtualised resources, and a Virtualisation Layer;

Virtualised Infrastructure Manager(s) (VIMs);

NFV Orchestrator (NFVO);

VNF Manager(s) (VNFMs); Service, VNF and Infrastructure Description; and

Operations and Business Support Systems (OSS/BSS).

The key reference points, or interfaces, between the above mentioned functional blocks are illustrated in Figure 2, and include the Vi-Vnfm interface, between the one or more VNFMs and the VIM(s), the Nf-Vi interface, between the NFVI and the VIM(s), and the Ve-Vnfm interface, between the one or more VNFMs and the Virtualised Network Functions. The Ve-Vnfm interface may comprise dedicated interfaces to the VNFs themselves (Ve-Vnfm-vnf) and dedicated interfaces to the VNF EM(s) (Ve-Vnfm- em).

The key functional blocks and reference points are also illustrated in Figure 3, which shows a multi-NFVI architecture with a common management system. The following glossary provides a definition of the key functional blocks introduced above and illustrated in Figures 2 and 3, together with related terms employed in the present specification.

Hypervisor: A hypervisor is a piece of computer software, firmware or hardware that creates and runs virtual machines. A computer on which a hypervisor is running one or more virtual machines is defined as a host machine. Each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualised hardware resources.

Virtual Machine (VM): a virtualised computation environment which behaves very much like a physical computer/server. Virtualised Network Function (VNF): an implementation of an executable software program that constitutes the whole or a part of a Network Function and can be deployed on a virtualisation infrastructure.

Virtualised Network Function Component (VNFC): a component of a VNF which is hosted by a dedicated VM; a single VNF may comprise multiple VNFCs. VNF Instance: a run-time instantiation of a VNF resulting from completing the instantiation of the VNF using the VNF deployment and operational information captured in the VNF Description, as well as additional run-time instance-specific information and constraints.

Element Manager (EM): an element management system that performs fault, configuration, accounting, performance and security management.

Virtualised Infrastructure Manager (VIM): comprises the functionalities that are used to control and manage the interaction of a VNF with computing, storage and network resources provided by a NFVI-PoP under its authority, as well as their virtualisation.

VNF Manager (VNFM): responsible for VNF lifecycle management including for example instantiation, update, query, scaling and termination. Multiple VNFMs may be deployed, with some VNFs having a dedicated VNFM, while other multiple VNFs may be managed by a single VNFM.

NFV Orchestrator (NFVO): an element that conducts the orchestration and management of NFV infrastructure and software resources, and is responsible for realising network services on NFVI.

Network Function Virtualisation Infrastructure (NFVI): delivered across multiple NFVI Nodes or PoPs. NFVI-PoPs may be geographically separated and a single NFVI may comprise NFVI-PoPs from different vendors.

Portability: refers to the flexibility to move VNFs between different NFVI-PoPs.

As discussed above, NFV adds new capabilities to communications networks, and requires a new set of management and orchestration functions to be added to the current model of operations, administration, maintenance and provisioning. These functions are specified in the above mentioned "Network Functions Virtualisation (NFV); Management and Orchestration", ETSI GS NFV- MAN 001 V1.1 .1 (2014-12) standardisation document. Allocation of physical resources in the NFVI is a particularly important and potentially complex task covered by the management and orchestration functions. Many different requirements and constraints may need to be satisfied concurrently in the allocation of resources. Allocation and release of resources is thus a dynamic process, performed in response to consumption of those resources by other functions. Resource allocations and releases may be needed throughout the lifetime of any given VNF, although the management and orchestration functions are unaware of individual VNFs.

An infrastructure domain administered by a NFVO may consist of multiple NFVI-PoPs. Different kinds of resource reallocation may therefore be performed: The NFVO may decide to migrate resources or VNFs between different NFVI-PoPs. VNF instance migration is not yet described by ETSI, but it may be assumed that inter- NFVI-PoP migration will require awareness and coordination by NFVO.

A VIM may decide to reallocate or change properties of resources assigned to VNFC instances. Reallocation of computing hosts to a VNFC instance is also referred to as "VM migration", with a "Migrate VM" operation supported on the Nf-Vi interface. Under current specifications, both the VNFM and NFVO remain unaware of any resource reallocation that the VIM initiates. Either as a consequence of VM migration, or independently of any such migration, the properties of memory and CPU that are allocated to a VM may change, in procedures which may be triggered by automated supervision functions or by administrative intervention.

Resource reallocation operations may be configured or triggered by a data centre operator, and should not require handshaking with any tenant operator or administrator. The most prominent motivations for such operations are:

Performing maintenance on NFVI components: planned maintenance activities include upgrade of software and hardware components and may also include change or modification of policies and rules that a VIM uses for resource allocation.

Performing troubleshooting on NFVI components: this may include restart or other kinds of recovery actions on NFVI components, but may also comprise resource consuming observational activities such as logging and tracing.

Optimising workload distribution within the data centre: reallocation of resources, primarily computing hosts, to individual VNFCs may be indicated by resource utilisation measurement results. Optimising power consumption: resource utilisation may vary greatly according to time of the day, day of the week or in as a consequence of special events or occasions. At times of low demand, VNFCs may be moved away from a number of computing hosts to allow them to be powered down. This can be a manually triggered or automated activity.

A VNF is deployed on a single NFVI-PoP, which is controlled by a dedicated VIM. Both VNFM and NFVO are aware of which VIM coordinates the resources for a particular VNF. VNFM and NFVO are however unaware of the particular correlation between VNFC instances and individual resources that have been assigned to them by a VIM. Allocation of individual NFVI resources within a PoP is of temporary nature and can in principle change at any time, as long as service level agreement with the tenant is satisfied.

The current version of ETSI NFV-MANO use case descriptions do not explicitly cover operations related to location-internal re-allocation of NFVI resources to VNFC instances. However, related operations are described on the NFVI hypervisor management interface towards VIM, and a note states that these interfaces may be consumed by authenticated and authorised other parties.

One of the principles of virtualised data centres is that tenants should not become aware of resource reallocation, and reallocation procedures should not result in any ISP degradation. For example, when a live migration of a VM between computing hosts is performed, the VNF and related management systems are not notified and no effects should be experienced by the VNF. In real deployments, this principle is often not respected, as reallocation operations do have an impact on system performance, including for example the disconnection of telephone calls or interruption of network services. This is especially true for application architectures that do not perform load sharing between VNFs, are stateful and/or do not allow VM live migration.

If redundancy is not operative at the time of the event, then ISP impacts can be more severe compared to a scenario in which redundant components or information can be used to alleviate or compensate for the effects of resource reallocation. Detection of such conditions requires VNF specific knowledge and information, which is not available to the data centre administration domain. Some effects of resource reallocation can be alleviated if the VNF application architecture follows certain principles and guidelines. However, many applications that are deployed in virtualised data centres have originally been designed for deployment in a native environment, and conversion of the application architecture to respect virtualisation guidelines and principles may be uneconomical or technically non feasible.

Data centre operators have no knowledge about application specific requirement beyond a generic SLA, and coordination across operational domains is difficult and undesirable, if not impossible in certain instances. It is not therefore possible for the data centre to follow VNF specific procedures when performing resource reallocation in order to mitigate the effects of the reallocation operation. Summary

It is an aim of the present invention to provide a method, apparatus and computer readable medium which at least partially address one or more of the challenges discussed above.

According to a first aspect of the present invention, there is provided a method, performed in a Network Functions Virtualisation Management and Operations (NFV M&O) element, for managing allocation of resources in a Network Functions Virtualisation Infrastructure (NFVI) the method comprising establishing a planned resource allocation adjustment and identifying a Virtualised Network Function Manager (VNFM) managing at least one Virtualised Network Function (VNF) which will be affected by the planned resource allocation adjustment. The method further comprises requesting permission from the identified VNFM to perform the planned resource allocation adjustment and implementing the planned resource allocation adjustment if the requested permission is received.

According to examples of the invention, the resource may be a physical resource such as a host computer, memory or CPU capacity, or may be a software resource, such as a virtual appliance. According to examples of the invention, establishing a planned resource allocation adjustment may comprise deciding to migrate resources or VNFs between different NFVI Points of Presence (POPs). Alternatively, establishing a planned resource allocation adjustment may comprise reallocating or changing resources allocated to an instance of a VNF or VNF Component (VNFC). This may for example include Virtual Machine (VM) migration, in which computing hosts allocated to a VNF are reallocated, or may include changing the allocation of memory or CPU resources for individual VMs. The planned adjustment may be established following a trigger such as an automatic or operator trigger, or in line with a management policy or for any other reason. In further examples, planned resource allocation adjustment may be established via an instruction to implement a resource allocation adjustment, which instruction may be received from another NFV M&O element.

According to examples of the invention, communication with the identified VNFM may take place via another NFV M&O element, such that requesting permission to perform the planned resource allocation adjustment may comprise sending a request for permission to the another VNF M&O element for forwarding to the identified VNFM. Similarly, receiving a response from the identified VNFM may comprise receiving the response via the other NFV M&O element. In such examples, the NFV M&O element may be a VIM and the other NFV M&O element may be a NFVO.

According to examples of the invention, requesting permission from the identified VNFM to perform the planned resource allocation adjustment may comprise preparing an indication of an impact on resource availability for a Virtualisation Container, on which the VNF managed by the identified VNFM is running, of the planned resource allocation adjustment.

According to examples of the invention, the indication of an impact may comprise at least one of: temporary unavailability of resource, reduced availability of resource, complete interruption of service provided by resource etc.

According to examples of the invention, requesting permission from the identified VNFM to perform the planned resource allocation adjustment may further comprise sending to the VNFM an identification of the Virtualisation Container on which the VNF managed by the VNFM is running, an indication of the type of the resource of the planned resource allocation adjustment, and the prepared indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment.

According to examples of the invention, the identification of the Virtualisation Container (VC) may be implicit, for example if the VNFM manages only a single VNF running on a single VC. The VC may for example be a Virtual Machine.

According to examples of the invention, implementing the planned resource allocation adjustment may comprise instructing the NFVI to perform the planned resource allocation adjustment.

According to examples of the invention, the adjustment may be performed by a single NFVI PoP or by multiple NFVI PoPs, for example if the resource allocation adjustment comprises an inter NFVI PoP adjustment.

According to examples of the invention, implementing the planned resource adjustment may also comprise checking for resource availability to support the planned resource allocation adjustment before instructing the NFVI to perform the adjustment. According to examples of the invention, the method may further comprise, if the requested permission is received, receiving a message from the identified VNFM indicating that the affected VNF is preparing for the planned resource allocation adjustment. According to examples of the invention, the method may further comprise, if the requested permission is received, receiving confirmation that the planned resource allocation adjustment has been completed following implementation of the planned resource allocation adjustment. According to examples of the invention, the method may further comprise, if the requested permission is received, informing the identified VNFM that the planned resource allocation adjustment has been completed.

According to examples of the invention, the method may further comprise, if the requested permission is received, checking for a condition attached to the permission, and, if a condition is attached to the permission, waiting for fulfilment of the condition before implementing the planned resource allocation adjustment.

According to examples of the invention, the condition may for example be a delay time period, after expiry of which the planned resource allocation adjustment may be implemented. The delay time period may be specified in the response received by the NFV M&O element in which the requested permission is granted.

According to examples of the invention, the method may further comprise, if the requested permission is not received, repeating, after expiry of a repeat time period, the step of requesting permission from the identified VNFM to perform the planned resource allocation adjustment. In some examples, failure to receive a response to the request for permission within an allocated time period may be interpreted as permission being withheld. In other examples, a negative response may be received, in which permission is explicitly withheld or denied.

According to examples of the invention, the repeat time period may be specified by a manager or operator, or may be specified in a response received from the identified VNFM in which permission is withheld. In some examples, the number of repetitions of the request for permission may be limited to avoid excessive looping. In further examples, a failure to grant permission may be overruled by the NFV M&O element.

According to examples of the invention, the NFV M&O element may comprise a Virtualised Infrastructure Manager (VIM).

According to examples of the invention in which the NFV M&O element is a VIM, identifying a VNFM managing a VNF which will be affected by the planned resource allocation adjustment may comprise requesting the identity of the VNFM managing the affected VNF from another NFV M&O element, which other NFV M&O element may be a NFVO.

According to further examples of the invention in which the NFV M&O element is a VIM, the request for permission to perform the planned resource allocation adjustment may be sent directly to the identified VNFM over a Vi-Vnfm interface, or may be sent via an NFVO via Or-Vi and Or-Vnfm interfaces. In such examples, the instruction to perform the planned resource allocation adjustment may be sent to the NFVI via an Nf- Vi interface.

According to examples of the invention, the NFV M&O element may comprise a Network Function Virtualisation Orchestrator (NFVO).

According to examples of the invention in which the NFV M&O element is a NFVO, the request for permission to perform the planned resource allocation adjustment may be sent directly to the identified VNFM over an Or-Vnfm interface. In such examples, the instruction to perform the planned resource allocation adjustment may be sent to the NFVI via a VIM over an Or-Vi interface and Nf-Vi interface.

According to another aspect of the present invention, there is provided a method, performed in a Virtualised Network Function Manager (VNFM), for managing a Virtualised Network Function (VNF) that consumes resources in a Network Functions Virtualisation Infrastructure (NFVI), which resources are allocated to the VNF. The method comprises receiving, from a Network Functions Virtualisation Management and Operations (NFV M&O) element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM, checking an operational status of the VNF, and responding to the request on the basis of the operational status of the VNF.

According to examples of the invention, the resource may be a physical resource such as a host computer, memory or CPU capacity, or may be a software resource, such as a virtual appliance.

According to examples of the invention, responding to the request on the basis of the operational status of the VNF comprises establishing a response on the basis of the operational status of the VNF, and sending the response to the NFV M&O element.

According to examples of the invention, the method may further comprise sending the response to the NFV M&O element if the response comprises granting the requested permission. According to examples of the invention, receiving a request for permission to perform the planned resource allocation adjustment may comprise receiving from the NFV M&O element: an identification of a Virtualisation Container on which the VNF is running, an indication of the type of the resource of the planned resource allocation adjustment; and an indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment.

According to examples of the invention, checking an operational status of the VNF may comprise requesting operational status information for the VNF.

According to examples of the invention, requesting operational status information may comprise requesting directly from the VNF, for example over the Ve-Vnfm-vnf interface.

According to examples of the invention, requesting operational status information for the VNF may comprises sending a request for operational status information of the VNF to an Element Manager (EM) associated with the VNF.

According to examples of the invention, the request may be made over the Ve-Vnfm- em interface.

According to examples of the invention, checking an operational status of the VNF may further comprise receiving operational status information for the VNF.

According to examples of the invention, the operational status information may be received from the EM associated with the VNF. According to examples of the invention, operational status information may comprise at least one of operational status information for the entire VNF, operational status information for individual components of the VNF, and/or operational status information for individual component instances of the VNF. According to examples of the invention, responding to the request may comprise determining, on the basis of the operational status information for the VNF, whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. According to examples of the invention, the threshold level may comprise a minimum level of service defined in a Service Level Agreement (SLA). According to examples of the invention, if the operational status information comprises operational status information for individual components or component instances of the VNF, responding to the request may comprise establishing a component response for each component or component instance of the VNF and aggregating the component responses to form a complete function response for the VNF.

According to examples of the invention, aggregating may comprise checking whether any of the component or component instance responses are negative, and if so establishing a negative function response, otherwise establishing a positive function response.

According to examples of the invention, checking an operational status of the VNF may comprise requesting whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. The threshold level may for example comprise a minimum level of service defined in a Service Level Agreement (SLA).

According to examples of the invention, requesting whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level may comprise sending a request to an EM associated with the VNF. Alternatively, requesting may comprise sending a request directly to the VNF. According to examples of the invention, responding to the request for permission to perform a planned resource allocation adjustment may comprise receiving an indication as to whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. The indication may for example be received from the VNF directly or from the EM associated with the VNF.

According to examples of the invention, responding to the request for permission to perform a planned resource allocation adjustment may comprise at least one of receiving a component indication for each component or component instance of the VNF and aggregating the component responses to form a complete function indication for the VNF, or receiving a complete function indication for the VNF. According to examples of the invention, aggregating may comprise checking whether any of the component responses are negative, and if so establishing a negative function response, otherwise establishing a positive function response.

According to examples of the invention, the method may further comprise, if responding to the request comprises granting permission, triggering preparatory actions in the VNF. According to examples of the invention, the nature of the preparatory actions may be determined in the VNFM or in the EMA NF.

According to examples of the invention, triggering preparatory actions in the VNF may comprise sending a trigger message to a VNF or to an EM associated with the VNF.

According to examples of the invention, the preparatory actions may comprise VNF level operational procedures to mitigate the impact of the planned resource allocation adjustment. The procedures may for example include isolation of an affected component of the VNF from new operational traffic, redistribution of workload among components of the VNF, establishing additional redundancy across components of the VNF etc.

According to examples of the invention, the method may further comprise informing the NFV M&O element that preparatory actions are taking place in the VNF.

According to examples of the invention, the method may further comprise receiving confirmation that the triggered preparatory actions have been completed, and, on receipt of the confirmation, sending the established response to the NFV M&O element. The confirmation may for example be received from the EM or directly from the VNF. According to examples of the invention, the method may further comprise receiving confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed.

According to examples of the invention, the method may further comprise, on receipt of the confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed, triggering clean up actions at the VNF. According to examples of the invention, triggering may comprise sending a trigger message to the EM associated with the VNF. Clean up actions may for example comprise re-establishment of redundancy among VNF components, redistribution of workload amongst VNF components, etc.

According to examples of the invention, the method may further comprise receiving confirmation that the clean up actions have been completed. The confirmation may for example be in the form of a message from the EM associated with the VNF.

According to examples of the invention, responding to the request for permission to perform a planned resource allocation adjustment by granting permission may comprise attaching a condition to the permission. According to examples of the invention, fulfilment of the condition may be required before the planned resource allocation adjustment is performed. The condition may for example be a delay time.

According to examples of the invention, refusing the request for permission to perform a planned resource allocation adjustment may comprise attaching a repeat time to a negative response to the request, after which the request may be repeated.

According to another aspect of the present invention, there is provided a computer program configured, when run on a computer, to carry out a method according to any one of the preceding aspects of the present invention.

According to another aspect of the present invention, there is provided a computer program product comprising computer readable media having stored thereon a computer program according to the preceding aspect of the present invention. According to another aspect of the present invention, there is provided a Network Functions Virtualisation Management and Operations (NFV M&O) element for managing allocation of resources in a Network Functions Virtualisation Infrastructure (NFVI), the NFV M&O element comprising a processor and a memory, the memory containing instructions executable by the processor such that the NFV M&O element is operative to establish a planned resource allocation adjustment and identify a Virtualised Network Function Manager (VNFM) managing at least one Virtualised Network Function (VNF), which will be affected by the planned resource allocation adjustment. The NFV M&O element is also operative to request permission from the identified VNFM to perform the planned resource allocation adjustment, and implement the planned resource allocation adjustment if the requested permission is received.

According to examples of the invention, the NFV M&O element may be further operative to request permission from the identified VNFM to perform the planned resource allocation adjustment by preparing an indication of an impact on resource availability for a Virtualisation Container, on which the VNF managed by the identified VNFM is running, of the planned resource allocation adjustment.

According to examples of the invention, the NFV M&O element may be further operative to request permission from the identified VNFM to perform the planned resource allocation adjustment by sending to the VNFM: an identification of the Virtualisation Container on which the VNF managed by the VNFM is running, an indication of the type of the resource of the planned resource allocation adjustment, and the prepared indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment. According to examples of the invention, the NFV M&O element may be further operative to, if the requested permission is received, check for a condition attached to the permission, and, if a condition is attached to the permission, wait for fulfilment of the condition before implementing the planned resource allocation adjustment. According to examples of the invention, the NFV M&O element may be further operative to, if the requested permission is not received, repeat, after expiry of a repeat time period, the step of requesting permission from the identified VNFM to perform the planned resource allocation adjustment. According to examples of the invention, the NFV M&O element may comprise a Virtualised Infrastructure Manager (VIM), or may comprise a Network Function Virtualisation Orchestrator (NFVO). Implementation may comprise instructing the VIM to perform the adjustment, for example if the NFV M&O element is a NFVO

According to another aspect of the present invention, there is provided a Virtualised Network Function Manager (VNFM) for managing a Virtualised Network Function (VNF) that consumes resources in a Network Functions Virtualisation Infrastructure (NFVI), which resources are allocated to the VNF. The VNFM comprises a processor and a memory, the memory containing instructions executable by the processor such that the VNFM is operative to receive, from a Network Functions Virtualisation Management and Operations (NFV M&O) element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM, check an operational status of the VNF, and respond to the request on the basis of the operational status of the VNF. According to examples of the invention, the VNFM may be further operative to check an operational status of the VNF by requesting operational status information for the VNF.

According to examples of the invention, the VNFM may be further operative to check an operational status of the VNF by requesting whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level.

According to examples of the invention, the VNFM may be further operative to, if responding to the request comprises granting permission, trigger preparatory actions in the VNF.

According to examples of the invention, the VNFM may be further operative to receive confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed, and, on receipt of the confirmation, to trigger clean up actions at the VNF.

According to examples of the invention, the NFV M&O element may comprise a Virtualised Infrastructure Manager (VIM), or a Network Function Virtualisation Orchestrator (NFVO). According to another aspect of the present invention, there is provided a Network Functions Virtualisation Management and Operations (NFV M&O) element for managing allocation of resources in a Network Functions Virtualisation Infrastructure (NFVI) the NFV M&O element comprising a resource unit for establishing a planned resource allocation adjustment and an identifying unit for identifying a Virtualised Network Function Manager (VNFM) managing at least one Virtualised Network Function (VNF) which will be affected by the planned resource allocation adjustment. The NFV M&O element further comprises a permission unit for requesting permission from the identified VNFM to perform the planned resource allocation adjustment, and an implementation unit for implementing the planned resource allocation adjustment if the requested permission is received.

According to another aspect of the present invention, there is provided a Virtualised Network Function Manager (VNFM) for managing a Virtualised Network Function (VNF) that consumes resources in a Network Functions Virtualisation Infrastructure (NFVI), which resources are allocated to the VNF. The VNFM comprises a receiving unit for receiving, from a Network Functions Virtualisation Management and Operations (NFV M&O) element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM, a status unit for checking an operational status of the VNF, and a response unit for responding to the request on the basis of the operational status of the VNF.

Brief description of the drawings For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

Figure 1 illustrates a high-level NFV framework;

Figure 2 illustrates a reference architectural framework for NFV;

Figure 3 illustrates a multi-NFVI architecture with common management systems; Figure 4 is a flow chart illustrating process steps in a method for managing allocation of resources in a NFVI; Figures 5a and 5b show a flow chart illustrating process steps in another method for managing allocation of resources in a NFVI; Figure 6 is a flow chart illustrating process steps in a method for managing a VNF that consumes resources in a NFVI;

Figures 7a and 7b show a flow chart illustrating process steps in another method for managing a VNF that consumes resources in a NFVI;

Figure 8 is a sequence diagram illustrating intra-PoP resource reallocation according to an example of the method of Figures 5a and 5b;

Figure 9 is a sequence diagram illustrating inter-PoP resource reallocation according to another example of the method of Figures 5a and 5b;

Figure 10 is a block diagram illustrating functional units in a NFV M&O element;

Figure 1 1 is a block diagram illustrating functional units in a VNFM;

Figure 12 is a block diagram illustrating functional units in another example of NFV M&O element; and

Figure 13 is a block diagram illustrating functional units in another example of VNFM.

Detailed Description

Examples of the present invention provide methods enabling what may be considered as "courteous cloud provision", in which a Network Functions Virtualisation Management and Orchestration (NFV M&O) element asks permission before making an adjustment to resource allocation which will affect a VNF. If permission is granted, the adjustment is made, if permission is not granted, the adjustment is postponed. The permission to perform a resource allocation adjustment is granted or withheld by a VNFM managing the VNF which will be affected by the adjustment. The logic for deciding whether an adjustment can be supported by the VNF may be contained at the VNFM, or may be contained within the VNF itself, or an associated EM. The NFV M&O element may be a VIM, for example if the resource allocation adjustment is an intra NFVI-PoP adjustment, or may be a NFVO, if the resource allocation adjustment is an inter NFVI-PoP adjustment. The VNFM interacts on a VNF level either with the VNF itself or with its associated EM, and is thus able to perform VNF level checks concerning the effects of a planned resource allocation adjustment which go far beyond what can be checked with a standard VM level health check. In addition to granting or withholding permission for a resource allocation adjustment, the VNFM may also trigger or initiate preparatory actions in the VNF to mitigate the effects of the planned resource allocation adjustment, for example isolating a component of the VNF which will be affected by the adjustment, allowing ongoing calls to terminate and/or rejecting new assignments. On receiving confirmation that the resource allocation adjustment has been completed, the VNFM may also trigger clean up actions in the VNF, including for example the re-establishment of redundancy or the redistribution of workload among components of the VNF.

Figure 4 is a flow chart illustrating process steps in a first example of a method 100 conducted at a NFV M&O element for managing allocation of resources in a Network Functions Virtualisation Infrastructure (NFVI). The NFV M&O element may for example be a VIM or a NFVO. The method 100 comprises, in a first step 102, establishing a planned resource allocation adjustment. The resource may be a physical resource such as a host computer, memory or CPU capacity, or may be a software resource, such as a virtual appliance. Having established the planned resource allocation adjustment, the NFV M&O element then, in step 104, identifies a VNFM managing at least one VNF which will be affected by the planned resource allocation adjustment. The NFV M&O element then requests permission from the identified VNFM to perform the planned resource allocation adjustment in step 106, and checks for receipt of the requested permission in step 1 12. If the permission is received, the NFV M&O element implements the planned resource allocation adjustment in step 124. As discussed above, the NFV M&O element may be a VIM or may be a NFVO. The nature of the NFV M&O element may impact the manner in which communication with the VNFM takes place. For example, in the case of a VIM, communication with the identified VNFM may take place via a NFVO, such that requesting permission to perform the planned resource allocation adjustment may comprise sending a request for permission to the NFVO for forwarding to the identified VNFM. Similarly, receiving granted permission from the identified VNFM may comprise receiving the permission via the NFVO. The process of implementing the planned resource allocation adjustment may also vary according to the nature of the NFV M&O element. For example, a VIM may instruct a NFVI directly, but a NFVO may send an instruction to the NFVI via a VIM.

An effect of the above discussed example method, together with cooperating actions at a VNFM which are discussed below, is to introduce a control mechanism such that planned resource allocation adjustments are performed in accordance with NFV requirements but also in such a manner as to avoid or minimise impact upon currently running operations. Delay and repeat timers may be introduced into the process flow in order to avoid deadlocks, and an overwrite mechanism may also be introduced, to ensure essential maintenance operations may be carried out, and to avoid endless loop cycles. Referring back to Figure 2, the method 100 discussed above may be conducted via message flows over the interfaces Or-Vnfm and/or Vi-Vnfm, for permission requests and responses, Ve-Vnfm (em/vnf) for the checking by a VNFM for operational status of a VNF, and Nf-Vi for the implementing of a planned resource allocation adjustment, following receipt of permission. In some examples, a condition may be attached to a granting of permission, so as to impose a delay before the adjustment is carried out. This may allow time for preparatory actions to be completed in the VNF. In the event of an imposed delay, a locking mechanism may be introduced to prevent any further operations on other VMs on which the affected VNF is running.

Figures 5a and 5b illustrate process steps in another example of a method 200 conducted at a NFV M&O element for managing allocation of resources in a NFVI. As for the method 100, the NFV M&O element may be a VIM in the case of an intra NFVI- PoP adjustment, or a NFVO in the case of an inter-NFVI PoP adjustment. The method 200 of Figures 5a and 5b provides one example of how the steps of the method 100 of Figure 4 may be implemented and supplemented to provide the above discussed and additional functionality.

Referring to Figure 5a, in a first step 202, the NFV M&O element establishes a planned resource allocation adjustment. In the case of a NFVO NFV M&O element, this may comprise deciding to migrate resources or VNFs between different NFVI-PoPs. In the case of a VIM NFV M&O element, establishing a planned resource allocation adjustment may comprise deciding to adjust or change resources allocated to an instance of a VNF or VNF Component (VNFC). This may for example include Virtual Machine (VM) migration, in which computing hosts allocated to a VNF are reallocated, or may include changing the allocation of memory or CPU resources for individual VMs. The planned adjustment may be established following a trigger 202a, such as an automatic or operator trigger, or a decision 202b may be taken by the NFV M&O element in line with a management policy or for any other reason. In further examples, planned resource allocation adjustment may be established following receipt of a message 202c instructing a resource allocation adjustment, which instruction may be received from another NFV M&O element. Having established the planned resource allocation adjustment, the NFV M&O element then identifies a VNFM managing at least one VNF which will be affected by the planned resource allocation adjustment in step 204. The NFV M&O element may not have visibility of individual VNFs, but may identify an appropriate VNFM by identifying a Virtual Container, such as a VM, which will be affected by the planned resource allocation adjustment, and identifying the VNFM associated with the affected VM. The VNFM will have knowledge of which VNF is running on the affected VM. If the NFV M&O element is a VIM, the NFV M&O element may not have the necessary visibility to identify a VNFM directly, and may therefore identify a VNFM managing a VNF which will be affected by the planned resource allocation adjustment by requesting the identity of the VNFM managing an affected VNF from another NFV M&O element, such as a NFVO in step 204a.

In step 206, the NFV M&O element requests permission from the identified VNFM to perform the planned resource allocation adjustment. This may comprise a first step 206a of preparing an indication of an impact on resource availability for the Virtualisation Container on which the VNF managed by the identified VNFM is running, of the planned resource allocation adjustment. The indication of an impact will vary according to the nature of the resource for which the allocation is being adjusted, and the nature of the adjustment. The indication of an impact may for example be at least one of temporary unavailability of resource, reduced availability of resource, or complete interruption of service provided by resource etc.

In a second step 206b, the NFV M&O element may send the prepared indication of an impact on resource availability for the Virtualisation Container to the identified VNFM, together with an identification of the Virtualisation Container on which the VNF managed by the VNFM is running and an indication of the type of the resource of the planned resource allocation adjustment. In some examples, the identification of the Virtualisation Container (VC) may be implicit, for example if the VNFM manages only a single VNF running on a single VC. As discussed above, communication with the identified VNFM may be direct or may be via another NFV M&O element, according to the nature of the NFV M&O element. If the NFV M&O element is a VIM, the request for permission to perform the planned resource allocation adjustment may be sent directly to the identified VNFM over a Vi- Vnfm interface, or may be sent via an NFVO via Or-Vi and Or-Vnfm interfaces. If the NFV M&O element is a NFVO, the request for permission to perform the planned resource allocation adjustment may be sent directly to the identified VNFM over an Or- Vnfm interface.

If permission is going to be granted, the NFV M&O element may receive, at step 208, a message from the identified VNFM indicating that the affected VNF is preparing for the planned resource allocation adjustment. If permission is going to be withheld, or in example of the method in which a preparatory message is not provided for, a message indicating that the affected VNF is preparing for the planned resource allocation adjustment may not be received.

Referring now to Figure 5b, the NFV M&O element then checks for a response from the VNFM in step 210. In some examples of the method 200, a response may always be received from the VNFM, with the response being either positive, granting permission, or negative, withholding permission. In other examples, in order to reduce signalling load, a response may only be sent if permission is being granted, with a failure to receive a response within a given time frame being interpreted as a withholding or denial of permission. Figure 5b illustrates an example in which a response is only received in the event of permission being granted, although it will be appreciated that this is merely one example, provided for the purposes of illustration. Referring to Figure 5b, if a response is not received in step 212, this is interpreted as a withholding of permission, possibly after expiry of a response time window (not shown). The NFV M&O element then checks for existence of a repeat time period in step 214, which may for example be pre-programmed by a manager or operator or, in examples in which a response is always received, may be specified in a negative response. The NFV M&O element checks for expiry of the repeat timer in step 216, and on expiry of the repeat timer, returns to step 206 and repeats the step of requesting permission from the identified VNFM to perform the planned resource allocation adjustment. In some examples of the method, the number of repetitions of the request for permission may be limited to avoid excessive looping. In still further examples, a failure to grant permission may be overruled by the NFV M&O element, for example in the event of a resource allocation adjustment required for an essential management operation, or on reaching a limit on the number of repetitions of the request for permission.

Returning to step 212, if a response is received granting permission for the requested allocation adjustment, the NFV M&O element then checks, at step 218, for a condition included in the response, fulfilment of which is required before the resource allocation adjustment takes place. The condition may for example be a delay time period, after expiry of which the planned resource allocation adjustment may be implemented. The delay time period may be specified in the response received by the NFV M&O element in which the requested permission is granted. If a condition is included in the response at step 220, the NFV M&O element checks for fulfilment of the condition in step 222, and only proceeds to the next step when the condition has been fulfilled, for example when a delay time period has expired.

Once the condition has been fulfilled, or if no condition was included in the response, the NFV M&O element implements the planned resource allocation adjustment in step 224, which may comprise instructing the appropriate NFVI to perform the planned resource allocation adjustment in step 224a, for example after checking for resource availability to support the planned resource allocation adjustment. If the NFV M&O element is a VIM, the instruction to perform the planned resource allocation adjustment may be sent directly to the NFVI over the Nf-Vi interface. If the NFV M&O element is a NFVO, the instruction to perform the planned resource allocation adjustment may be sent to the NFVI via a VIM over an Or-Vi interface and Nf-Vi interface. The adjustment may then be performed by a single NFVI-PoP or by multiple NFVI-PoPs, for example if the resource allocation adjustment comprises an inter NFVI-PoP adjustment.

Following completion of the planned resource allocation adjustment by the NFVI, the NFV M&O element then receives confirmation that the planned resource allocation adjustment has been completed at step 226, and informs the identified VNFM that the planned resource allocation adjustment has been completed at step 228. The methods 100, 200 described above are conducted within a NFV M&O element, and may be complemented by methods taking place in a VNFM. Figures 6, 7a and 7b illustrate examples of such methods. Figure 6 is a flow chart illustrating process steps in a first example of a method 300 performed in a Virtualised Network Function Manager (VNFM), for managing a VNF that consumes resources in a NFVI, which resources are allocated to the VNF. The method comprises a first step 302 of receiving, from a NFV M&O element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM. The resource may be a physical resource such as a host computer, memory or CPU capacity, or may be a software resource, such as a virtual appliance. The request for permission may include an identification of a Virtualisation Container (for example a VM) on which the VNF is running, an indication of the type of the resource of the planned resource allocation adjustment; and an indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment. The method then comprises checking an operational status of the VNF in step 304 and responding to the request on the basis of the operational status of the VNF in step 318. Responding to the request on the basis of the operational status of the VNF may comprise establishing a response on the basis of the operational status of the VNF, and sending the response to the NFV M&O element. In some examples, a response may always be sent, with the response either granting or withholding the requested permission. In other examples, the response may be sent only if the response comprises granting the requested permission, a withholding of the response being interpreted by the NFV M&O element as a withholding of permission.

Figures 7a and 7b illustrate process steps in another example of a method 400 conducted at a VNFM for managing a VNF that consumes resources in a NFVI, which resources are allocated to the VNF. The method 400 of Figures 7a and 7b provides one example of how the steps of the method 300 of Figure 6 may be implemented and supplemented to provide the above discussed and additional functionality.

Referring to Figure 7a, in a first step 402, the VNFM receives, from a NFV M&O element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM. The resource may be a physical resource such as a host computer, memory or CPU capacity, or may be a software resource, such as a virtual appliance. The request for permission may include an identification of a Virtualisation Container on which the VNF is running, an indication of the type of the resource of the planned resource allocation adjustment; and an indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment. The NFV M&O element may be a VIM or may be a NFVO, and the request for permission may be received directly from the NFV M&O element or may be received via another element. For example, if the NFV M&O element is a VIM, the request for permission may be received from the VIM via a NFVO. After receiving the request for permission from the NFV M&O element, the VNFM then proceeds to check an operational status of the VNF to be affected. This step may take different forms depending upon where the logic to decide whether or not the operational status of the VNF can accommodate the planned resource allocation adjustment is located. This logic may be located with the VNFM or with the individual VNFs or with their element managers. Both of these options are illustrated in Figure 7a, with the first option (decision logic in the VNFM) shown on the left of the Figure in stream a, and the second option (decision log in the VNF or EM) shown on the right of the Figure in stream b. Referring to the left side of Figure 7a, if the decision logic is located in the VNFM, the VNFM proceeds to request operational status information for the VNF in step 404ai. This may involve requesting operational status information directly from the VNF, for example over the Ve-Vnfm-vnf interface, or may involve sending a request for operational status information of the VNF to an Element Manager (EM) associated with the VN, for example over the Ve-Vnfm-em interface. The requested operational status information is then received at step 404aii, either directly from the VNF or from the EM associated with the VNF.

The operational status information may be operational status information for the entire VNF, operational status information for individual components of the VNF, and/or operational status information for individual component instances of the VNF. Additional aggregating steps may be conducted in the VNFM if the operational status information concerns individual components or component instances of the VNF, as discussed in further detail below.

Having received operational status information, the VNFM then proceeds to respond to the request for permission received in step 402 on the basis of the operational status of the VNF. In the illustrated example, this first comprises establishing a response to the request on the basis of the operational status of the VNF.

If operational status information is received for the entire VNF, then the VNFM then proceeds, at step 406ai to determine, on the basis of the operational status information for the VNF, whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. The threshold level may for example be a minimum service level defined in a Service Level Agreement (SLA), or may be set in any other manner by an operator, client or other authority.

If the operational status information is received for individual components or component instances of the VNF, the VNFM then proceeds, at step 406aii, to establish a component response for each component or component instance of the VNF, by, for each component or component instance, determining, on the basis of the operational status information for the VNF component or component instance, whether the VNF component or component instance can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF component or component instance that exceeds a threshold level. The VNFM then, in step 406aiii, aggregates the component responses to form a complete function response for the VNF. Aggregating the component responses at step 406aiii may comprise checking whether any one of the component or component instance responses is negative, and if so establishing a negative function response, otherwise establishing a positive function response.

The above discussion illustrates one example of how a response may be established if the logic to decide whether or not the operational status of the VNF can accommodate the planned resource allocation adjustment is located in the VNFM. Referring now to the right side of Figure 7a, following receipt of the request for permission to perform a planned resource allocation adjustment in step 402, if the decision logic is located in the VNF or EM, the VNFM proceeds to check operational status of the VNF by requesting, in step 404bi, whether or not the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. As previously, the threshold level may be for example a minimum level of service defined in an SLA. The request sent in step 404bi may be sent directly to the VNF or may be sent to the EM associated with the VNF. The VNFM then receives an indication in step 404bii as to whether or not the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. As for the operational status information in stream a, the indication may be for the entire VNF or for individual components or component instances of the VNF. The indication(s) may be received directly from the VNF or from the EM associated with the VNF. It may be envisaged for example that the EM queries individual VNF components for operational status information and then formulates the appropriate indication or indications on the basis of the operational status information received from the VNF, which indication or indications is/are forwarded to the VNFM.

On receiving the indication(s) in step 404bii, the VNFM then establishes a response to the request received in step 402 on the basis of the received indication(s). If a complete indication is received for the entire VNF, then the VNFM sets this indication to be the established response in step 406bi. Thus if the indication is positive, stating that the planned resource allocation adjustment can be accommodated, then a positive response to the request is established. If the indication is negative, stating that the planned resource allocation adjustment cannot be accommodated, then a negative response to the request is established. If a series of component or component instance indications are received, then the VNFM aggregates the component indications to form a complete function response for the VNF. This may comprise checking whether any of the component indications are negative, and if so establishing a negative function response, otherwise establishing a positive function response. Regardless of whether the decision making logic is located in the VNFM or in the VNF/EM, by the end of step 406, the VNFM has established a response to the request received in step 402. Subsequent actions are then performed according to whether the response is positive, granting permission, or negative, withholding permission. Referring to Figure 7b, if, at step 408, the response is found to be negative, then the VNFM withholds the requested permission at step 418b. The step of withholding permission may, as discussed earlier with reference to Figures 5a and 5b, take different forms. In one example, a response to the request received in step 402 may be sent by the VNFM in all cases. Thus withholding permission at step 418b may comprise sending a negative response to the NFV M&O element. In some examples, a repeat time may be attached to the negative response, after which repeat time the request may be repeated. In other examples, in order to reduce signalling load, a response may only be sent if the response is positive, granting the requested permission. In such examples, withholding permission may comprise sending no response, which will be interpreted by the NFV M&O element as a withholding of permission.

Referring again to Figure 7b, if the established response is positive, granting the requested permission, then the VNFM proceeds to trigger preparatory actions in the VNF at step 410. The precise nature of the preparatory actions may be determined in the VNFM or in the VNF/EM and the process of triggering the preparatory actions may comprise sending a trigger message to the VNF or to the associated EM. The preparatory actions may include VNF level operational procedures to mitigate the impact of the planned resource allocation adjustment. The procedures may for example include isolation of an affected component of the VNF from new operational traffic, redistribution of workload among components of the VNF, establishing additional redundancy across components of the VNF etc. Other preparatory actions may include allowing the graceful termination of existing services, sessions or calls and the refusal of new service, session or call requests. After triggering the preparatory actions, the VNFM then informs the NFV M&O element in step 412 that preparatory actions are taking place in the VNF.

In step 416 the VNFM receives confirmation that the triggered preparatory actions have been completed. The confirmation may for example be received from the EM or directly from the VNF. On receipt of this confirmation, the VNFM sends the established response granting permission to the NFV M&O element in step 418a. In some examples, a condition may be attached to the response, fulfilment of the condition being required before the planned resource allocation adjustment is performed. The condition may for example be a delay time.

In step 420, the VNFM receives confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed, and, in step 422, the VNFM triggers clean up actions at the VNF by sending a trigger message to the VNF or associated EM. Clean up actions may for example include re-establishment of redundancy among VNF components, redistribution of workload amongst VNF components, etc. Finally, the VNFM receives confirmation that the clean up actions have been completed, for example in the form of a message from the VNF or the EM associated with the VNF. The above described methods, conducted in a NFV M&O element and in a VNFM, cooperate to ensure that resource allocation adjustments are conducted in such a manner as to minimise the negative impact of such adjustments, allowing refusal of an adjustment and in some examples allowing time for preparatory actions to be taken before an adjustment and clean up operations to be conducted after an adjustment. Te sequence diagrams in Figures 8 and 9 illustrate example message flow between cooperating elements according to examples of the present invention. In the sequences presented, an architecture is assumed according to which all communication between a VIM and VNFM is performed via a NFVO. In other examples in which a VIM has a direct interface to a VNFM, the signalling may be modified to take account of the possibility for the direct exchange of messages between the VIM and the VNFM. Figure 8 illustrates an example intra NFVI-PoP adjustment in which a VNF comprises two VNF component instances 2, 4, and a VIM 10, acting as the NFV M&O element of Figures 5a and 5b decides to migrate VNF component instances between different computer hosts. It will be appreciated that message names illustrated in the message sequence are merely examples of possible message names that could be used. Initially, the VIM 10 establishes a need to perform a resource allocation adjustment that may affect a particular VM hosting a VNF component instance. This need might be established on the basis of an operator trigger or because of an automatic policy or for any other reason. The VIM 10 either knows the relation between the affected VM and its corresponding VNFM 8 or it may fetch this information from the NFVO 12. Alternatively, as illustrated, all communication with the VNFM may be performed through the NFVO. The VIM 10 then contacts the VNFM 8 to request permission to perform the resource allocation adjustment. The VNFM 8 contacts the EM 6 associated with the VNF component instance hosted on the affected VM to check its operative status. The EM 6 checks the operative status of all VNF component instances and sends a VNF status report including an indication s to whether the VNF can accommodate the planned resource allocation adjustment. The indication may for example be one of: ΌΚ", ΌΚ, execute after time x", or "Not OK, re-attempt after time y". If the indication is positive (adjustment accepted), the VNFM 8 then triggers preparatory actions to be performed by the VNF component instances and informs the VIM 10, via the NFVO 12, that preparations are taking place. The EM 6 informs the VNFM 8 when preparations are complete, and the VNFM 8 then sends a positive answer to the request for permission to perform the resource allocation adjustment. This answer is again sent via the NFVO 12. On receipt of the granted permission, the VIM 10 checks for resource availability to support the resource allocation adjustment, and orders the NFVI 14 to perform the adjustment. The NFVI confirms that the adjustment has been completed and this confirmation is passed to the VNFM 8. The VNFM 8 then triggers clean up operations in the VNF, which, when completed, are reported back to the VNFM 8 by the EM 6.

It will be appreciated that the VNFM does not need to know the specific identities of the resources for which the allocation is to be adjusted. It is sufficient that the request for permission sent by the VIM indicates a reference to the affected VM or other Virtualisation Container, the affected resource type and a qualification about the kind of impact on resource availability. Figure 9 illustrates an inter NFVI-PoP adjustment, in which a need for resource reallocation is established by a NFVO 32. Communication between the NFVO 32, VNFM 28, EM 26 and VNF component instances 22, 24 is illustrated as substantially the same as that discussed above with reference to the intra-NFVI-PoP example of Figure 8, with the NFVO 32 coordinating as the NFV M&O element of Figures 5a and 5b. Communication between the NFVO 32, VIM1 30A, NFVI 1 34A, VIM2 30B and NFVI2 34B, required for the actual resource allocation adjustment between NFVI-PoPs, has not yet been standardised by ETSI and is thus illustrated as a white box in Figure 9. The following examples illustrate different operational scenarios which may be managed according to the methods discussed above with reference to Figures 4 to 9.

In a first example, a VNF comprises multiple components running either a 1 +1 (EX/SB) or in an N+1 (cluster) redundancy scheme. In the case of a 1 +1 redundancy scheme, at least one VM component of the group should be running at any one time in order to provide the business service for which the machine group is responsible. In the case of an N+1 redundancy scheme, more VM components of the group should be running at any one time to ensure the level of functionality for which the machine group is responsible can be provided. During a VNF status check according to examples of the present invention, the associated EM checks the status of the VNF components and determines whether or not that the service provided by the VNF will be affected by the requested resource allocation adjustment. If for example the permission request indicates that the computing host will experience a service interruption, and no redundancy is currently available, the requested permission should be withheld. Examples of the present invention ensure that the resource allocation adjustment is only given permission to take place if sufficient other instances of the redundancy group are running to ensure service functionality.

In a second example, a scalable telephony system has an n+1 redundancy scheme, and the remaining VNF component instance is able to handle the dimensioned capacity of the node when one component instance is taken down for maintenance. The VNFM checks that n+1 component instances are operational, and thus that the redundancy scheme can accommodate the requested resource allocation adjustment, before granting permission. In order to allow graceful disconnection of ongoing telephony calls, the component instance to be removed is transferred into an isolation state as part of preparatory operations. This allows ongoing services to terminate naturally, while new service requests are handled by the other component instances.

In a third example, some applications may take advantage of additional computing resources, for example CPU cores, which are added during runtime, and examples of the present invention may serve as a trigger to make use of such capability. If computing resources are withdrawn during runtime, the applications may gracefully adjust to this new environment as well, thanks to the possibility of withholding permission for adjustments that cannot be accommodated, and to the option of conducting preparatory and clean up operations.

As discussed above, examples of the methods 100, 200 may be conducted in a NFV M&O element, which may for example be a VIM or a NFVO. The methods may be implemented on receipt of suitable computer readable instructions, which may be embodied within a computer program running on the NFV M&O element. Figure 10 illustrates a first example of a NFV M&O element 500 which may execute the methods 100, 200 of the present invention, for example on receipt of suitable instructions from a computer program. Referring to Figure 10, the NFV M&O element 500 comprises a processor 501 and a memory 502. The memory 502 contains instructions executable by the processor 501 such that the NFV M&O element 500 is operative to conduct the steps of the methods 100, 200 of Figures 4 and/or 5a and 5b. The methods 300, 400 may be conducted in a VNFM, for example on receipt of suitable computer readable instructions, which may be embodied within a computer program running on the VNFM. Figure 1 1 illustrates a first example of a VNFM 600 which may execute the methods 300, 400 of the present invention, for example on receipt of suitable instructions from a computer program. Referring to Figure 1 1 , the VNFM 600 comprises a processor 601 and a memory 602. The memory 602 contains instructions executable by the processor 601 such that the VNFM 600 is operative to conduct the steps of the methods 300, 400 of Figures 6 and/or 7a and 7b. Figure 12 illustrates functional units in another example of NFV M&O element 700 which may execute the methods 100, 200 of the present invention, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 12 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 12, the NFV M&O element, which may be a VIM or a NFVO, comprises a resource unit 702 for establishing a planned resource allocation adjustment, and an identifying unit 704 for identifying a VNFM managing at least one VNF which will be affected by the planned resource allocation adjustment. The NFV M&O element 700 further comprises a permission unit 706 for requesting permission from the identified VNFM to perform the planned resource allocation adjustment, and an implementation unit 708 for implementing the planned resource allocation adjustment if the requested permission is received.

The permission unit 706 may be for preparing an indication of an impact on resource availability for a Virtualisation Container, on which the VNF managed by the identified VNFM is running, of the planned resource allocation adjustment. The permission unit 706 may also be for sending to the VNFM an identification of the Virtualisation Container on which the VNF managed by the VNFM is running, an indication of the type of the resource of the planned resource allocation adjustment, and the prepared indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment. The implementation unit 708 may be for instructing the NFVI to perform the planned resource allocation adjustment. The implementation unit 708 may comprise a notification unit 712 for receiving a message from the identified VNFM indicating that the affected VNF is preparing for the planned resource allocation adjustment, and for receiving confirmation that the planned resource allocation adjustment has been completed following implementation of the planned resource allocation adjustment. The notification unit 712 may also be for, informing the identified VNFM that the planned resource allocation adjustment has been completed.

The implementation unit 708 may also comprise a condition unit 710 for checking for a condition attached to the permission, and, if a condition is attached to the permission, waiting for fulfilment of the condition before the implementation unit 708 implements the planned resource allocation adjustment. The implementation unit 708 may also comprise a repeat unit 714 for, if permission is withheld, checking for expiry of a repeat time period, and, on expiry of the repeat time period, causing the permission unit repeat the step of requesting permission from the identified VNFM to perform the planned resource allocation adjustment.

Figure 13 illustrates functional units in another example of VNFM 800 which may execute the methods 300, 400 of the present invention, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 13 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 13, the VNFM 800 comprises a receiving unit 802 for receiving, from a NFV M&O element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM. The VNFM 800 also comprises a status unit 804 for checking an operational status of the VNF, and a response unit 806 for responding to the request on the basis of the operational status of the VNF.

The response unit 806 may be for establishing a response on the basis of the operational status of the VNF, and sending the response to the NFV M&O element, for example via a transmitting unit 814. The response unit 806 may send the response to the NFV M&O element only if the response comprises granting the requested permission. The status unit 804 may be for requesting operational status information for the VNF, for example by sending a request for operational status information of the VNF to an EM associated with the VNF or to the VNF directly. The status unit 804 may also be for receiving operational status information for the VNF.

The response unit 806 may be for determining, on the basis of the operational status information for the VNF, whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. The operational status information comprises at least one of operational status information for the entire VNF, operational status information for individual components of the VNF, or operational status information for individual component instances of the VNF.

The response unit may comprise an aggregating unit, and, If the operational status information comprises operational status information for individual components or component instances of the VNF, the response unit 806 may be for establishing a component response for each component or component instance of the VNF and the aggregating unit 808 may be for aggregating the component responses to form a complete function response for the VNF.

The status unit 804 may also be for requesting whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level, for example by sending a request to the VNF or an EM associated with the VNF.

The response unit 806 may be for receiving an indication as to whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level. The response unit 806 may be for receiving a component indication for each component or component instance of the VNF with the aggregating unit 808 being for aggregating the component responses to form a complete function indication for the VNF. The response unit 806 may also be for receiving a complete function indication for the VNF.

The VNFM may further comprise a trigger unit 816 for triggering preparatory actions in the VNF, for example by sending a trigger message to a VNF or to an EM associated with the VNF. The transmitting unit 814 may be for informing the NFV M&O element that preparatory actions are taking place in the VNF. The trigger unit may also be for receiving confirmation that the triggered preparatory actions have been completed, and, on receipt of the confirmation, causing the transmitting unit to send the established response to the NFV M&O element.

The receiving unit 802 may also be for receiving confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed, and the trigger unit 816 may be for triggering clean up actions at the VNF on receipt of the confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed. The trigger unit 816 may also be for receiving confirmation that the clean up actions have been completed.

The response unit 806 may also comprise a condition unit 810 for attaching a condition to the permission. The response unit 806 may also comprise a repeat unit for attaching a repeat time to a negative response to the request, after which the request may be repeated.

It has been noted above that Virtual Infrastructure Resource allocation adjustments, including modification of resource properties or performance, may have performance impact on VNFs, especially on legacy applications that do not have a cloud technology compliant architecture. Aspects of the present invention provide methods according to which a NFV M&O element asks permission before making an adjustment to resource allocation which will affect a VNF. If permission is granted, the adjustment is made, if permission is not granted, the adjustment is postponed. The permission to perform a resource allocation adjustment is granted or withheld by a VNFM managing the VNF which will be affected by the adjustment. The VNFM may also have the opportunity to delay the adjustment, and or to trigger some preparatory actions in the VNF to mitigate the effects of the adjustment. In this manner, service performance of VNFs may be maintained while resource allocation adjustments are carried out. Aspects of the present invention thus enhance support for transition from Physical Network Function (PNF) to VNF. By enabling a status check on affected VNFs, examples of the present invention provide enhanced support for separation of the infrastructure administrative domain from the tenant administrative domain. Examples of the present invention enable infrastructure operations to automatically consider application specific requirements, contributing to a reduction in both OPEX and CAPEX. It will be appreciated that examples of the present invention conform to the ETSI MANO architecture for virtualisation of telecom applications, and may be incorporated into the standardisation document: "Network Functions Virtualisation (NFV); Management and Orchestration" ETSI GS NFV-MAN 001 V1 .1 .1 (2014-12). The methods of the present invention may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present invention also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A method, performed in a Network Functions Virtualisation Management and Operations, NFV M&O, element, for managing allocation of resources in a Network Functions Virtualisation Infrastructure, NFVI, the method comprising:

establishing a planned resource allocation adjustment;

identifying a Virtualised Network Function Manager, VNFM, managing at least one Virtualised Network Function, VNF, which will be affected by the planned resource allocation adjustment;

requesting permission from the identified VNFM to perform the planned resource allocation adjustment; and

implementing the planned resource allocation adjustment if the requested permission is received.

2. A method as claimed in claim 1 , wherein requesting permission from the identified VNFM to perform the planned resource allocation adjustment comprises preparing an indication of an impact on resource availability for a Virtualisation

Container, on which the VNF managed by the identified VNFM is running, of the planned resource allocation adjustment.

3. A method as claimed in claim 2, wherein requesting permission from the identified VNFM to perform the planned resource allocation adjustment further comprises sending to the VNFM:

an identification of the Virtualisation Container on which the VNF managed by the VNFM is running;

an indication of the type of the resource of the planned resource allocation adjustment; and

the prepared indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment.

4. A method as claimed in any one of the preceding claims, wherein implementing the planned resource allocation adjustment comprises instructing the NFVI to perform the planned resource allocation adjustment.

5. A method as claimed in any one of the preceding claims, further comprising, if the requested permission is received, receiving a message from the identified VNFM indicating that the affected VNF is preparing for the planned resource allocation adjustment.

6. A method as claimed in any one of the preceding claims, further comprising, if the requested permission is received, receiving confirmation that the planned resource allocation adjustment has been completed following implementation of the planned resource allocation adjustment.

7. A method as claimed in any one of the preceding claims, further comprising, if the requested permission is received, informing the identified VNFM that the planned resource allocation adjustment has been completed.

8. A method as claimed in any one of the preceding claims, further comprising, if the requested permission is received, checking for a condition attached to the permission, and, if a condition is attached to the permission, waiting for fulfilment of the condition before implementing the planned resource allocation adjustment.

9. A method as claimed in any one of the preceding claims, further comprising, if the requested permission is not received, repeating, after expiry of a repeat time period, the step of requesting permission from the identified VNFM to perform the planned resource allocation adjustment.

10. A method as claimed in any one of the preceding claims, wherein the NFV M&O element comprises a Virtualised Infrastructure Manager, VIM.

1 1 . A method as claimed in any one of claims 1 to 9, wherein the NFV M&O element comprises a Network Function Virtualisation Orchestrator, NFVO.

12. A method, performed in a Virtualised Network Function Manager, VNFM, for managing a Virtualised Network Function, VNF, that consumes resources in a Network Functions Virtualisation Infrastructure, NFVI, which resources are allocated to the VNF, the method comprising:

receiving, from a Network Functions Virtualisation Management and Operations, NFV M&O, element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM;

checking an operational status of the VNF; and responding to the request on the basis of the operational status of the VNF.

13. A method as claimed in claim 12, wherein responding to the request on the basis of the operational status of the VNF comprises:

establishing a response on the basis of the operational status of the VNF; and sending the response to the NFV M&O element.

14. A method as claimed in claim13, further comprising sending the response to the NFV M&O element if the response comprises granting the requested permission.

15. A method as claimed in any one of claims 12 to 14, wherein receiving a request for permission to perform the planned resource allocation adjustment comprises receiving from the NFV M&O element:

an identification of a Virtualisation Container on which the VNF is running;

an indication of an impact on resource availability for the Virtualisation Container of the planned resource allocation adjustment.

16. A method as claimed in any one of claims 12 to 15, wherein checking an operational status of the VNF comprises requesting operational status information for the VNF.

17. A method as claimed in claim 16, wherein requesting operational status information for the VNF comprises sending a request for operational status information of the VNF to an Element Manager, EM, associated with the VNF.

18. A method as claimed in claim 16 or 17, wherein checking an operational status of the VNF further comprises receiving operational status information for the VNF.

19. A method as claimed in claim 18, wherein operational status information comprises at least one of:

operational status information for the entire VNF;

operational status information for individual components of the VNF;

operational status information for individual component instances of the VNF.

20. A method as claimed in any one of claims 16 to 19, wherein responding to the request comprises determining, on the basis of the operational status information for the VNF, whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level.

21 . A method as claimed in claim 20, when dependent upon claim 19, wherein, if the operational status information comprises operational status information for individual components or component instances of the VNF, responding to the request comprises establishing a component response for each component or component instance of the VNF and aggregating the component responses to form a complete function response for the VNF.

22. A method as claimed in any one of claims 12 to 15, wherein checking an operational status of the VNF comprises requesting whether the VNF can

accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level.

23. A method as claimed in claim 22, wherein requesting whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level comprises sending a request to an EM associated with the VNF.

24. A method as claimed in claim 22 or 23, wherein responding to the request for permission to perform a planned resource allocation adjustment comprises receiving an indication as to whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level.

25. A method as claimed in claim 23, wherein responding to the request for permission to perform a planned resource allocation adjustment comprises at least one of:

receiving a component indication for each component or component instance of the VNF and aggregating the component responses to form a complete function indication for the VNF, or

receiving a complete function indication for the VNF.

26. A method as claimed in any one of claims 12 to 25, further comprising, if responding to the request comprises granting permission, triggering preparatory actions in the VNF.

27. A method as claimed in claim 26, wherein triggering preparatory actions in the VNF comprises sending a trigger message to a VNF or to an EM associated with the VNF.

28. A method as claimed in claim 26 or 27, wherein the preparatory actions comprise VNF level operational procedures to mitigate the impact of the planned resource allocation adjustment.

29. A method as claimed in any one of claims 26 to 28, further comprising informing the NFV M&O element that preparatory actions are taking place in the VNF.

30. A method as claimed in any one of claims 26 to 29, further comprising receiving confirmation that the triggered preparatory actions have been completed, and, on receipt of the confirmation, sending the established response to the NFV M&O element.

31 . A method as claimed in any one of claims 12 to 30, further comprising receiving confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed.

32. A method as claimed in claim 31 , further comprising, on receipt of the confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed, triggering clean up actions at the VNF.

33. A method as claimed in claim 32, further comprising receiving confirmation that the clean up actions have been completed.

34. A method as claimed in any one of claims 12 to 33, wherein responding to the request for permission to perform a planned resource allocation adjustment by granting permission comprises attaching a condition to the permission.

35. A method as claimed in any one of claims 12 to 34, wherein refusing the request for permission to perform a planned resource allocation adjustment comprises attaching a repeat time to a negative response to the request, after which the request may be repeated.

36. A method as claimed in any one of claims 12 to 35, wherein the NFV M&O element comprises a Virtualised Infrastructure Manager, VIM.

37. A method as claimed in any one of claims 12 to 35, wherein the NFV M&O element comprises a Network Function Virtualisation Orchestrator, NFVO.

38. A computer program configured, when run on a computer, to carry out a method according to any one of the preceding claims.

39. A computer program product comprising computer readable media having stored thereon a computer program as claimed in claim 38.

40. A Network Functions Virtualisation Management and Operations, NFV M&O, element for managing allocation of resources in a Network Functions Virtualisation Infrastructure, NFVI, the NFV M&O element comprising a processor and a memory, the memory containing instructions executable by the processor such that the NFV M&O element is operative to:

establish a planned resource allocation adjustment;

identify a Virtualised Network Function Manager, VNFM, managing at least one Virtualised Network Function, VNF, which will be affected by the planned resource allocation adjustment;

request permission from the identified VNFM to perform the planned resource allocation adjustment; and

implement the planned resource allocation adjustment if the requested permission is received.

41 . A NFV M&O element as claimed in claim 40, wherein the NFV M&O element is further operative to request permission from the identified VNFM to perform the planned resource allocation adjustment by preparing an indication of an impact on resource availability for a Virtualisation Container, on which the VNF managed by the identified VNFM is running, of the planned resource allocation adjustment.

42. A NFV M&O element as claimed in claim 41 , wherein the NFV M&O element is further operative to request permission from the identified VNFM to perform the planned resource allocation adjustment by sending to the VNFM:

an identification of the Virtualisation Container on which the VNF managed by the

VNFM is running;

43. A NFV M&O element as claimed in any one of claims 40 to 42, wherein the NFV M&O element is further operative to, if the requested permission is received, check for a condition attached to the permission, and, if a condition is attached to the permission, wait for fulfilment of the condition before implementing the planned resource allocation adjustment.

44. A NFV M&O element as claimed in any one of claims 40 to 43, wherein the NFV M&O element is further operative to, if the requested permission is not received, repeat, after expiry of a repeat time period, the step of requesting permission from the identified VNFM to perform the planned resource allocation adjustment.

45. A Virtualised Network Function Manager, VNFM, for managing a Virtualised Network Function, VNF, that consumes resources in a Network Functions

Virtualisation Infrastructure, NFVI, which resources are allocated to the VNF, the VNFM comprising a processor and a memory, the memory containing instructions executable by the processor such that the VNFM is operative to:

receive, from a Network Functions Virtualisation Management and Operations, NFV M&O, element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM;

check an operational status of the VNF; and

respond to the request on the basis of the operational status of the VNF.

46. A VNFM as claimed in claim 45, wherein the VNFM is further operative to check an operational status of the VNF by requesting operational status information for the

VNF.

47. A VNFM as claimed in claim 45, wherein the VNFM is further operative to check an operational status of the VNF by requesting whether the VNF can accommodate the planned resource allocation adjustment without a reduction in service level of the VNF that exceeds a threshold level.

48. A VNFM as claimed in any one of claims 45 to 47, wherein the VNFM is further operative to, if responding to the request comprises granting permission, trigger preparatory actions in the VNF.

49. A VNFM as claimed in any one of claims 45 to 48, wherein the VNFM is further operative to receive confirmation from the NFV M&O element that the planned resource allocation adjustment has been completed, and, on receipt of the

confirmation, to trigger clean up actions at the VNF.

50. A Network Functions Virtualisation Management and Operations, NFV M&O, element, for managing allocation of resources in a Network Functions Virtualisation Infrastructure, NFVI, the NFV M&O element comprising:

a resource unit for establishing a planned resource allocation adjustment;

an identifying unit for identifying a Virtualised Network Function Manager, VNFM, managing at least one Virtualised Network Function, VNF, which will be affected by the planned resource allocation adjustment;

a permission unit for requesting permission from the identified VNFM to perform the planned resource allocation adjustment; and

an implementation unit for implementing the planned resource allocation adjustment if the requested permission is received.

51 . A Virtualised Network Function Manager, VNFM, for managing a Virtualised Network Function, VNF, that consumes resources in a Network Functions Virtualisation Infrastructure, NFVI, which resources are allocated to the VNF, the VNFM comprising: a receiving unit for receiving, from a Network Functions Virtualisation

Management and Operations, NFV M&O, element, a request for permission to perform a planned resource allocation adjustment which will affect the VNF managed by the VNFM;

a status unit for checking an operational status of the VNF; and a response unit for responding to the request on the basis of the operational status of the VNF.