Methods, devices, and storage media for updating instances of network function virtualization

Abstract

This application discloses a method, device, and storage medium for updating Network Functions Virtualization (NFV) instances. The method includes: a Network Functions Virtualization Orchestrator (NFVO) obtaining an update request for updating an NFV instance; updating the instance based on a newly added first interface between the NFVO and the Virtual Network Functions Manager (VNFM); wherein the instance is a VNF instance or an NS instance. Updating the VNF instance or NF instance based on the newly added first interface between the NFVO and VNFM allows for dynamic updates of deployed VNF instances and / or NS instances based on business needs. This reduces the operational complexity and workload associated with traditional methods that involve deleting existing VNF instances and creating new ones, improving operational efficiency and enhancing the dynamic iteration capability of VNF instances.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, device and storage medium for updating instances of Network Function Virtualization (NFV). Background Technology

[0002] Traditional network equipment is customized based on specific specifications and technical requirements, making its maintenance and upgrade processes complex and its operational costs high for service deployment. To reduce the complexity and cost of network deployment and service deployment, a hardware-software decoupling approach based on a general-purpose hardware platform can effectively reduce the costs associated with equipment upgrades and accelerate the deployment of new services. Therefore, NFV (Network Functions Virtualization), which enables the use of dedicated network elements, is gradually being adopted.

[0003] With the introduction of Software Defined Networking (SDN) technology in NFV, the deployment and management of virtualized network functions (VNFs) have become increasingly automated. For example, commands can be issued to relevant virtual devices through the SDN Controller (SDN-C) to achieve operations such as VNF instantiation and scaling. In the SDN scenario, the MANO (NFV management and orchestration) system defines the concept of Network Service (NS). An NS instance represents a specific network service, such as... Figure 1 As shown, each NS instance can contain one or more VNF instances, as well as virtual links (VLs) and network connectivity resources required for communication and interaction between VNF instances.

[0004] In a network cloud, when existing VNF instances require network and resource adjustments based on business needs, the common approach is to "delete the existing VNF instance and create a new one based on the requirements" to update the network elements. However, the newly created VNF instance needs to re-interact with surrounding VNF instances or the network management system, making the process complex and time-consuming. Summary of the Invention

[0005] In view of this, embodiments of this application provide an NFV instance update method, apparatus, device, and storage medium, which are designed to dynamically update deployed VNF instances and / or NS instances based on business needs.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a method for updating an instance of a network function virtualization, including:

[0008] The network function virtualization orchestrator (NFVO) receives update requests that update instances of network function virtualization (NFV).

[0009] The instance is updated based on the newly added first interface between the NFVO and the virtualized network function manager (VNFM) in response to the update request;

[0010] The instance is either a VNF instance or an NS instance.

[0011] In the above scheme, the update request is a first request for updating the VNF instance. Accordingly, updating the instance based on the newly added first interface between the NFVO and VNFM includes:

[0012] In response to the first request, the NFVO sends a query request for the VNF instance to the VNFM based on the second interface;

[0013] The NFVO receives the query results returned by the VNFM based on the second interface;

[0014] The NFVO updates the mutable parameters of the VNF instance based on the query results;

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

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

[0017] The method in the above scheme further includes:

[0018] The VNFM updates the association between the VNF instance and the VNF packet identifier and the virtualized network function descriptor (VNFD) identifier based on the information of the updated VNF instance;

[0019] The VNFM sends the association relationship to the NFVO based on the third interface;

[0020] The NFVO associates the VNF instance with the corresponding VNF packet identifier and VNFD identifier based on the association relationship.

[0021] The method in the above scheme further includes:

[0022] The VNFM requests resource authorization from the NFVO based on the fourth interface;

[0023] The NFVO returns the resource authorization result to the VNFM based on the fourth interface.

[0024] The method in the above scheme further includes:

[0025] The VNFM sends a VNF lifecycle change notification to the NFVO via the fifth interface.

[0026] In the above scheme, the update request is a second request for updating the NS instance. Accordingly, updating the instance based on the newly added first interface between NFVO and VNFM includes:

[0027] In response to the second request, the NFVO sends a query request for each VNF instance in the NS instance to the VNFM based on the second interface;

[0028] The NFVO receives the query results returned by the VNFM based on the second interface;

[0029] The NFVO updates the modifiable parameters of each VNF instance based on the query results;

[0030] The NFVO sends information to the VNFM to update each of the VNF instances based on the first interface;

[0031] The NFVO receives the updated task identifiers of each VNF instance returned by the VNFM based on the first interface.

[0032] The method in the above scheme further includes:

[0033] The VNFM updates the association between each VNF instance and the VNF packet identifier and VNFD identifier based on the updated information of each VNF instance;

[0034] The VNFM sends the association relationship to the NFVO based on the third interface;

[0035] The NFVO associates each VNF instance with its corresponding VNF packet identifier and VNFD identifier based on the association relationship.

[0036] The method in the above scheme further includes:

[0037] The VNFM requests resource authorization from the NFVO based on the fourth interface;

[0038] The NFVO returns the resource authorization result to the VNFM based on the fourth interface.

[0039] The method in the above scheme further includes:

[0040] The VNFM sends a VNF lifecycle change notification to the NFVO via the fifth interface.

[0041] The method in the above scheme further includes:

[0042] Based on the updated resources of each of the VNF instances, the NFVO performs at least one of the following: adding an equal-cost route, adding a signaling collection rule, deleting an equal-cost route, and deleting a signaling collection rule;

[0043] The NFVO updates the Virtual Link (VL) and network connectivity resources of the NS instance.

[0044] Secondly, embodiments of this application provide an NFV management and orchestration device, including: NFVO and VNFM, wherein the NFVO and the VNFM are configured to perform the steps of the method described in embodiments of this application.

[0045] Thirdly, embodiments of this application provide a storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described in embodiments of this application.

[0046] The technical solution provided in this application embodiment can update VNF instances or NF instances based on the newly added first interface between NFVO and VNFM. This allows for dynamic updates of deployed VNF instances and / or NS instances based on business needs, reducing the operational complexity and workload caused by the traditional method of deleting existing VNF instances and recreating new ones, improving operational efficiency, and enhancing the dynamic iteration capability of VNF instances. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the structure of an NS instance in related technologies;

[0048] Figure 2 This is a schematic diagram of the structure of an NFV system in related technologies;

[0049] Figure 3 This is a flowchart illustrating the NFV instance update method according to an embodiment of this application;

[0050] Figure 4This is a schematic diagram illustrating the process of updating a VNF instance in Embodiment 1 of this application;

[0051] Figure 5 This is a schematic diagram of the NS instance update process in Embodiment 2 of this application. Detailed Implementation

[0052] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0053] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0054] In related technologies, such as Figure 2 As shown, the NFV system includes functional nodes such as the MANO system, Operations Support System (OSS), Operation and Maintenance Center (OMC), VNF, and NFVI. The MANO system includes NFVO, VNFM, Virtualized Infrastructure Manager (VIM), and SDN Controller (SDN-C).

[0055] The main functions of the MANO system include: network element lifecycle management, creation of network element images, management of network element templates and software, and allocation and management of network resources. Specifically, NFVO is responsible for unified resource scheduling, creating automatic VNF scaling policies, and providing VNF instantiation configuration parameters; VNFM is responsible for VNF lifecycle management, such as VNFD parsing and processing, VNF instance initialization, and VNF scaling; and VIM is responsible for the scheduling and management of hardware and virtualization resources. After introducing SDN technology into the NFV system, the MANO system can transmit VNF ​​deployment and management configuration parameters to SDN-C, which then issues commands to relevant virtual devices in NFVI, such as SDN Gateway and vSwich, to achieve operations such as VNF instantiation and scaling.

[0056] The ETSI (European Telecommunications Standards Institute) NFV-IFA working group proposed three types of operations for updating VNF instances: Change current VNF ​​package, Modify VNF Information, and Change VNF Flavor, as detailed below:

[0057] 1) Change current VNF ​​package operation: Used to switch the VNF package on which the VNF instance is based, thereby upgrading the VNF instance's software.

[0058] 2) Modify VNF Information operation: Used to update VNF instance information.

[0059] 3) Change VNF Flavor operation: Used to switch the deployment flavor (DF) on which the VNF instance is based, so as to update the VNF instance resources.

[0060] The "Change current VNF ​​package" operation is primarily used for software updates of VNF instances. However, VNF instance updates often involve changes to the internal network information and virtual resources of the VNF instance, and this operation does not cover the required scenarios.

[0061] The "Modify VNF Information" operation is primarily used to change VNF instance information. The VNFM notifies the NFVO whether the modification was successful. However, in live network operations, for stability and security reasons, the relevant parameters of VNF instances need to be comprehensively designed during the planning phase to determine which parameters are modifiable and which should retain their creation values. In ETSI-NFV, this operation does not define or restrict the modifiability of the VNF instance information parameters based on actual live network operations.

[0062] Regarding the Change VNF Flavor operation, since most network cloud vendors' VNF package implementations only contain one VNFD file, and each VNFD file only contains one deployment specification DF file, it is not possible to switch between different DF files within the same VNFD file. Therefore, this operation cannot be successfully introduced into network cloud products.

[0063] Based on this, in various embodiments of this application, the newly added first interface between NFVO and VNFM for updating VNF instances can be used to dynamically update existing VNF instances and / or NS instances based on business needs. This can effectively avoid the operational complexity and workload caused by the traditional VNF update method of "deleting existing VNF instances and creating new VNF instances based on needs", improve operational efficiency, and enhance the dynamic iteration capability of VNF instances.

[0064] Before describing the instance update method of NFV in this application embodiment, the interface (Or-vnfm) between NFVO and VNFM in the NFV system of this application embodiment will be introduced first. The interface between NFVO and VNFM includes: a newly added first interface and enhanced second, third, fourth and fifth interfaces. Among them, the first interface is used for VNF instance updates, i.e., the UpdateVNF interface; the second interface is used for querying VNFD information, i.e., the QueryVNFD interface; the third interface is used for VNFM event notification, i.e., the VNFMEventNotification interface; the fourth interface is used for resource authorization, i.e., the GrantLifecycle interface; and the fifth interface is used for VNF instance lifecycle change notification, i.e., the VNFLifecycleChangesNotification interface.

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

[0066] The aforementioned interfaces are defined as follows:

[0067] 1) First interface: UpdateVNF interface

[0068] The first interface access method is: PUT / v4 / vnfs / {vnfInstanceID} / update

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

[0070] Table 1

[0071]

[0072] It is understandable that NFVO sends information about updating the VNF instance to VNFM based on the first interface, as shown in Table 1, including required parameters, conditionally required parameters, and optional parameters. Required parameters may include: VNF instance identifier, NFVO identifier, VNFM identifier, VIM identifier, update information, VNFD version, VNFD vendor, VNFD identifier, deployment specifications, input parameter list, input parameter name, input parameter type, input parameter description, and parameter value. Optional parameters may include: default values ​​for input parameters and VNF extended parameters. Conditionally required parameters may include: external network information required in NS scenarios.

[0073] Understandably, after VNFM creates a task based on the updated VNF instance information, it can return the task identifier (JobID) to NFVO based on the first interface.

[0074] 2) Second interface: QueryVNFD interface

[0075] The interface access method for the second interface is as follows:

[0076] GET / v4 / vnfds / {packageID}{? NFVOID&VNFMID}

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

[0078] Table 2

[0079]

[0080] The `packageID` parameter identifies the VNF package being queried. In the VNF update process:

[0081] a) If the VNF package has not been changed, the packageID will still be the original VNF package ID;

[0082] b) If the VNF package changes, it must be the ID of the new VNF package.

[0083] The modifiable parameter: This parameter is defined in VNFD, parsed and processed by VNFM and returned to NFVO, and identifies which Inputs parameters in the corresponding VNF instance have modifiable values.

[0084] In both VNF instantiation and VNF update lifecycle operations, NFVO calls the QueryVNFD interface, but NFVO handles the modifiable parameter in this interface differently:

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

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

[0087] 3) Third interface: VNFMEventNotification interface

[0088] The interface access methods for the third interface are as follows:

[0089] POST / v4 / vnfs / eventnotification

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

[0091] Table 3

[0092]

[0093] Among them, the EventType parameter adds the event type "Update".

[0094] PackageID and deployflavorid parameters: If there are changes to the VNF package and deployment template (DF) during the VNF update operation, these two fields will be the changed package ID and DF ID. VNFM uses the VNFMEventNotification interface to carry these two fields to inform NFVO about the changes in the association between the VNF package / DF and the VNF instance. NFVO then completes the association change based on this information.

[0095] 4) Fourth interface: GrantLifecycle interface

[0096] The access methods for the fourth interface are as follows:

[0097] PUT / v4 / resource / grant

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

[0099] Table 4

[0100]

[0101] The OperationRight parameter represents the resource modification operation permissions requested by the VNFM from the NFVO, including adding, reducing, and overwriting. "Overwriting" means using the virtual resources of the target VNF ​​instance to overwrite the existing VNF instance resources. For VNF update operations, since the operation may involve three scenarios: "resource addition," "resource reduction," and "both addition and reduction," in this complex scenario, "OperationRight = Overwrite" is used to represent this scenario during authorization.

[0102] The OperationType parameter indicates the lifecycle operation type requested by the VNFM from the NFVO, including instantiation, autoscaling, manual scaling, update, and termination. "Update" specifically refers to a VNF instance update operation.

[0103] VMList: In VNF update scenarios, since both adding and removing VMs occur simultaneously, this returns the full virtual resource information of the target VNF ​​instance.

[0104] 5) Fifth Interface: VNFLifecycleChangesNotification Interface

[0105] The interface access method for the fifth interface is as follows:

[0106] POST / v4 / vnfs / lifecyclechangesnotification

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

[0108] Table 5

[0109]

[0110] Based on the above-mentioned newly added and enhanced interfaces, the NFV instance update method of this application embodiment will be described next.

[0111] like Figure 3 As shown in the figure, this application embodiment provides an NFV instance update method, including:

[0112] Step 301: NFVO obtains an update request to update the NFV instance.

[0113] Step 302: Update the instance of the update request based on the first newly added interface between NFVO and VNFM.

[0114] Here, the instance that needs to be updated can be a VNF instance or an NS instance that has been deployed in the live network.

[0115] Here, the update request obtained by NFVO can be triggered by the operator selecting a VNF instance or NS instance to be updated.

[0116] Understandably, by using the newly added first interface between NFVO and VNFM to update VNF instances or NF instances, the deployed VNF instances and / or NS instances can be dynamically updated based on business needs. This reduces the operational complexity and workload caused by the traditional method of deleting existing VNF instances and recreating new ones, improves operational efficiency, and enhances the dynamic iteration capability of VNF instances.

[0117] In some embodiments, the update request is a first request for updating a VNF instance. Accordingly, updating the instance based on the newly added first interface between NFVO and VNFM includes:

[0118] In response to the first request, NFVO sends a query request for the VNF instance to VNFM based on the second interface;

[0119] NFVO receives the query results returned by VNFM based on the second interface;

[0120] NFVO updates the mutable parameters of the VNF instance based on the query results;

[0121] NFVO sends information about updating the VNF instance to VNFM based on the first interface;

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

[0123] Understandably, NFVO queries the VNFD of the VNF instance to be updated via the second interface. This query request carries the identifier of the VNF instance to be updated. The query result returned by VNFM includes parameters indicating whether the Inputs parameter can be changed (i.e., modifiable parameters). This allows the operator to select the modifiable parameters in the VNF instance to be updated and input the corresponding parameter values. Correspondingly, the information sent by NFVO to VNFM via the first interface to update the VNF instance can include the aforementioned modified parameters. This allows for updates to VNF instances at a finer granularity. For example, the VM specifications (compute / storage) remain unchanged, but related parameters in Vdu / VduProfile / VLProfile need to be adjusted. For instance, adjusting the maximum number of VMs of a certain VDU type that the VNF instance can support to create, thus better meeting the dynamic adjustment capabilities of VNF instances.

[0124] For example, the method further includes:

[0125] VNFM updates the association between VNF instances and VNF packet identifiers and VNFD identifiers based on the information of the updated VNF instances;

[0126] VNFM sends association relationships to NFVO based on a third interface;

[0127] NFVO associates VNF instances with corresponding VNF packet identifiers and VNFD identifiers based on the association relationship.

[0128] Understandably, the EventType parameter of the third interface has added an "Update" event type. During a VNF update operation, if there are changes to the VNF package and deployment template (DF), then these two fields represent the changed package ID and DF ID. VNFM uses the VNFMEventNotification interface to carry these two fields to inform NFVO about the changes in the association between the VNF package / DF and the VNF instance. NFVO then completes the association change based on this information.

[0129] For example, the method further includes:

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

[0131] NFVO returns the resource authorization result to VNFM based on the fourth interface.

[0132] It is understandable that the resource change operation permissions requested by VNFM from NFVO can include: add, reduce, and overwrite. Among them, "overwrite" can meet the resource change needs of complex scenarios.

[0133] For example, the method further includes:

[0134] VNFM sends VNF lifecycle change notifications to NFVO via the fifth interface.

[0135] Understandably, VNFM adds a "VNF Update" type to the event types sent based on the fifth interface. In a VNF update scenario, if both VMs are added and removed simultaneously, all VM information, including port information, is reported; if only VMs are added or removed, only the changed VM information, including port information, is reported. In this way, operators can see the VNF update results on the NFVO interface.

[0136] In some embodiments, the update request is a second request for updating the NS instance. Accordingly, updating the instance based on the newly added first interface between NFVO and VNFM includes:

[0137] In response to the second request, NFVO sends a query request for each VNF instance in the NS instance to VNFM based on the second interface;

[0138] NFVO receives the query results returned by VNFM based on the second interface;

[0139] NFVO updates the mutable parameters of each VNF instance based on the query results;

[0140] NFVO sends updated information about each VNF instance to VNFM based on the first interface;

[0141] NFVO receives the task identifiers for updating each VNF instance returned by VNFM based on the first interface.

[0142] For example, the method further includes:

[0143] VNFM updates the association between each VNF instance and the VNF packet identifier and VNFD identifier based on the updated information of each VNF instance;

[0144] VNFM sends association relationships to NFVO based on a third interface;

[0145] NFVO associates each VNF instance with its corresponding VNF packet identifier and VNFD identifier based on the association relationship.

[0146] For example, the method further includes:

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

[0148] NFVO returns the resource authorization result to VNFM based on the fourth interface.

[0149] For example, the method further includes:

[0150] VNFM sends VNF lifecycle change notifications to NFVO via the fifth interface.

[0151] For example, the method further includes:

[0152] Based on the updated resources of each VNF instance, NFVO performs at least one of the following: adds an equal-cost route, adds a signaling collection rule, deletes an equal-cost route, and deletes a signaling collection rule;

[0153] NFVO updates the Virtual Link (VL) and network connectivity resources of the NS instance.

[0154] It should be noted that for NS instance updates, each VNF instance within the NS instance can be updated cyclically. Based on the updated resources of each VNF instance, the virtual links and network connectivity resources of the NS instance are also updated, such as BGP Neighbor and ExRoute. After the NS instance update is complete, the operator can view the update results on the NFVO interface.

[0155] The present application will be further described in detail below with reference to application examples.

[0156] Application Example 1

[0157] like Figure 4 As shown in the illustration, this application example demonstrates the end-to-end process of a VNF update lifecycle operation, which may include:

[0158] Step 4001 triggers the VNF instance update operation.

[0159] Here, the operator can select a VNF instance and choose the required VNF package based on business needs to trigger a VNF update operation.

[0160] It should be noted that if the VNF package needs to be changed before performing the VNF instance update operation, the new VNF package can be uploaded to NFVO. Furthermore, if necessary, services can be migrated in advance.

[0161] Step 4002: Query VNFD information based on the second interface to obtain updatable parameters.

[0162] Here, NFVO can use the QueryVNFD interface to query the Inputs parameters that need to be filled in.

[0163] Step 4003: Return the query results.

[0164] Here, VNFM returns the query results to NFVO.

[0165] Step 4004: The operator selects the parameter to be changed and enters the corresponding parameter value.

[0166] Here, the operator selects the VNF instance's modifiable parameters on the NFVO interface and enters the changed parameter values.

[0167] Step 4005: Parameter validity verification.

[0168] Here, NFVO verifies the validity of the parameters.

[0169] Step 4006: Send information to update the VNF instance based on the first interface.

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

[0171] Step 4007: Return to task identifier.

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

[0173] Step 4008: Analyze the required resource changes.

[0174] Here, VNFM analyzes the required resource changes based on the new and old VNFD information and the Inputs parameter.

[0175] Step 4009: Associate the VNF instance with the new VNF package ID and VNFD ID.

[0176] Step 4010: Send the association relationship based on the third interface.

[0177] Here, VNFM uses the VNFMEventNotification interface to notify NFVO of the updated association relationship.

[0178] Step 4011: Associate the VNF instance with the corresponding VNF packet identifier and VNFD identifier.

[0179] Here, NFVO associates VNF instances with corresponding VNF packet identifiers and VNFD identifiers based on the updated association relationships.

[0180] Step 4012: Request resource authorization based on the fourth interface.

[0181] Here, when virtual resources change, VNFM requests resource authorization based on the GrantLifecycle interface.

[0182] Step 4013: Return the resource authorization result based on the fourth interface.

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

[0184] Step 4014, VNF update pre-notification and response.

[0185] Here, VNFM notifies VNF and OMC and receives a response.

[0186] Step 4015, Indirect mode, VNF (Virtual Resource Set) network resource update.

[0187] Step 4016: VIM detects resource changes and notifies the system of resource changes.

[0188] Here, when virtual resources change, VIM detects the resource changes and notifies NFVO of the resource changes.

[0189] Step 4017, NFVO returns a response.

[0190] Step 4018: Update VNF deployment parameters.

[0191] Here, VNFM updates the VNF deployment parameters.

[0192] Step 4019: Send a VNF lifecycle change notification based on the fifth interface.

[0193] Here, VNFM calls the VNFLifecycleChangesNotification interface to send a VNF lifecycle change notification to NFVO.

[0194] Step 4020, NFVO returns a response.

[0195] Step 4021: VNFM sends a VNF update result notification to OMC, and OMC returns a response.

[0196] Step 4022, VNF update result notification.

[0197] Here, the operator can see the VNF instance update results in the NFVO interface.

[0198] Application Example 2

[0199] Step 5001 triggers an NS instance update operation.

[0200] Here, the operator can select the NS instance and NSD (Network Service Description) to trigger an NS instance update operation. The NSD is a required condition.

[0201] 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 NFVO.

[0202] Step 5002: Verify the validity of the NS instance update.

[0203] Here, NFVO verifies the validity of NS instance updates.

[0204] Step 5003: Query VNFD information based on the second interface to obtain updatable parameters.

[0205] Here, NFVO can use the QueryVNFD interface to query the Inputs parameters that each VNF instance in the NS instance to be updated needs to fill in.

[0206] Step 5004: Return the query results.

[0207] Here, VNFM returns the query results to NFVO.

[0208] Step 5005: The operator selects the parameter to be changed and enters the corresponding parameter value.

[0209] Here, the operator selects the VNF instance's modifiable parameters on the NFVO interface and enters the changed parameter values.

[0210] Step 5006: Parameter validity verification.

[0211] Here, NFVO verifies the validity of the parameters.

[0212] Step 5007: Send information to update the VNF instance based on the first interface.

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

[0214] Step 5008: Return to task identifier.

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

[0216] Step 5009: Analyze the required resource changes.

[0217] Here, VNFM analyzes the required resource changes based on the new and old VNFD information and the Inputs parameter.

[0218] Step 5010: Associate the VNF instance with the new VNF package ID and VNFD ID.

[0219] Step 5011: Send the association relationship based on the third interface.

[0220] Here, VNFM uses the VNFMEventNotification interface to notify NFVO of the updated association relationship.

[0221] Step 5012: Associate the VNF instance with the corresponding VNF packet identifier and VNFD identifier.

[0222] Here, NFVO associates VNF instances with corresponding VNF packet identifiers and VNFD identifiers based on the updated association relationships.

[0223] Step 5013: Request resource authorization based on the fourth interface.

[0224] Here, when virtual resources change, VNFM requests resource authorization based on the GrantLifecycle interface.

[0225] Step 5014: Return the resource authorization result based on the fourth interface.

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

[0227] Step 5015, VNF update pre-notification and response.

[0228] Here, VNFM notifies VNF and OMC and receives a response.

[0229] Step 5016, Indirect mode, VNF (Virtual Resource Set) network resource update.

[0230] Step 5017: VIM detects resource changes and notifies the system of resource changes.

[0231] Here, when virtual resources change, VIM detects the resource changes and notifies NFVO of the resource changes.

[0232] Step 5018, NFVO returns a response.

[0233] Step 5019: Update VNF deployment parameters.

[0234] Here, VNFM updates the VNF deployment parameters.

[0235] Step 5020: Send a VNF lifecycle change notification based on the fifth interface.

[0236] Here, VNFM calls the VNFLifecycleChangesNotification interface to send a VNF lifecycle change notification to NFVO.

[0237] Step 5021, NFVO returns a response.

[0238] Step 5022: VNFM sends a VNF update result notification to OMC, and OMC returns a response.

[0239] Step 5023: Add an equal-cost route.

[0240] Here, NFVO can add Equal Cost Multi-path (ECMP) routes based on the updated VNF instance resources.

[0241] Step 5024: Add signaling collection rules.

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

[0243] Step 5025: Delete the equivalent route.

[0244] Here, NFVO can delete Equal Cost Multipath (ECMP) routes based on the updated VNF instance resources.

[0245] Step 5026: Delete the signaling collection rule.

[0246] Here, NFVO can delete signaling collection rules (TapFlow) based on the updated VNF instance resources.

[0247] It should be noted that for each VNF instance, steps 5007 to 5026 can be executed repeatedly to update each VNF instance in the NS instance.

[0248] Step 5027: Update VL and network connectivity resources.

[0249] Here, virtual links (VLs) and network connectivity resources, such as BGP Neighbor and ExRoute, can be updated based on the updated resources of each VNF instance.

[0250] Step 5028, VNF update result notification.

[0251] Here, the operator can see the NS instance update results in the NFVO interface.

[0252] This application also provides an NFV management and orchestration device, namely a MANO system, including: NFVO and VNFM, wherein NFVO and VNFM are configured to perform the steps of the method described in this application embodiment. For details, please refer to the description of the foregoing method embodiments, which will not be repeated here.

[0253] It is understood that NFVO and VNFM can be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned methods.

[0254] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory that stores a computer program. This computer program can be executed by a processor of an NFV management and orchestration device to complete the steps described in the method of this application embodiment. The computer-readable storage medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disc, or a CD-ROM, etc.

[0255] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0256] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0257] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for updating instances of Network Functions Virtualization, characterized in that, include: The Network Functions Virtualization Orchestrator (NFVO) receives update requests that update instances of Network Functions Virtualization (NFV). The update request updates the instance based on the newly added first interface between the NFVO and the Virtual Network Function Manager (VNFM); Wherein, the instance is an NS instance, and the parameter body of the first interface includes required parameters, conditionally required parameters, and optional parameters. The conditionally required parameters include: external network information that is required in the NS scenario; the update request is a second request for updating the NS instance, and correspondingly, updating the instance based on the newly added first interface between NFVO and VNFM includes: In response to the second request, the NFVO sends a query request for each VNF instance in the NS instance to the VNFM based on the second interface; The NFVO receives the query results returned by the VNFM based on the second interface; The NFVO updates the modifiable parameters of each VNF instance based on the query results; The NFVO sends information to the VNFM to update each of the VNF instances based on the first interface; The NFVO receives the updated task identifiers of each VNF instance returned by the VNFM based on the first interface.

2. The method according to claim 1, characterized in that, The method further includes: The VNFM updates the association between each VNF instance and the VNF packet identifier and VNFD identifier based on the updated information of each VNF instance; The VNFM sends the association relationship to the NFVO based on the third interface; The NFVO associates each VNF instance with its corresponding VNF packet identifier and VNFD identifier based on the association relationship.

3. The method according to claim 2, characterized in that, The method further includes: The VNFM requests resource authorization from the NFVO based on the fourth interface; The NFVO returns the resource authorization result to the VNFM based on the fourth interface.

4. The method according to claim 3, characterized in that, The method further includes: The VNFM sends a VNF lifecycle change notification to the NFVO via the fifth interface.

5. The method according to claim 4, characterized in that, The method further includes: Based on the updated resources of each of the VNF instances, the NFVO performs at least one of the following: adding an equal-cost route, adding a signaling collection rule, deleting an equal-cost route, and deleting a signaling collection rule; The NFVO updates the Virtual Link (VL) and network connectivity resources of the NS instance.

6. A method for updating instances of Network Functions Virtualization, characterized in that, include: The Network Functions Virtualization Orchestrator (NFVO) receives update requests that update instances of Network Functions Virtualization (NFV). The update request updates the instance based on the newly added first interface between the NFVO and the Virtual Network Function Manager (VNFM); The instance is a VNF instance. The parameter body of the first interface includes required parameters, conditionally required parameters, and optional parameters. The conditionally required parameters include: external network information required in the NS scenario. The update request is a first request for updating the VNF instance. Accordingly, updating the instance based on the newly added first interface between the NFVO and VNFM includes: In response to the first request, the NFVO sends a query request for the VNF instance to the VNFM based on the second interface; The NFVO receives the query results returned by the VNFM based on the second interface; The NFVO updates the mutable parameters of the VNF instance based on the query results; The NFVO sends information to the VNFM to update the VNF instance 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.

7. The method according to claim 6, characterized in that, The method further includes: The VNFM updates the association between the VNF instance and the VNF packet identifier and the Virtual Network Function Description (VNFD) identifier based on the information of the updated VNF instance; The VNFM sends the association relationship to the NFVO based on the third interface; The NFVO associates the VNF instance with the corresponding VNF packet identifier and VNFD identifier based on the association relationship.

8. The method according to claim 7, characterized in that, The method further includes: The VNFM requests resource authorization from the NFVO based on the fourth interface; The NFVO returns the resource authorization result to the VNFM based on the fourth interface.

9. The method according to claim 8, characterized in that, The method further includes: The VNFM sends a VNF lifecycle change notification to the NFVO via the fifth interface.

10. An NFV management and orchestration device, characterized in that, include: NFVO and VNFM, wherein the NFVO and the VNFM are configured to perform the steps of the method as described in any one of claims 1 to 9.

11. A storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images