CN115695199A - Instance updating method, device and storage medium for network function virtualization - Google Patents

Abstract

The application discloses a method, equipment and storage medium for updating a network function virtualization instance. The method comprises the following steps: a Network Function Virtualization Orchestrator (NFVO) obtains an update request to update an instance of Network Function Virtualization (NFV); updating the request based on a newly added first interface update instance between the NFVO and a Virtual Network Function Manager (VNFM); wherein the instance is a VNF instance or an NS instance. The VNF instance or the NF instance may be updated based on the newly added first interface between the NFVO and the VNFM, so that the deployed VNF instance and/or the NS instance may be dynamically updated based on the service requirement, which may reduce operation and maintenance complexity and workload caused by a conventional method of deleting an existing VNF instance and re-creating a new VNF instance, improve operation and maintenance efficiency, and enhance dynamic iteration capability of the VNF instance.

Description

Instance update method, device and storage medium of network function virtualization

technical field

The present application relates to the field of communication technologies, and in particular to a method, device, device and storage medium for updating instances of Network Function Virtualization (Network Function Virtualization, NFV).

Background technique

Traditional network equipment is customized based on specific specification equipment and specific technical requirements. The maintenance and update process of network equipment is relatively complicated, and the operation cost of business promotion is relatively high. In order to reduce the complexity and cost of network deployment and service promotion, the decoupling of software and hardware based on a common hardware platform can effectively reduce the cost of equipment upgrades and accelerate the deployment of new services. Therefore, NFV, which implements the functions of dedicated network element devices in the network, is gradually being applied.

After NFV introduces software-defined network (Software Defined Network, SDN) technology, the deployment and management of virtualized network function (virtualized network function, VNF) tends to be automated. For example, an SDN controller (SDN Controller, SDN-C) can issue instructions to related virtual devices to implement operational requirements such as VNF instantiation and capacity expansion and contraction. In the SDN scenario, the MANO (NFV management and orchestration, NFV management orchestration) system defines the concept of Network Service (NS). An NS instance serves a specific network. As shown in Figure 1, each NS instance can contain one or more VNF instances, as well as the virtual link (Virtual Link, VL) and network connectivity required for communication and interaction between VNF instances. resource.

In the network cloud, when the created VNF instances are based on business requirements and need to be adjusted in terms of network and resources, in related technologies, it is often necessary to adopt the method of "deleting existing VNF instances and recreating new VNF instances based on requirements". Realize the updating of network elements. However, the newly created VNF instance needs to be reconnected with the VNF instance or network management system interacting with the surroundings, and the project is more complicated and the cycle is longer.

Contents of the invention

In view of this, the embodiments of the present application provide a NFV instance update method, device, device, and storage medium, aiming at dynamically updating deployed VNF instances and/or NS instances based on service requirements.

The technical scheme of the embodiment of the application is realized in this way:

In the first aspect, the embodiment of the present application provides a method for updating an instance of network function virtualization, including:

A network function virtualization orchestrator (network function virtualization orchestrator, NFVO) obtains an update request for updating an instance of network function virtualization (NFV);

updating the instance based on the first interface newly added between the NFVO and a virtualized network function manager (virtualized network function manager, VNFM) for the update request;

Wherein, the instance is a VNF instance or an NS instance.

In the above solution, the update request is a first request for updating a VNF instance, and correspondingly, updating the instance based on the newly added first interface between the NFVO and VNFM includes:

For the first request, the NFVO sends a query request of the VNF instance to the VNFM based on a second interface;

The NFVO receives the query result returned by the VNFM based on the second interface;

The NFVO updates the changeable parameters of the VNF instance based on the query result;

The NFVO sends information for updating the VNF instance to the VNFM based on the first interface;

The NFVO receives the task identifier for updating the VNF instance returned by the VNFM based on the first interface.

In the above scheme, the method also includes:

The VNFM updates the association relationship between the VNF instance, the VNF package identifier and the virtual network function description (virtualized network function Descriptor, VNFD) identifier based on the information of the updated VNF instance;

The VNFM sends the association relationship to the NFVO based on a third interface;

The NFVO associates the VNF instance with the corresponding VNF package ID and VNFD ID based on the association relationship.

In the above scheme, the method also includes:

The VNFM requests resource authorization from the NFVO based on a fourth interface;

The NFVO returns a resource authorization result to the VNFM based on the fourth interface.

In the above scheme, the method also includes:

The VNFM sends a VNF life cycle change notification to the NFVO based on the fifth interface.

In the above solution, the update request is a second request for updating the NS instance, and correspondingly, the updating of the instance based on the newly added first interface between the NFVO and VNFM includes:

For the second request, the NFVO sends a query request of each VNF instance in the NS instance to the VNFM based on a second interface;

The NFVO receives the query result returned by the VNFM based on the second interface;

The NFVO updates the variable parameters of each VNF instance based on the query result;

The NFVO sends information for updating each of the VNF instances to the VNFM based on the first interface;

The NFVO receives, based on the first interface, the task identifier for updating each VNF instance returned by the VNFM.

In the above scheme, the method also includes:

The VNFM updates the association relationship between each VNF instance, the VNF package identifier and the VNFD identifier based on updating the information of each VNF instance;

The VNFM sends the association relationship to the NFVO based on a third interface;

The NFVO associates each VNF instance with a corresponding VNF package identifier and a VNFD identifier based on the association relationship.

In the above scheme, the method also includes:

The VNFM requests resource authorization from the NFVO based on a fourth interface;

The NFVO returns a resource authorization result to the VNFM based on the fourth interface.

In the above scheme, the method also includes:

The VNFM sends a VNF life cycle change notification to the NFVO based on the fifth interface.

In the above scheme, the method also includes:

The NFVO executes at least one of the following based on the updated resources of each of the VNF instances: adding equivalent routes, adding signaling collection rules, deleting equivalent routes, and deleting signaling collection rules;

The NFVO updates the virtual link (VL) and network connectivity resources of the NS instance.

In a second aspect, the embodiment of the present application provides a management and orchestration device for NFV, including: NFVO and VNFM, and the NFVO and the VNFM are configured to execute the steps of the method described in the embodiment of the present application.

In a third aspect, the embodiments of the present application provide a storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method described in the embodiments of the present application are implemented.

The technical solution provided by the embodiment of this application can update the VNF instance or NF instance based on the newly added first interface between NFVO and VNFM, so that the deployed VNF instance and/or NS instance can be dynamically updated based on business requirements , can reduce the operation and maintenance complexity and workload brought by the traditional way of deleting existing VNF instances and recreating new VNF instances, improve operation and maintenance efficiency, and enhance the dynamic iteration capability of VNF instances.

Description of drawings

FIG. 1 is a schematic structural diagram of an NS instance in the related art;

FIG. 2 is a schematic structural diagram of an NFV system in the related art;

Fig. 3 is a schematic flow chart of an example update method of NFV in the embodiment of the present application;

FIG. 4 is a schematic flow diagram of updating a VNF instance in the application embodiment 1 of the present application;

FIG. 5 is a schematic flow chart of NS instance update in the application embodiment 2 of the present application.

Detailed ways

The application will be further described in detail below in conjunction with the accompanying drawings and embodiments.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field to which this application belongs. The terms used herein in the specification of the application are only for the purpose of describing specific embodiments, and are not intended to limit the application.

In related technologies, as shown in Figure 2, the NFV system includes: MANO system, Operations Support System (Operations Support System, OSS), Operation and Maintenance Center (Operation and Maintenance Center, OMC), VNF, NFVI and other functional nodes. Among them, the MANO system includes: NFVO, VNFM, virtualized infrastructure manager (virtualized infrastructure manager, VIM) and SDN controller (SDN Controller, SDN-C).

The main functions of the MANO system include: lifecycle management of network elements, creation of mirror images required by network elements, management of templates and software required by network elements, allocation and management of network resources, etc. Among them, NFVO is responsible for the unified scheduling of resources, creating VNF automatic expansion and contraction policies, and providing specification configuration parameters for VNF instantiation, etc.; VNFM is responsible for VNF life cycle management, such as VNFD analysis and processing, VNF instance initialization and VNF expansion and contraction capacity, etc.; VIM is responsible for the scheduling and management of hardware resources and virtualization resources. After the NFV system introduces the SDN technology, the MANO system can pass the configuration parameters related to the deployment and management of the VNF to the SDN-C, and the SDN-C will issue instructions to the relevant virtual devices of the NFVI, for example, SDN Gateway (SDN Gateway), vSwich (virtual switch), etc., to achieve operational requirements such as VNF instantiation, expansion and contraction.

In the ETSI (European Telecommunications Standards Institute, European Telecommunications Standards Institute) NFV-IFA working group, three types of operations, Change current VNF package, Modify VNF Information, and Change VNF Flavor, are proposed for updating VNF instances, as follows:

1), Change current VNF package operation: used to switch the VNF package on which the VNF instance is based, and realize the software upgrade of the VNF instance

2), Modify VNF Information operation: used to update the relevant information of the VNF instance

3). Change VNF Flavor operation: it is used to switch the deployment template (deployment flavor, DF) on which the VNF instance is based, so as to update the resources of the VNF instance.

For the Change current VNF package operation, this operation is mainly used to update the software of the VNF instance. However, in the VNF instance update scenario, most of the changes are made to the internal network information and virtual resources of the VNF instance, and this operation does not include the required scenarios.

For the Modify VNF Information operation, this operation is mainly used to change the VNF instance information, and the VNFM notifies the NFVO of whether the information is successfully modified. However, in the current network operation of the network cloud, from the perspective of stability and security, the relevant information parameters of the VNF instance need to be fully designed in the planning stage to determine which parameters are modifiable and which parameters need to be kept from the created value. Change. In ETSI-NFV, this operation does not start from the actual operation and maintenance of the live network, and defines and restricts the modifiability of the VNF instance information parameters.

For the Change VNF Flavor operation, because the VNF package implementation of most network cloud manufacturers only contains one VNFD file, and each VNFD file only contains one deployment specification DF file, it is impossible to switch between different DF files in the same VNFD file , so this operation cannot be successfully introduced into the network cloud product.

Based on this, in various embodiments of the present application, based on the newly added first interface between NFVO and VNFM for updating VNF instances, service-based Dynamic update of requirements can effectively avoid the operation and maintenance complexity and workload brought by the traditional VNF update method of "deleting existing VNF instances and recreating new VNF instances based on requirements", improve operation and maintenance efficiency, and enhance VNF The dynamic iteration capability of the instance.

Before describing the example update method of NFV in the embodiment of the present application, the interface (Or-vnfm) between NFVO and VNFM in the NFV system of the embodiment of the present application is introduced. The interface between NFVO and VNFM includes: the newly added An interface and the second interface, the third interface, the fourth interface and the fifth interface with enhanced functions. Among them, the first interface is used to update the VNF instance, that is, the UpdateVNF interface; the second interface is used to query VNFD information, that is, the QueryVNFD interface; the third interface is used for VNFM event notification, that is, the VNFMEventNotification interface; the fourth interface is used for resource authorization, That is, the GrantLifecycle interface; the fifth interface is used for VNF instance life cycle change notification, that is, the VNFLifecycleChangesNotification interface.

It should be noted that each interface can be defined based on the interface access method and parameter body, wherein the parameter body is used to define the access direction, parameters and related descriptions, parameter positions, and so on.

Next, exemplarily define the aforementioned interfaces as follows:

1), the first interface: UpdateVNF interface

Interface access method of the first interface: PUT/v4/vnfs/{vnfInstanceID}/update

The parameter body of the first interface is shown in Table 1 below:

Table 1

It can be understood that, based on the first interface, NFVO sends information to VNFM to update the VNF instance, such as the mandatory parameters, conditional mandatory parameters and optional parameters listed in Table 1, wherein the mandatory parameters may include: VNF instance identifier , NFVO logo, VNFM logo, VIM logo, update information, VNFD version, VNFD manufacturer, VNFD logo, deployment specification, input parameter list, input parameter name, input parameter type, input parameter description and parameter value, optional parameters can include : Enter the default value of the parameter and the VNF extended parameter. The conditional mandatory parameter can include: the external network information that must be selected in the NS scenario.

It can be understood that, after the VNFM creates a job based on the information of the updated VNF instance, it may return a job identifier (JobID) to the NFVO based on the first interface.

2), the second interface: QueryVNFD interface

The interface access method of the second interface is as follows:

GET /v4/vnfds/{packageID}{? NFVOID&VNFMID}

The parameter body of the second interface is shown in Table 2 below:

Table 2

Among them, the packageID parameter: used to identify the VNF package queried this time. During the VNF update process:

a), if the VNF package has not changed, the packageID is still the ID of the original VNF package;

b) If the VNF package changes, it needs to be the ID of the new VNF package.

modifiable parameter: This parameter is defined in VNFD, parsed and processed by VNFM and returned to NFVO, identifying which Inputs parameter values in the corresponding VNF instance can be changed.

In the operation process of VNF instantiation and VNF update life cycle, NFVO will call the QueryVNFD interface, but NFVO handles the modifiable parameters in this interface differently:

a) In the VNF instantiation process: NFVO does not need to process the modifiable field;

b) In the VNF instance update process: if the value of the modifiable parameter returned by VNFM is false, it means that the corresponding Inputs parameter is not allowed to be modified; if the value of the modifiable parameter returned by VNFM is true or the parameter is not returned, it means that the corresponding Inputs parameter is not allowed Modifications are allowed.

3), the third interface: VNFMEventNotification interface

The interface access method of the third interface is as follows:

POST /v4/vnfs/eventnotification

The parameter body of the third interface is shown in Table 3 below:

table 3

Among them, the EventType parameter: the new event type "update".

PackageID and deployflavorid parameters: If the VNF package and deployment template DF are changed during the VNF update operation, these two fields are the changed package ID and DF ID. VNFM carries these two fields through the VNFMEventNotification interface, and informs NFVO of the change information of the association relationship between VNF package/DF and VNF instance, and NFVO completes the change of association relationship based on this information.

4), the fourth interface: GrantLifecycle interface

The interface access method of the fourth interface is as follows:

PUT /v4/resource/grant

The parameter body of the fourth interface is shown in Table 4 below:

Table 4

Among them, OperationRight parameter: This parameter indicates the resource change operation authority applied by VNFM to NFVO, including increase, decrease and coverage. Wherein "overwrite" means that the virtual resource of the target VNF instance is used to overwrite the existing VNF instance resource. For the VNF update operation, since the operation process may include three scenarios of "resource increase, resource decrease, and both increase and decrease", in this complex scenario, use "OperationRight=override" to indicate this scenario when authorizing .

OperationType parameter: This parameter indicates the life cycle operation type applied by VNFM to NFVO, including instantiation, automatic expansion and contraction, manual expansion and contraction, update, and termination. Where "update" indicates the VNF instance update operation.

VMList: In the VNF update scenario, since VMs are added and VMs are decreased at the same time, the full amount of virtual resource information of the target VNF instance is returned here.

5), the fifth interface: VNFLifecycleChangesNotification interface

The interface access method of the fifth interface is as follows:

POST /v4/vnfs/lifecyclechangesnotification

The parameter body of the fifth interface is shown in Table 5 below:

table 5

In combination with the above newly added and enhanced interfaces, the method for updating an NFV instance in the embodiment of the present application will be described next.

As shown in Figure 3, the embodiment of the present application provides an NFV instance update method, including:

In step 301, the NFVO obtains an update request for updating an NFV instance.

Step 302, update the instance based on the newly added first interface between the NFVO and the VNFM for the update request.

Here, the instance to be updated may be a deployed VNF instance or NS instance in the live network.

Here, the update request acquired by the NFVO may be triggered by the operator selecting the VNF instance or NS instance to be updated.

It can be understood that, based on the newly added first interface between NFVO and VNFM, the VNF instance or NF instance can be updated, so that the deployed VNF instance and/or NS instance can be dynamically updated based on business requirements, which can reduce the traditional Based on the operation and maintenance complexity and workload brought by deleting the existing VNF instance and recreating a new VNF instance, the operation and maintenance efficiency is improved, and the dynamic iteration capability of the VNF instance is enhanced.

In some embodiments, the update request is the first request for updating the VNF instance. Correspondingly, the update request is based on the newly added first interface between NFVO and VNFM to update the instance, including:

For the first request, the NFVO sends a query request of the VNF instance to the VNFM based on the second interface;

NFVO receives the query result returned by VNFM based on the second interface;

NFVO updates the changeable parameters of the VNF instance based on the query results;

The NFVO sends information to update the VNF instance to the VNFM based on the first interface;

The NFVO receives the task identifier of updating the VNF instance returned by the VNFM based on the first interface.

It can be understood that the NFVO queries the VNFD of the VNF instance to be updated based on the second interface, the query request carries the VNF instance identifier to be updated, and the query result returned by the VNFM includes a parameter indicating whether the Inputs parameter is allowed to be changed (that is, the modifiable parameter) , so as to indicate to the operator the changeable parameters in the VNF instance to be updated, and the operator can select the parameter to be changed and input the corresponding parameter value. Correspondingly, the information for updating the VNF instance sent by the NFVO to the VNFM based on the first interface may include: the above-mentioned changed parameters. In this way, the update of VNF instances with a smaller granularity can be satisfied. For example, the VM specification (computing/storage) remains unchanged, and relevant parameters in Vdu/VduProfile/VLProfile need to be adjusted. For example, for a certain VDU type, the VNF instance supports the creation of the maximum number of VMs of this type, so as to better meet the dynamic adjustment capability of the VNF instance.

Exemplarily, the method also includes:

The VNFM updates the association relationship between the VNF instance, the VNF package identifier and the VNFD identifier based on the updated information of the VNF instance;

VNFM sends the association relationship to NFVO based on the third interface;

NFVO associates the VNF instance with the corresponding VNF package identifier and VNFD identifier based on the association relationship.

It is understandable that the event type "Update" is added to the EventType parameter of the third interface. During the VNF update operation, if there is a change in the VNF package and deployment template (DF), these two fields are the changed package ID and DF ID. VNFM carries these two fields through the VNFMEventNotification interface, and informs NFVO of the change information of the association relationship between VNF package/DF and VNF instance, and NFVO completes the change of association relationship based on this information.

Exemplarily, the method further includes:

VNFM requests resource authorization from NFVO based on the fourth interface;

The NFVO returns a resource authorization result to the VNFM based on the fourth interface.

It can be understood that the resource change operation authority applied by VNFM to NFVO may include: increase, decrease, and coverage, among which "coverage" can meet the resource change requirements of complex scenarios.

Exemplarily, the method further includes:

The VNFM sends a VNF life cycle change notification to the NFVO based on the fifth interface.

It can be understood that VNFM adds the type of "VNF update" based on the event type (EventType) sent by the fifth interface, and in the VNF update scenario, if there is an increase and decrease of VMs at the same time, all VM information, including port information, will be reported ; If there is only an increase or decrease of VMs, report the changed VM information, including port information. In this way, the operator can see the VNF update results on the NFVO interface.

In some embodiments, the update request is a second request for updating the NS instance. Correspondingly, the update request is based on the newly added first interface between NFVO and VNFM to update the instance, including:

For the second request, the NFVO sends the query request of each VNF instance in the NS instance to the VNFM based on the second interface;

NFVO receives the query result returned by VNFM based on the second interface;

NFVO updates the changeable parameters of each VNF instance based on the query results;

NFVO sends information to update each VNF instance to VNFM based on the first interface;

Based on the first interface, the NFVO receives the task identifiers for updating each VNF instance returned by the VNFM.

Exemplarily, the method further includes:

The VNFM updates the association relationship between each VNF instance and the VNF package identifier and the VNFD identifier based on the updated information of each VNF instance;

VNFM sends the association relationship to NFVO based on the third interface;

NFVO associates each VNF instance with the corresponding VNF package identifier and VNFD identifier based on the association relationship.

Exemplarily, the method further includes:

VNFM requests resource authorization from NFVO based on the fourth interface;

The NFVO returns a resource authorization result to the VNFM based on the fourth interface.

Exemplarily, the method further includes:

The VNFM sends a VNF life cycle change notification to the NFVO based on the fifth interface.

Exemplarily, the method further includes:

NFVO executes at least one of the following based on the updated resources of each VNF instance: adding equivalent routes, adding signaling collection rules, deleting equivalent routes, and deleting signaling collection rules;

NFVO updates the virtual link (VL) and network connectivity resources of the NS instance.

It should be noted that for NS instance update, each VNF instance in the NS instance can be updated cyclically, and based on the updated resources of each VNF instance, the virtual link and network connectivity resources of the NS instance can be updated, for example, BGP Neighbor (border gateway protocol neighbor), ExRoute, etc. After the update of the NS instance is completed, the operator can see the update result of the NS instance on the NFVO interface.

The present application will be further described in detail below in conjunction with application examples.

Application Example 1

As shown in Figure 4, this application embodiment illustrates the end-to-end process of the VNF update life cycle operation, which may include:

Step 4001, trigger a VNF instance update operation.

Here, the operator can select a VNF instance, and select the required VNF package based on business requirements, and trigger the VNF update operation.

It should be noted that before performing the VNF instance update operation, if the VNF package needs to be changed, the new VNF package can be uploaded to the NFVO. In addition, if necessary, the business can be migrated in advance.

Step 4002, query VNFD information based on the second interface, and obtain updatable parameters.

Here, NFVO can query the Inputs parameters that need to be filled based on the QueryVNFD interface.

Step 4003, return query result.

Here, VNFM returns the query result to NFVO.

Step 4004, the operator selects the parameter to be changed, and inputs the corresponding parameter value.

Here, the operator selects the VNF instance on the NFVO interface to change the parameters, and inputs the changed parameter values.

Step 4005, parameter validity check.

Here, NFVO checks the validity of the parameters.

Step 4006: Send information for updating the VNF instance based on the first interface.

Here, NFVO updates VNF instance resources based on the UpdateVNF interface, including virtual resources and network resources of VNF instances.

Step 4007, return the task ID.

Here, VNFM returns the Job ID of the VNF instance update operation.

Step 4008, analyzing required resource changes.

Here, VNFM analyzes the required resource changes based on the old and new VNFD information and Inputs parameters.

Step 4009, associating the VNF instance with the new VNF package ID and VNFD ID.

Step 4010, send the association relationship based on the third interface.

Here, based on the VNFMEventNotification interface, the VNFM notifies the NFVO of the update of the association relationship.

Step 4011, associating the VNF instance with the corresponding VNF package ID and VNFD ID.

Here, the NFVO associates the VNF instance with the corresponding VNF package ID and VNFD ID based on the updated association relationship.

Step 4012, request resource authorization based on the fourth interface.

Here, when there is a change in the virtual resource, VNFM requests resource authorization based on the GrantLifecycle interface.

Step 4013, return the resource authorization result based on the fourth interface.

Here, NFVO returns the resource authorization result based on the GrantLifecycle interface.

Step 4014, the VNF updates the pre-notification and response.

Here, the VNFM notifies the VNF and the OMC, and obtains a response.

Step 4015, in indirect mode, update the network resources of the VNF virtual resource set.

Step 4016, VIM detects resource changes, and notifies resource changes.

Here, when there is a change in the virtual resource, the VIM detects the resource change and notifies the NFVO of the resource change.

Step 4017, NFVO returns a response.

Step 4018, updating VNF deployment parameters.

Here, the VNFM updates the VNF deployment parameters.

Step 4019: Send a VNF life cycle change notification based on the fifth interface.

Here, VNFM calls the VNFLifecycleChangesNotification interface to send VNF lifecycle change notifications to NFVO.

Step 4020, NFVO returns a response.

In step 4021, the VNFM sends a VNF update result notification to the OMC, and the OMC returns a response.

Step 4022, VNF update result notification.

Here, the operator can see the update result of the VNF instance on the NFVO interface.

Application Example 2

Step 5001, trigger NS instance update operation.

Here, the operator can select an NS instance and an NSD (Network Service Description) to trigger an NS instance update operation, wherein the NSD is a conditional selection.

It should be noted that before performing the NS instance update operation, the target NSD of the NS instance to be updated and the required VNF package can be uploaded to the NFVO.

Step 5002, check the validity of NS instance update.

Here, NFVO checks the validity of NS instance update.

Step 5003, query VNFD information based on the second interface, and obtain updatable parameters.

Here, NFVO can query the Inputs parameters that need to be filled in by each VNF instance in the NS instance to be updated based on the QueryVNFD interface.

Step 5004, return query result.

Here, VNFM returns the query result to NFVO.

Step 5005, the operator selects the parameter to be changed, and inputs the corresponding parameter value.

Here, the operator selects the VNF instance on the NFVO interface to change the parameters, and inputs the changed parameter values.

Step 5006, parameter validity check.

Here, NFVO checks the validity of the parameters.

Step 5007: Send the information for updating the VNF instance based on the first interface.

Here, NFVO updates VNF instance resources based on the UpdateVNF interface, including virtual resources and network resources of VNF instances.

Step 5008, return the task ID.

Here, VNFM returns the Job ID of the VNF instance update operation.

Step 5009, analyzing required resource changes.

Here, VNFM analyzes the required resource changes based on the old and new VNFD information and Inputs parameters.

Step 5010, associating the VNF instance with the new VNF package ID and VNFD ID.

Step 5011, send the association relationship based on the third interface.

Here, based on the VNFMEventNotification interface, the VNFM notifies the NFVO of the update of the association relationship.

Step 5012, associating the VNF instance with the corresponding VNF package ID and VNFD ID.

Here, the NFVO associates the VNF instance with the corresponding VNF package ID and VNFD ID based on the updated association relationship.

Step 5013, request resource authorization based on the fourth interface.

Here, when there is a change in the virtual resource, VNFM requests resource authorization based on the GrantLifecycle interface.

Step 5014, return the resource authorization result based on the fourth interface.

Here, NFVO returns the resource authorization result based on the GrantLifecycle interface.

Step 5015, the VNF updates the pre-notification and response.

Here, the VNFM notifies the VNF and the OMC, and obtains a response.

Step 5016, in indirect mode, update the network resources of the VNF virtual resource set.

Step 5017, VIM detects resource changes, and notifies resource changes.

Here, when there is a change in the virtual resource, the VIM detects the resource change and notifies the NFVO of the resource change.

Step 5018, NFVO returns a response.

Step 5019, updating VNF deployment parameters.

Here, the VNFM updates the VNF deployment parameters.

Step 5020, send a VNF life cycle change notification based on the fifth interface.

Here, VNFM calls the VNFLifecycleChangesNotification interface to send VNF lifecycle change notifications to NFVO.

Step 5021, NFVO returns a response.

In step 5022, the VNFM sends a VNF update result notification to the OMC, and the OMC returns a response.

Step 5023, add an equal-cost route.

Here, based on the updated VNF instance resources, the NFVO can add equal-cost multi-path routing (Equal Cost Multi-path, ECMP).

Step 5024, add a signaling collection rule.

Here, the NFVO can add signaling collection rules (TapFlow) based on the updated VNF instance resources.

Step 5025, delete the equivalent route.

Here, the NFVO can delete the equal-cost multi-path routing (ECMP) based on the updated VNF instance resource.

Step 5026, delete the signaling collection rule.

Here, the NFVO can delete the signaling collection rule (TapFlow) based on the updated VNF instance resource.

It should be noted that, for each VNF instance, the foregoing step 5007 to step 5026 may be executed cyclically, so as to implement updating of each VNF instance in the NS instance.

Step 5027, update VL and network connectivity resources.

Here, virtual links (VL) and network connectivity resources, such as BGP Neighbor (Border Gateway Protocol Neighbor), ExRoute, etc., may be updated based on the updated resources of each VNF instance.

Step 5028, VNF update result notification.

Here, the operator can see the NS instance update result on the NFVO interface.

The embodiment of the present application also provides a NFV management and orchestration device, that is, the MANO system, including: NFVO and VNFM, and the NFVO and the VNFM are configured to execute the steps of the method described in the embodiment of the present application. For details, reference may be made to the description of the foregoing method embodiments, and details are not repeated here.

It can be understood that NFVO and VNFM can be implemented by one or more Application Specific Integrated Circuits (ASIC, Application Specific Integrated Circuit), DSP, Programmable Logic Device (PLD, Programmable Logic Device), Complex Programmable Logic Device (CPLD, Complex Programmable Logic Device), Field Programmable Logic Gate Array (FPGA, Field Programmable Gate Array), general-purpose processor, controller, microcontroller (MCU, Micro Controller Unit), microprocessor (Microprocessor), or other electronic components, used to perform the aforementioned method.

In an exemplary embodiment, the embodiment of the present application also provides a storage medium, that is, a computer storage medium, which may specifically be a computer-readable storage medium, for example, including a memory storing a computer program, and the above-mentioned computer program may be arranged by the NFV management device executed by a processor to complete the steps described in the method in the embodiment of the present application. The computer-readable storage medium can be a read-only memory (ROM, Read Only Memory), a programmable read-only memory (PROM, Programmable Read-Only Memory), an erasable programmable read-only memory (EPROM, Erasable Programmable Read-Only Memory) , Electrically Erasable Programmable Read-Only Memory (EEPROM, Electrically Erasable Programmable Read-Only Memory), flash memory (Flash Memory), magnetic surface memory, optical disk, or CD-ROM and other memories.

It should be noted that: "first", "second", etc. are used to distinguish similar objects, and not necessarily used to describe a specific order or sequence.

In addition, the technical solutions described in the embodiments of the present application may be combined arbitrarily if there is no conflict.

The above is only the specific implementation of the application, but the scope of protection of the application is not limited thereto. Anyone familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the application. Should be covered within the protection scope of this application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (12)

1. An instance updating method for network function virtualization, comprising:

a Network Function Virtualization Orchestrator (NFVO) acquires an update request for updating an instance of a Network Function Virtualization (NFV);

updating the instance for the update request based on a newly added first interface between the NFVO and a Virtual Network Function Manager (VNFM);

wherein the instance is a VNF instance or an NS instance.

2. The method of claim 1, wherein the update request is a first request for updating an instance of a VNF, and wherein the updating the instance based on the newly added first interface between the NFVO and the VNFM according to the update request comprises:

for the first request, the NFVO sending a query request of the VNF instance to the VNFM based on a second interface;

the NFVO receives a query result returned by the VNFM based on the second interface;

the NFVO updating a changeable parameter of the VNF instance based on the query result;

the NFVO sending, to the VNFM, information to update the VNF instance based on the first interface;

the NFVO receives, based on the first interface, a task identifier returned by the VNFM to update the VNF instance.

3. The method of claim 2, further comprising:

the VNFM updates the association relation between the VNF instance and the VNF packet identification and the Virtual Network Function Description (VNFD) identification based on the information of the updated VNF instance;

the VNFM sends the incidence relation to the NFVO based on a third interface;

and the NFVO associates the VNF instance with the corresponding VNF package identification and VNFD identification based on the association relation.

4. The method of claim 3, further comprising:

the VNFM requests resource authorization from the NFVO based on a fourth interface;

the NFVO returns a resource authorization result to the VNFM based on the fourth interface.

5. The method of claim 4, further comprising:

the VNFM sends a VNF lifecycle change notification to the NFVO based on a fifth interface.

6. The method of claim 1, wherein the update request is a second request for updating an instance of an NS, and wherein correspondingly updating the instance based on the newly added first interface between the NFVO and the VNFM comprises:

for the second request, the NFVO sending, to the VNFM, a query request for each VNF instance in the NS instances based on a second interface;

the NFVO receives a query result returned by the VNFM based on the second interface;

the NFVO updates the changeable parameters of each VNF instance based on the query result;

the NFVO sends information for updating each VNF instance to the VNFM based on the first interface;

and the NFVO receives the task identification which is returned by the VNFM and updates each VNF instance based on the first interface.

7. The method of claim 6, further comprising:

the VNFM updates the incidence relation between each VNF instance and the VNF package identification and the VNFD identification based on the information for updating each VNF instance;

the VNFM sends the incidence relation to the NFVO based on a third interface;

and the NFVO associates each VNF instance with a corresponding VNF packet identifier and a corresponding VNFD identifier based on the association relation.

8. The method of claim 7, further comprising:

the VNFM requests resource authorization from the NFVO based on a fourth interface;

the NFVO returns a resource authorization result to the VNFM based on the fourth interface.

9. The method of claim 8, further comprising:

the VNFM sends a VNF lifecycle change notification to the NFVO based on a fifth interface.

10. The method of claim 9, further comprising:

the NFVO executes, based on the updated resources of each VNF instance, at least one of: adding an equivalent route, adding a signaling acquisition rule, deleting the equivalent route and deleting the signaling acquisition rule;

the NFVO updates virtual link VL and network connectivity resources of the NS instance.

11. An NFV management orchestration device, comprising: NFVO and VNFM configured to perform the steps of the method of any one of claims 1 to 10.

12. A storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, performs the steps of the method of any one of claims 1 to 10.

Images