CN112217654B

CN112217654B - Service resource license management method and related equipment

Info

Publication number: CN112217654B
Application number: CN201910625039.5A
Authority: CN
Inventors: 夏海涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-07-11
Filing date: 2019-07-11
Publication date: 2022-06-07
Anticipated expiration: 2039-07-11
Also published as: CN112217654A; WO2021004320A1

Abstract

The embodiment of the application provides a service resource permission management method and related equipment. The service resource permission management method comprises the following steps: the VNFM receiving a lifecycle management operation request for a containerized VNF instance; reading service resources requested to be used by the containerized VNF instance in the life cycle management operation from the VNFD; sending a VNF lifecycle operation permission request to the NFVO, wherein the VNF lifecycle operation permission request carries service resources requested to be used by a containerized VNF instance in lifecycle management operation; a VNF lifecycle operations permission response is received from the NFVO. The embodiment of the application is beneficial to flexibly managing the service resources used by the containerized VNF instances from the perspective of network services.

Description

Service resource license management method and related equipment

Technical Field

The present application relates to the field of communications technologies, and in particular, to a service resource permission management method and a related device.

Background

Network Function Virtualization (NFV) refers to a telecommunication Network operator, by using Virtualization Technology in the Information Technology (IT) field, decoupling software and hardware for implementing part of telecommunication Network functions (e.g., core Network functions) in general servers, switches, memories, and other devices, thereby implementing fast and efficient deployment and operation of Network Services (NS), and simultaneously achieving the goal of saving Network investment cost and operation cost. By applying NFV technology, telecommunications network functions are implemented in software and can run on generic server hardware, can be migrated, instantiated, deployed at different physical locations of the network as required, and do not require installation of new equipment.

Among them, the Container as a Service (CaaS) can be regarded as a specific type of Platform as a Service (PaaS). In general, Container (Container) is an operating system level virtualization technology that isolates different processes through operating system isolation techniques such as CGroup and NameSpace under Linux. The container technology is different from a hardware virtualization (Hypervisor) technology, virtual hardware is not provided, an operating system is not provided inside a container, and only a process is provided. Due to the important characteristic of the container technology, the container is lighter in weight and more convenient to manage compared with a virtual machine. In the operating state of the container, a group of common management operations is defined, specifically for example: start, stop, pause, delete, etc., for unified lifecycle management of the containers.

Application form servitization or microservices supported by the containerized VNF, currently, no service resource permission management scheme for use in the containerized VNF instance lifecycle management process has been proposed in the industry.

Disclosure of Invention

The embodiment of the application provides a service resource permission management method and related equipment.

A first aspect of an embodiment of the present application provides a method for service resource admission management, including:

a Virtualized Network Function Manager (VNFM) receives a lifecycle management operation request (e.g., from a Network Function virtualization orchestrator or an element management system, etc.) for a containerized Virtual Network Function (VNF) instance. The VNFM reads, from a virtualized network function Descriptor (VNFD, VNF Descriptor), service resources that the containerized VNF instance requests to use in lifecycle management operations.

The VNFM sends a VNF lifecycle operation permission request to a Network Function Virtualization Orchestrator (NFVO), where the VNF lifecycle operation permission request carries service resources requested to be used by the containerized VNF instance in the lifecycle management operation. The VNFM receives a VNF lifecycle operations permission response from the NFVO.

The service resource of the containerized VNF instance is, for example, a total number (which may also be referred to as a quota or a volume upper limit) of container objects included in a container object package called by the containerized VNF instance.

In some possible embodiments, the VNF lifecycle management permission response may carry, for example, a success indication or a failure indication.

In some possible embodiments, the VNF lifecycle management permission reply may also carry service resources that the containerized VNF instance permitted by the NFVO is permitted to use in the lifecycle management operation. Wherein the service resources allowed by the NFVO containerized VNF instance to be used in the lifecycle management operation, for example, the service resources that the containerized VNF instance carried in the VNF lifecycle operation permission request may be greater than or less than or equal to the service resources requested to be used in the lifecycle management operation.

In some possible embodiments, the method further comprises:

when the VNF lifecycle management permission response carries a success indication, the VNFM sends a management operation request of a container object package to a container management platform CISM, where the management operation request carries a service resource of the container object package, and the service resource of the container object package does not exceed a service resource allowed to be used by the NFVO containerized VNF instance in the lifecycle management operation.

In the foregoing example scheme, when the VNFM executes the lifecycle management operation of the containerized VNF instance, the VNFM first initiates a VNF lifecycle operation permission request to the VNFO to request the VNFO to permit the relevant service resources, and the NFVO uniformly permits the service resources used by the container object in the lifecycle management operation of the containerized VNF instance, which is beneficial to avoiding service resource usage conflicts in the NS layer due to the fact that the service resources used by each member VNF in the network service exceed the relevant preset quota, and further beneficial to effectively managing the service resources used by the containerized VNF instance from the perspective of the network service.

A second aspect of an embodiment of the present application provides a virtualized network function manager, including:

a receiving unit, configured to receive a lifecycle management operation request of a containerized VNF instance (where the lifecycle management operation request is, for example, from a network function virtualization orchestrator or a network element management system, etc.).

A reading unit, configured to read, from the VNFD, a service resource that the containerized VNF instance requests to use in a lifecycle management operation.

A sending unit, configured to send a VNF lifecycle operation permission request to the NFVO, where the VNF lifecycle operation permission request carries service resources requested to be used by the containerized VNF instance in the lifecycle management operation. The VNFM receives a VNF lifecycle operations permission response from the NFVO.

The service resource of the containerized VNF instance is, for example, a total number (which may also be referred to as a quota or an upper limit of quantity) of container objects included in a container object package called by the containerized VNF instance.

In some possible embodiments, the sending unit is further configured to: and when the VNF lifecycle management permission response carries a success indication, sending a management operation request of the container object packet to a container management platform (CISM), wherein the management operation request carries service resources of the container object packet. Wherein service resources of the container object package do not exceed service resources allowed by the NFVO for use by the containerized VNF instances in the lifecycle management operations.

A third aspect of the embodiments of the present application provides a method for service resource admission management, including:

the network function virtualization orchestrator NFVO receives a virtual network function VNF lifecycle operation permission request from a virtual network function manager VNFM, wherein the VNF lifecycle operation permission request carries service resources requested to be used by the containerized VNF instance in a lifecycle management operation.

The NFVO sends a VNF lifecycle operations permission response to the VNFM.

In some possible implementations, the VNF lifecycle management permission response may also carry service resources that the containerized VNF instance permitted by the NFVO is permitted to use in the lifecycle management operation. Wherein the service resources allowed by the NFVO containerized VNF instance to be used in the lifecycle management operation, for example, the service resources that the containerized VNF instance carried in the VNF lifecycle operation permission request may be greater than or less than or equal to the service resources requested to be used in the lifecycle management operation.

In some possible embodiments, before the NFVO sending the VNF lifecycle operations license response to the VNFM, the method may further include: the NFVO determines a relationship between service resources, which are requested to be used by the containerized VNF instance in the lifecycle management operation, and service resources of a Network Service (NS) instance to which the containerized VNF instance belongs;

wherein the VNF lifecycle operations permission response may carry a success indication in the event that the service resources requested for use by the containerized VNF instance in the lifecycle management operation do not exceed the service resources of the NS instance to which the containerized VNF instance belongs. The VNF lifecycle operations permission response may carry a failure indication in case the service resources requested for use by the containerized VNF instance in the lifecycle management operation exceed the service resources of the network service NS instance to which the containerized VNF instance belongs.

The service resource of the NS instance is, for example, the total number of container objects included in the container object package called by all member VNF instances and/or all member nested NS instances included in the NS instance.

In the foregoing example scheme, when the VNFM executes the lifecycle management operation of the containerized VNF instance, the VNFM first initiates a VNF lifecycle operation permission request to the VNFO to request the VNFO to permit the relevant service resources, and the NFVO uniformly permits the service resources used by the container object in the lifecycle management operation of the containerized VNF instance, so that it is possible to avoid service resource usage conflicts formed on the NS level by the service resources used by each member VNF in the network service exceeding the relevant preset quota, and further, the VNFM is favorable to effectively manage the service resources used by the containerized VNF instance from the perspective of the network service.

A fourth aspect of the present embodiment provides a network function virtualization orchestrator NFVO, including:

a receiving unit, configured to receive a virtual network function VNF lifecycle operation permission request from a virtual network function manager VNFM. The service resources requested to be used by the containerized VNF instance in the lifecycle management operation are carried in the VNF lifecycle operation permission request.

A sending unit configured to send a VNF lifecycle operation permission response to the VNFM.

In some possible embodiments, the NFVO further includes a determining unit, configured to, before the sending unit sends the VNF lifecycle operation permission response to the VNFM: and judging the relation between the service resources requested to be used by the containerized VNF instances in the life cycle management operation and the service resources of the network service NS instances to which the containerized VNF instances belong.

Wherein, the service resource of the NS instance is, for example, the total number of container objects contained in the container object package called by all the member VNF instances and/or all the member nested NS instances contained in the NS instance.

A fifth aspect of the present application provides a service resource permission management method, including: the container management platform CISM receives a management operation request of a container object package from a virtualized network function manager VNFM, where the management operation request carries service resources of the container object package, and the service resources of the container object package do not exceed service resources allowed to be used by a containerized VNF instance permitted by a network function virtualization orchestrator NFVO in a lifecycle management operation. And the CISM monitors the container object under the container object package used by the containerized VNF instance in the life cycle management process by using the service resource of the container object package.

In some possible embodiments, the monitoring, by the CISM, the container object under the container object package used by the containerized VNF instance in the lifecycle management process using the service resource of the container object package may include: when the CISM expands the containerized VNF instance by monitoring the operation of the container objects and determining the number of the expanded container objects, the CISM determines that the sum of the number of the container objects to be expanded and the number of the container objects currently running in the containerized VNF instance cannot exceed the service resources of the container object package.

In the foregoing example scheme, when the VNFM executes the lifecycle management operation of the containerized VNF instance, the NFVO is used to uniformly grant the service resources used by the container object in the lifecycle management operation of the containerized VNF instance, and the CISM monitors the container object under the container object package used by the containerized VNF instance that is not more than the service resources permitted by the NFVO in the lifecycle management operation, so as to avoid service resource usage conflicts at the NS level due to the fact that the service resources used by each member VNF in the network service exceed the relevant preset quota, and further, to effectively manage the service resources used by the containerized VNF instance from the perspective of the network service.

A sixth aspect of an embodiment of the present application provides a container management platform CISM, including: a receiving unit, configured to receive a management operation request of a container object package from a virtualized network function manager VNFM, where the management operation request carries service resources of the container object package, and the service resources of the container object package do not exceed service resources allowed by a containerized VNF instance permitted by a network function virtualization orchestrator NFVO in a lifecycle management operation.

A monitoring unit, configured to monitor, using the service resource of the container object package, a container object under the container object package used by the containerization VNF instance in a lifecycle management process.

In some possible embodiments, the monitoring unit is specifically configured to: when the CISM expands the containerized VNF instance by monitoring the operation of the container objects and determining the number of the expanded container objects, it is determined that the sum of the number of the container objects to be expanded and the number of the container objects currently running in the containerized VNF instance cannot exceed the service resources of the container object package.

A seventh aspect of the present embodiment provides a service resource permission management method, including: the network function virtualization orchestrator NFVO receives a first service resource management request from a virtualized network function manager VNFM, where the first service resource management request carries service resources requested to be used by a containerized VNF instance in a lifecycle management operation. The NFVO sends a second service resource management request to a container management platform CISM, where the second service resource management request carries service resources permitted by the NFVO to be used by the containerized VNF instance in the lifecycle management operation. After receiving a second service resource management response from the CISM, the NFVO sends a first service resource management response to the VNFM, where the first service resource management response carries the service resources allowed by the NFVO to be used in the lifecycle management operation by the containerized VNF instance permitted by the NFVO.

In some possible embodiments, before the NFVO sends the second service resource management request to the CISM, the method further includes: in case that the service resource requested to be used by the containerized VNF instance in the lifecycle management operation does not exceed the service resource of the network service NS instance to which the containerized VNF instance belongs, the NFVO permits the containerized VNF instance to grant the service resource allowed to be used in the lifecycle management operation, wherein the service resource allowed to be used is less than or equal to the service resource requested to be used.

In the case that the service resources requested to be used by the VNF instance in the lifecycle management operation exceed the service resources of the NS instance to which the containerized VNF instance belongs, the NFVO determines the service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation, the allowed service resources being smaller than the service resources requested to be used. Alternatively, in the case that the service resources requested to be used by the VNF instance in the lifecycle management operation exceed the service resources of the NS instance to which the containerized VNF instance belongs, the NFVO may refuse to permit the service resources that the containerized VNF instance is permitted to use in the lifecycle management operation.

Correspondingly, the CISM receives a second service resource management request from the NFVO, and the container management platform sends a second service resource management response to the NFVO.

And the CISM monitors the container object under the container object package used by the containerized VNF instance in the life cycle management process by using the service resource of the container object package. The service resources of the container object package do not exceed the service resources used by the VNF instance licensed by the NFVO in lifecycle management operations.

The monitoring, by the CISM, the container object under the container object package used by the containerized VNF instance in the lifecycle management process using the service resource of the container object package may include, for example: when the CISM expands the containerized VNF instances by monitoring the operation of the container objects and deciding to expand the number of container objects, the CISM determines that the number of container objects to be expanded and the number of running container objects in the containerized VNF instances cannot exceed the bulk service resources granted by the NFVO.

In the foregoing example scheme, when the VNFM triggers execution of the lifecycle management operation of the containerized VNF instance, the NFVO uniformly grants the service resources used by the container object in the lifecycle management operation of the containerized VNF instance, and the CISM monitors the container object under the container object package used by the containerized VNF instance that is not more than the service resources granted by the NFVO in the lifecycle management operation, so as to avoid service resource usage conflicts at the NS level due to the fact that the service resources used by each member VNF in the network service exceed the relevant preset quota, and further, to effectively manage the service resources used by the containerized VNF instance from the perspective of the network service.

An eighth aspect of the present embodiment provides a network function virtualization orchestrator NFVO, including: a receiving unit, configured to receive a first service resource management request from a virtualized network function manager VNFM, where the first service resource management request carries a service resource that a containerized VNF instance requests to use in a lifecycle management operation.

A sending unit, configured to send a second service resource management request to a container management platform CISM, where the second service resource management request carries a service resource that the containerization VNF instance permitted by the NFVO allows to be used in the lifecycle management operation. After receiving a second service resource management response from the CISM, a receiving unit sends a first service resource management response to the VNFM, where the first service resource management response carries service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation.

In some possible embodiments, the NFVO further includes a processing unit, configured to, before sending the second service resource management request to the CISM, grant, to the containerized VNF instance, a service resource that is requested to be used in the lifecycle management operation, in case that the service resource of the network service NS instance to which the containerized VNF instance belongs is not exceeded by the service resource of the container VNF instance, a service resource that is allowed to be used in the lifecycle management operation by the containerized VNF instance, where the service resource that is allowed to be used is equal to the service resource that is requested to be used.

Determining a service resource allowed to be used by the containerized VNF instance in the lifecycle management operation if the service resource requested to be used by the VNF instance in the lifecycle management operation exceeds the service resource of the NS instance to which the containerized VNF instance belongs, the service resource allowed to be used being smaller than the service resource requested to be used. Or in case the service resources requested to be used by the VNF instance in the lifecycle management operation exceed the service resources of the NS instance to which the containerized VNF instance belongs, the service resources allowed to be used by the containerized VNF instance in the lifecycle management operation may be denied.

A ninth aspect of an embodiment of the present application provides a virtual network function manager VNFM, including: a processor and a memory coupled to each other; the processor is configured to call a computer program stored in the memory to complete some or all of the steps of any one of the methods performed by the VNFM in the embodiments of the present application.

A tenth aspect of the present embodiment provides a network function virtualization orchestrator NFVO, including: a processor and a memory coupled to each other; the processor is configured to call a computer program stored in the memory to complete part or all of the steps of any one of the methods performed by the NFVO in the embodiments of the present application.

An eleventh aspect of an embodiment of the present application provides a container management platform CISM, which may include: a processor and a memory coupled to each other; the processor is configured to call a computer program stored in the memory to complete part or all of the steps of any one of the methods performed by the CISM in the embodiments of the present application.

A twelfth aspect of embodiments of the present application provides a computer-readable storage medium storing a computer program, which when executed by a processor, is capable of performing part or all of the steps of any one of the methods performed by the VNFM of the embodiments of the present application.

A thirteenth aspect of embodiments of the present application provides a computer-readable storage medium, where a computer program is stored, and the computer program, when executed by a processor, is capable of performing part or all of the steps of any one of the methods performed by the NFVO in the embodiments of the present application.

A fourteenth aspect of the present application provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program can perform part or all of the steps of any one of the methods performed by the CISM in the embodiments of the present application.

Drawings

Some drawings to which embodiments of the present application relate will be described below.

FIG. 1 is a diagram of an ETSI NFV MANO standard architecture according to an embodiment of the present application

Fig. 2 is a schematic diagram of a VM-based VNF information model provided in an embodiment of the present application.

Fig. 3 is a schematic diagram of a kubernets container management orchestration architecture according to an embodiment of the present application.

Fig. 4 is a schematic diagram of an information model of a containerization VNF according to an embodiment of the present application.

Fig. 5 is a schematic diagram of an ETSI NFV standard MANO management container target architecture provided by an embodiment of the present application.

Fig. 6 is a flowchart illustrating a service resource permission management method according to an embodiment of the present application.

Fig. 7 is a flowchart illustrating a service resource permission management method according to an embodiment of the present application.

Fig. 8 is a flowchart illustrating a service resource permission management method according to an embodiment of the present application.

Fig. 9 is a schematic architecture diagram of a VNFM according to an embodiment of the present application.

Fig. 10 is a schematic structural diagram of an NFVO provided in an embodiment of the present application.

Fig. 11 is a schematic architecture diagram of a CISM according to an embodiment of the present application.

Fig. 12 is a schematic architecture diagram of another NFVO provided in the embodiment of the present application.

Fig. 13 is a schematic architecture diagram of a communication device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

The standardization work of NFV has mainly focused on Virtual Network Functions (VNF), dynamic management and Orchestration of Network services and virtual resources (MANO). The functional planning and the like within the MANO framework is typically performed by the IFA (InterFace and Architecture) working group of the NFV industry Standards group under the European Telecommunications Standards Institute (ETSI), the functional Architecture of which may be shown in fig. 1. Virtual Network Function Manager (VNF, Virtualized Network Function Manager)

In the architecture shown in fig. 1, the NFV Orchestrator (NFVO, NFV editor) may be configured to implement management and processing of a Network Service Descriptor (NSD, NS Descriptor), a virtual Network function Forwarding Graph (VNFFG, VNF Forwarding Graph), management of a lifecycle of a Network Service (NS, Network Service), and implement lifecycle management of a VNF in cooperation with a VNFM and have a global view function of a virtual resource.

The VNF Manager (VNFM, VNF Manager) may perform lifecycle management of the virtualized network function VNF, including management of virtualized network function descriptors (VNFD, VNF Descriptor), instantiation of the VNF (instantiation), elastic Scaling of VNF instances (which may include Scaling out/up and Scaling in/down), healing of VNF instances (healing), and termination of VNF instances (termination). The VNFM also supports receiving an elastic scaling (scaling) strategy issued by the NFVO, and realizes automatic VNF elastic scaling.

The Virtual Infrastructure Manager (VIM) is mainly responsible for management (including reservation and allocation) of virtual resources (including virtual computing, storage and network resources) of an Infrastructure layer, monitoring and fault reporting of states of the virtual resources, and providing a virtual resource pool for upper-layer applications.

An operation and Business Support system (OSS/BSS) may refer to an operation and maintenance system (OSS/BSS) of an operator.

An Element management system (EM) performs a conventional Fault (Fault), user (Account) and Configuration (Configuration), Performance (Performance) and Security (Security) management (FCAPS management, for short) function for the VNF.

Virtualized Network Functions (VNFs) correspond to Physical Network Functions (PNFs) in traditional non-Virtualized networks, such as Virtualized EPC nodes (packet gateways, service gateways, etc.). The functional behavior and state of the network function are independent of virtualization, and NFV technology requires that VNF and PNF have the same functional behavior and external interface.

The NFV Infrastructure (NFVI) is an Infrastructure layer of NFV functions, consisting of hardware and virtual resources and virtualization layers. From the VNF perspective, the virtualization layer and hardware resources are one complete entity that can provide the required virtual resources.

The management object information model in the NFV field is described around a function model, a deployment model, and a resource model of the VNF, and may be specifically shown in fig. 2.

Among them, in the functional model (also referred to as a functional view) illustrated in fig. 2 by way of example, the highest-order management object in the NFV domain is a Network Service (NS), and each NS may be composed of one or more VNFs. Further, each VNF may in turn be composed of one or more VNF components (VNFCs, VNF components) of a lower functional level. NS is visible only to NFVO, VNF is visible to both NFVO and VNFM, and VNFC is visible only to VNFM.

In a deployment model (also referred to as a deployment view), VNFs of the same class (e.g., vmmme or vPGW, etc.) uniquely correspond to a VNF descriptor file (VNFD), and one or more VNF instances are created using the VNFD. One or more finer-grained Virtualized Deployment Units (VDUs) may be included in the VNFD, and each VDU uniquely corresponds to a type of VNFC, and includes description information required for Deployment and operation of the type of VNFC.

In a resource model (also referred to as a resource view), the virtualization layer of the NFVI abstracts and encapsulates the underlying hardware resources (or referred to as physical resources) into Virtual Machines (VMs). The VNF may be deployed on multiple VMs, each VM uniquely carrying the functionality of one VNFC, although the VNF may also be deployed on one VM. In VNFD, each VDU describes a demand of a type of VNFC for Infrastructure layer virtual resources (Infrastructure resources), and VM allocated by VIM encapsulates information of Infrastructure layer virtual resources that satisfy the demand. From the functional model to the deployment model to the resource model, a one-to-one mapping relationship is formed between the VNFC and the VDU and VM. The host (host) is a hardware resource on which one or more VM instances can be created separately. The VM is visible to both NFVO and VNFM, while the host resources are not visible to both NFVO and VNFM.

The introduction of the CaaS architecture in the telecommunication network function clouding process brings agility change to development operation and maintenance (DevOps) in the telecommunication industry. The corresponding change is that the traditional large particle monomer network function is gradually deconstructed to perform the service, and even further performs the micro-service. Each of the serviced functions is independently developed, delivered and maintained, and the version is upgraded more frequently; on the other hand, however, the rapid increase of the number of containerized network functions does not bring exponential workload increase to the interoperation test, and the stable API interface definition ensures the consistency and reliability of interface function call.

The most popular application in the field of container management organization is the Kubernetes (K8S for short) container cluster management technology based on an open source platform by Google corporation. The container application system constructed on Kubernets can independently run on a physical machine, a virtual machine or an enterprise private cloud and can also be managed to a public cloud. Another feature of kubernets is automation, a service that is self-scalable, self-diagnostic, and easily scalable. The kubernets container management orchestration may be illustrated in fig. 3 by way of example.

Container management orchestration is an important chassis architecture enhancement feature in the evolution of telecommunication Network Function Virtualization (NFV) to cloud native (clouduntive), and forms an interoperation standardized scenario by connecting the NFV MANO system with an industry application-mature container management platform (such as kubernets), thereby ensuring the continuous delivery of containerized VNFs in DevOps from architecture functions. Detailed analysis on the enhancement of the NFV management object information model after the container is introduced is not carried out in the prior art.

The target architecture for the MANO management container proposed by the IFA029 research report is shown by way of example in fig. 5. The Container Service is an Infrastructure Service that is stripped from the VNF function to form an independent layer, and a Container Manager (Container Manager) provides a required Container Infrastructure Service (CIS) for lifecycle management of the containerized VNF using interaction between a fact standard (e.g., kubernets API) and the Container Service. Wherein the container manager provides the NFVO or VNFM with the management function of container objects or container object packages (e.g., Pod of Kubernetes or Chart of Helm, etc.) on the northbound interface, and these container objects further constitute the containerized VNF. In the IFA029 report, the Container manager is also called Container Infrastructure Service Management (CISM), and the Container Service is also called Container Infrastructure Service (CIS).

IFA029 research reports the introduction of the concept of service resources on top of infrastructure resources (which may be virtual or bare machines, etc.) used by containers. The service resource refers to a logical resource used by the container object, and mapped to kubernets, and a resource quota (resource quota) used in a namespace is provided. The introduction of service resources enables infrastructure resources at the bottom layer of the container to be decoupled from the containerized VNF, and a designer of the VNF focuses more on the mapping implementation from the function logic of the VNF to the function logic of the container object without trapping details of the creation and allocation of infrastructure resources (such as virtual machines), so that the capacity of Kubernets autonomous management node resources is fully utilized, and the agile development and operation and maintenance of the containerized VNF are realized.

Service resources are visible to the NFVO or VNFM, while infrastructure resources (virtual or bare) become no longer visible to the NFVO or VNFM under the isolation of the service resources. Wherein, although the service resources are abstract logical resources defined by the container-oriented object, the management of the service resources can still be managed by referring to the management mode of infrastructure resources in the ETSI NFV standard, that is: and adopting a direct mode or an indirect mode for service resource management. Currently, the IFA029 report does not develop detailed research into the management of service resources used by containers. In particular, how to describe the service resources in the abstract container object layer and define the action boundary of the service resources on the container object will affect how to manage the service resources by multiplexing the existing infrastructure resource management mode.

An information model of a containerized VNF according to an embodiment of the present application may be as shown in fig. 4. The resource model of the containerization VNF introduces a logical resource layer (e.g., server resource in the resource model in fig. 4) composed of container objects (e.g., Pod, Service, or delivery objects in kubernets) as an abstraction. The logical resource layer isolates infrastructure resources (e.g., VM resources) from VNFs for container-based implementations, and the NFV MANO system manages container objects for the logical resource layer without managing infrastructure resources, which is left to the NFVI implementation.

In contrast to the VNF information model based on the VM shown in fig. 2, the resource model of the VNF shown in fig. 4 by way of example encapsulates an abstract logical resource, i.e. service resource, composed of container objects on an infrastructure resource.

Specifically, as shown in fig. 4 for example, abstract Container objects, also called Managed Container Infrastructure Objects (MCIO), contained in the Service resources may be specifically mapped to Container objects of the open source domain Container fact standard, specifically, such as Pod, Service or delivery in kubernets, ReplicaSets, stateful sets, and the like.

When a VNFM executes lifecycle management operation of a containerized VNF, the VNFM first initiates a request for permission of Service resources to the VNFO, and the NFVO permits the Service resources used by a container object in the VNF lifecycle management operation, thereby effectively avoiding conflict of Service resource usage at an NS level due to the fact that the Service resources used by each member VNF in a Network Service (NS, Network Service) exceed a preset quota.

Referring to fig. 2, in the IFA029 research report, a service resource is defined as a logical resource used by a container object, and mapping to kubernets corresponds to a resource quota (resource quota) used in a namespace. The namespace may be mapped to a VNF instance or a NS instance corresponding to a management scenario of a containerized VNF.

The service resource in the embodiment of the present application may have the following definitions:

service resources of containerized VNF instances: refers to the total number of container objects (which may also be referred to as a quota or upper limit of quantity) contained in the container object package of this containerization VNF instance call.

Service resources of the NS instance: refers to the total number of container objects (which may also be referred to as a quota or volume cap) used by all member components (e.g., nested NS and containerized VNF instances, etc.) contained by this NS instance.

The following illustrates the concept of the containerized VNF instance service resources and NS instance service resources described above.

The instantiation process of one containerization VNF requests 3 container package files (each defined by a respective Helm Chart template). The instantiated VNF instance will correspond to 3 container package instances (e.g. hell Release) that contain different numbers of container objects, for example: packet example 1 includes 2 kubernets Deployment objects, packet example 2 includes 3 kubernets Pod objects, and packet example 3 includes 2 kubernets Service objects, 1 kubernets Deployment object, and 1 replicases object. If the service resource of the containerization VNF instance is set to 10 (total/quota), and the total number of container objects included in the container object package called by the current containerization VNF instance is 9(2+3+2+1+1), the service resource setting of the containerization VNF instance is met, and the operation of the containerization VNF instance is permitted in the form of the number of container objects.

Accordingly, in a running NS instance, all VNF instances and nested NS instances that make up the NS instance cannot use more service resources than the NS instance sets.

Since there is a large difference between the number of function granules and the used infrastructure resources of different types of container objects (e.g. between kubernets Deployment and Pod, between Service and Pod) at the container object layer, the Service resources of the containerized VNF instance can be normalized to the total number of smallest granule container objects mapped to the container object contained in the container object package called by the containerized VNF instance, for example: different container object numbers are all mapped in kubernets to Pod numbers, or finer grained OS containers (typically, OS containers are Pod-packed with pods, not visible to other kubernets objects). The service resources of the NS instance may also be normalized to the total number of smallest granule size objects of the container object map used by all the member components (e.g., nested NS and containerized VNF instances, etc.) that the NS instance contains.

In view of the requirement of backward compatibility, the service resource of the containerization VNF instance may also be defined as a sum of the number of infrastructure resources (e.g., virtual computing, storage, and network resources) used by the container object included in the container object package called by the containerization VNF instance, which is not described in detail in this application.

The above description is an example of the definition of service resources in the embodiment of the present application.

Based on the above-mentioned exemplary architecture and related concepts, the following examples provide some related flows of a service resource licensing (gradting) management method.

Referring to fig. 6, fig. 6 is a flowchart illustrating a service resource permission management method according to an embodiment of the present application, where the service resource permission management method includes:

601. for example, the NFVO or EM sends a VNF lifecycle management operation request to the VNFM, which may be used to trigger initiation of a lifecycle management operation of the containerized VNF instance.

A VNFM receives a VNF lifecycle management operation request from a containerized VNF instance, such as NFVO or EM, that reads from a VNFD service resources that the containerized VNF instance requests to use in a lifecycle management operation.

The VNFM sends a VNF lifecycle operations permission request to the NFVO. The service resources requested to be used by the containerized VNF instance in the lifecycle management operation are carried in the VNF lifecycle operation permission request.

NFVO receives VNF lifecycle operation permission request from VNFM, which sends VNF lifecycle operation permission response to VNFM.

For example, before the NFVO sends the VNF lifecycle operations permission response to the VNFM, the method further includes: the NFVO determines a relationship between service resources that the containerized VNF instance requests to use in the lifecycle management operation and service resources of the NS instance to which the containerized VNF instance belongs. The VNF lifecycle operations license response may carry a success indication in case the service resources requested for use by the containerized VNF instance in the lifecycle management operation do not exceed the service resources of the NS instance to which the containerized VNF instance belongs. The VNF lifecycle operations permission response may carry a failure indication in case the service resources requested for use by the containerized VNF instance in the lifecycle management operation exceed the service resources of the network service NS instance to which the containerized VNF instance belongs. The service resource of the NS instance may be a total number (quota) of container objects included in a container object package called by all member VNF instances and/or all member nested NS instances included in the NS instance.

605. The VNFM receives a VNF lifecycle operations permission response from the NFVO.

Wherein the VNF lifecycle management permission reply may carry service resources that are used by the VNF instances permitted by the NFVO in the lifecycle management operation in an order of words. Wherein the service resources allowed to be used by the VNF instance permitted by the NFVO in the lifecycle management operation are greater than or equal to or less than the service resources requested to be used by the containerized VNF instance carried in the VNF lifecycle operation permission request in the lifecycle management operation.

In addition, when the VNF lifecycle operation permission reply carries a failure indication, the NFVO may further carry the service resources it recommends for use in the reply message.

When the VNF lifecycle management permission response carries a success indication, the VNFM sends a management operation request of a container object package to a container management platform CISM, where the management operation request carries service resources of the container object package, and the service resources of the container object package do not exceed the service resources permitted by the VNF instance permitted by the NFVO in the lifecycle management operation.

The CISM receives a management operation request from a container object package of the VNFM. And the CISM monitors the container object under the container object package used by the containerized VNF instance in the life cycle management process by using the service resource of the container object package.

The monitoring, by the CISM, of the container object under the container object package used by the containerized VNF instance in the lifecycle management process using the service resource of the container object package may include, for example: when the CISM expands the containerized VNF instances by monitoring the operation conditions of the container objects and determining the number of the expanded container objects, the CISM judges that the sum of the number of the container objects to be expanded and the number of the container objects which are in operation in the containerized VNF instances cannot exceed the service resources of the container object package.

In the foregoing example scheme, when the VNFM executes the lifecycle management operation of the containerized VNF, the VNFM first initiates a VNF service resource permission request to the VNFO, and the NFVO permits the service resource used by the container object in the lifecycle management operation of the containerized VNF instance, which is beneficial to effectively avoid a conflict of service resource usage formed at an NS level by the service resource used by each member VNF in the network service due to exceeding a preset quota, and is further beneficial to effectively managing the service resource used by the containerized VNF instance from the perspective of the network service.

Referring to fig. 7, fig. 7 is a flowchart illustrating another method for managing a service resource license according to an embodiment of the present application, where the another method for managing a service resource license includes:

and 701, the NFVO sends a service resource batch permission request aiming at the VNF lifecycle management operation to the VNFM, wherein the service resource batch permission request carries batch service resources granted to the VNFM by the NFVO.

The VNFM-managed bulk services resource may be, for example, a range including an upper threshold and a lower threshold, i.e., the VNFM-managed bulk services resource cannot exceed an upper boundary and a lower boundary of a value determined by the range.

Before the NFVO sends the service resource batch permission request for the VNF lifecycle management operation to the VNFM, the NFVO may determine to grant the batch of container services to the VNFM for management based on global consideration of NS lifecycle management. The bulk of service resources may be used in the lifecycle management operation of any containerized VNF instance managed by the VNFM, and the total number of service resources used by all containerized VNF instances managed by the VNFM cannot exceed the bulk of service resources granted by the NFVO at any time.

The VNFM receives a service resource bulk permission request for VNF lifecycle management operations from the NFVO. The VNFM returns a service resource bulk permission reply to the NFVO for the VNF lifecycle management operation, which may carry a success or failure indication.

703. When the service resource bulk permission response carries a success indication, the VNFM sends a management operation request of the container object package to the container management platform when the VNFM performs the containerization VNF lifecycle management operation.

704. And the container management platform receives a management operation request of a container object package from the VNFM, and the CISM monitors container objects under the container object package used by the containerized VNF instances in the life cycle management process by using service resources of the container object package.

It can be seen that the above flow provides a convenient and fast batch license management mechanism for service resources, which is beneficial to simplifying the interaction complexity of the lifecycle management process of the containerized VNF instance.

Referring to fig. 8, fig. 8 is a flowchart illustrating another method for managing a service resource license according to an embodiment of the present application, where the another method for managing a service resource license includes:

801. for example, the NFVO or EM sends a VNF lifecycle management operation request to the VNFM to trigger initiation of a lifecycle management operation of the containerized VNF instance.

The VNFM receives a VNF lifecycle management operation request from the NFVO or the EM, and sends a first service resource management request to the NFVO, where the first service resource management request carries service resources requested to be used by the containerized VNF instance in the lifecycle management operation.

NFVO receives the first service resource management request from the VNFM. The NFVO sends a second service resource management request to a container management platform CISM, where the second service resource management request carries service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation.

And 804, the CISM receives a second service resource management request from the NFVO, and the container management platform sends a second service resource management response to the NFVO.

The monitoring, by the CISM, the container object under the container object package used by the containerized VNF instance in the lifecycle management process using the service resource of the container object package may include, for example: when the CISM expands a containerized VNF instance by monitoring the operation of container objects and deciding to expand the number of container objects, the CISM determines that the number of container objects to be expanded and the number of running container objects in the containerized VNF instance cannot exceed the bulk services resources granted by the NFVO.

805. After receiving a second service resource management response sent by a container management platform, the NFVO sends a first service resource management response to the VNFM, where the first service resource management response carries service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation.

In some possible embodiments, before the NFVO sends the second service resource management request to the CISM, the method may further include: in a case that the service resources requested to be used by the containerized VNF instance in the lifecycle management operation do not exceed the service resources of the network service NS instance to which the containerized VNF instance belongs, the NFVO permits the containerized VNF instance to grant the service resources allowed to be used in the lifecycle management operation, wherein the service resources allowed to be used are equal to the service resources requested to be used.

Some apparatus embodiments are also provided below.

Referring to fig. 9, an embodiment of the present application provides a virtualized network function manager VNFM 900, which includes:

a receiving unit 910, configured to receive a lifecycle management operation request of a containerized VNF instance.

A reading unit 920, configured to read, from the virtualized network function descriptor VNFD, a service resource requested to be used by the containerization VNF instance in the lifecycle management operation;

a sending unit 930, configured to send a VNF lifecycle operation permission request to a network function virtualization orchestrator NFVO, where the VNF lifecycle operation permission request carries a service resource that the containerized VNF instance requests to use in the lifecycle management operation;

the receiving unit 910 is further configured to receive a VNF lifecycle operations permission response from the NFVO.

In some possible implementations, the service resource of the containerized VNF instance is a total number of container objects included in a container object package invoked by the VNF instance.

In some possible embodiments, the VNF lifecycle management permission reply also carries service resources permitted by the VNF instance permitted by the NFVO to use in the lifecycle management operation.

In some possible embodiments, the sending unit 930 is further configured to, when the VNF lifecycle management permission response carries a success indication, send, to the container management platform CISM, a management operation request of a container object package, where the management operation request carries service resources of the container object package, and the service resources of the container object package do not exceed the service resources permitted by the VNF instance permitted by the NFVO in the lifecycle management operation.

Referring to fig. 10, a network function virtualization orchestrator NFVO 1000 provided in an embodiment of the present application includes:

a receiving unit 1010, configured to receive a VNF lifecycle operation permission request from the VNFM, where the lifecycle operation permission request carries a service resource requested to be used by the containerized VNF instance in the lifecycle management operation.

A sending unit 1020, configured to send a VNF lifecycle operations permission response to the VNFM.

In some possible embodiments, the determining unit 1030 is further configured to determine, before sending the VNF lifecycle operation permission response to the VNFM, a relationship between the service resource requested to be used by the containerized VNF instance in the lifecycle management operation and a service resource of the NS instance to which the containerized VNF instance belongs.

The VNF lifecycle operation permission response carries a success indication in case the service resources requested for use by the containerized VNF instance in the lifecycle management operation do not exceed the service resources of the network service NS instance to which the containerized VNF instance belongs.

The VNF lifecycle operation permission response carries a failure indication in case that the service resources requested for use by the containerized VNF instance in the lifecycle management operation exceed the service resources of the network service NS instance to which the containerized VNF instance belongs.

In some possible embodiments, the service resource of the NS instance is a total number of container objects included in a container object package invoked by all member VNF instances and/or all member nested NS instances included in the NS instance.

Referring to fig. 11, a container management platform CISM 1100 provided in an embodiment of the present application includes:

a receiving unit 1110, configured to receive a management operation request of a container object package from a VNFM, where the management operation request carries service resources of the container object package, and the service resources of the container object package do not exceed service resources used by the VNF instance permitted by the NFVO in a lifecycle management operation;

a monitoring unit 1120, configured to monitor, using the service resource of the container object package, a container object under the container object package used by the containerized VNF instance in the lifecycle management process.

In some possible embodiments, the monitoring unit is specifically configured to, when the CISM performs the extension on the containerized VNF instance by monitoring the operation condition of the container object and deciding to extend the number of container objects, the CISM determines that the number of container objects to be extended and the number of container objects in the containerized VNF instance that are currently running cannot exceed the service resource of the container object package.

Referring to fig. 12, an NFVO 1200 provided in an embodiment of the present application includes:

a receiving unit 1210, configured to receive a first service resource management request from a VNFM, where the first service resource management request carries service resources requested to be used by a containerized VNF instance in a lifecycle management operation;

a sending unit 1220, configured to send a second service resource management request to a container management platform CISM, where the second service resource management request carries service resources that the containerized VNF instance permitted by the NFVO is permitted to use in the lifecycle management operation; after receiving a second service resource management response sent by the container management platform, the receiving unit sends a first service resource management response to the VNFM, where the first service resource management response carries the service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation.

In some possible embodiments, NFVO 1200 further includes a processing unit 1230, configured to, before the NFVO sends the second service resource management request to the container management platform CISM, grant the service resource requested by the containerized VNF instance to be used in the lifecycle management operation if the service resource requested by the VNF instance in the lifecycle management operation is not exceeded by the service resource of the network service NS instance to which the VNF instance belongs; in case the service resources requested by the VNF instance to be used in the lifecycle management operation exceed the service resources of the NS instance to which the VNF instance belongs, the service resources that the VNF instance that it grants uses in the lifecycle management operation.

In some possible embodiments, the service resource of the VNF instance is a total number of container objects included in a container object package called by the VNF instance.

Referring to fig. 13, an embodiment of the present application further provides a general communication device 1300, where the communication device 1300 may implement the functions of the VNFM, the NFVO, or the container management platform provided in the foregoing embodiment, and specifically includes:

a processor 1310 and a memory 1320 coupled to each other.

The processor 1310 is configured to call the computer program stored in the memory 1320 to complete some or all of the steps of any one of the methods performed by the VNFM in the embodiments of the present application.

In addition, the processor 1310 may also call different computer programs stored in the memory 1320 to perform some or all of the steps of any one of the methods performed by the NFVO or the container management entity in the embodiments of the present application.

Processor 1210 may also be referred to as a Central Processing Unit (CPU). The components of the image prediction apparatus in a particular application are coupled together, for example, by a bus system. The bus system may include a power bus, a control bus, a status signal bus, and the like, in addition to a data bus. For clarity of illustration, the various buses are designated in the figure as the bus system 730. The method disclosed in the embodiments of the present application can be applied to the processor 1310, or implemented by the processor 1310. The processor 1310 may be an integrated circuit chip having signal processing capabilities. In some implementations, some or all of the steps of the above methods may be performed by instructions in the form of hardware, integrated logic circuits, or software in the processor 1310. The processor 1310 may be a general purpose processor, a digital signal processor, an application specific integrated circuit, an off-the-shelf programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components. Processor 1310 may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. The general purpose processor 1310 may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in a hardware decoding processor, or in a combination of hardware and software modules in a decoding processor. The software modules may be located in ram, flash memory, rom, prom, eprom, or registers, among other storage media as is well known in the art. The storage medium is located in the memory 1320, and the processor 1310 may read information in the memory 1320, and combine hardware thereof to complete some or all of the steps of the above method.

Embodiments of the present application also provide a computer-readable storage medium storing a computer program, where the computer program is executed by hardware (for example, a processor, etc.) to perform some or all of the steps of any one of the methods performed by any device in the embodiments of the present application.

Embodiments of the present application also provide a computer program product comprising instructions for causing a computer device to perform some or all of the steps of any one of the above aspects when the computer program product runs on the computer device.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, digital subscriber line) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., compact disk), or a semiconductor medium (e.g., solid state disk), among others. In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the foregoing embodiments, the descriptions of the embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is merely a logical division, and the actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted or not executed. In addition, the indirect coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, indirect coupling or communication connection of devices or units, and may be electrical or in other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application, which are essential or part of the technical solutions contributing to the prior art, or all or part of the technical solutions, may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage media may include, for example: a U-disk, a portable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Claims

1. A method for service resource admission management, comprising: the method comprises the steps that a Virtual Network Function Manager (VNFM) receives a life cycle management operation request of a containerized Virtual Network Function (VNF) instance;

the VNFM reading, from a Virtualized Network Function Descriptor (VNFD), service resources requested to be used by the containerized VNF instance in a lifecycle management operation;

the VNFM sends a VNF lifecycle operation permission request to a Network Function Virtualization Orchestrator (NFVO), wherein the VNF lifecycle operation permission request carries service resources requested to be used by the containerized VNF instance in the lifecycle management operation;

the VNFM receiving a VNF lifecycle operation permission response from the NFVO for responding to the VNF lifecycle operation permission request;

wherein the service resource of the containerization VNF instance is the total number of container objects contained in a container object package called by the containerization VNF instance;

wherein, the first and the second end of the pipe are connected with each other,

the method further comprises the following steps: the VNF lifecycle management permission reply also carries service resources that the containerized VNF instance permitted by the NFVO to use in the lifecycle management operation,

service resources of the container object package do not exceed service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation.

2. The method of claim 1, further comprising:

and when the VNF lifecycle management permission response carries a successful indication, the VNFM sends a management operation request of the container object package to a container management platform (CISM), wherein the management operation request carries the service resource of the container object package.

3. A method for service resource admission management, comprising:

a network function virtualization orchestrator NFVO receives a virtual network function VNF lifecycle operation permission request from a virtual network function manager VNFM, wherein the VNF lifecycle operation permission request carries service resources requested to be used by a containerized VNF instance in a lifecycle management operation;

the NFVO sending a VNF lifecycle operation permission response to the VNFM in response to the VNF lifecycle operation permission request;

wherein the VNF lifecycle operation permission response carries a success indication in case that the service resources that the containerized VNF instance requests to use in the lifecycle management operation do not exceed the service resources of the NS instance to which the containerized VNF instance belongs;

4. The method of claim 3, wherein before the NFVO sending a VNF lifecycle operations license response to the VNFM, the method further comprises: the NFVO determines a relationship between service resources, which the containerized VNF instance requests to use in the lifecycle management operation, and service resources of a network service NS instance to which the containerized VNF instance belongs.

5. The method of claim 4, wherein the service resources of the NS instance are a total number of container objects included in a container object package invoked by all member VNF instances and/or all member nested NS instances included in the NS instance.

6. A method for service resource admission management, comprising: a container management platform (CISM) receives a management operation request of a container object package from a Virtualized Network Function Manager (VNFM), wherein the management operation request carries service resources of the container object package, and the service resources of the container object package do not exceed the service resources allowed to be used in life cycle management operation by a containerized VNF instance permitted by a Network Function Virtualization Orchestrator (NFVO);

and the CISM monitors the container object under the container object package used by the containerized VNF instance in the life cycle management process by using the service resource of the container object package.

7. The method of claim 6,

the CISM monitors, using the service resource of the container object package, a container object under the container object package used by the containerized VNF instance in the lifecycle management process, including:

when the CISM expands the containerized VNF instances by monitoring the operation conditions of the container objects and deciding the number of the expanded container objects, the CISM judges that the sum of the number of the container objects to be expanded and the number of the container objects which are in operation in the containerized VNF instances cannot exceed the service resources of the container object package.

8. The method according to claim 6 or 7, wherein the service resource of the containerized VNF instance is the total number of container objects included in the container object package called by the containerized VNF instance.

9. A method for service resource admission management, comprising: a network function virtualization orchestrator NFVO receives a first service resource management request from a virtualized network function manager VNFM, where the first service resource management request carries service resources requested to be used by a containerized VNF instance in a lifecycle management operation;

the NFVO sends a second service resource management request to a container management platform (CISM), wherein the second service resource management request carries service resources allowed to be used by the containerized VNF instances allowed by the NFVO in the lifecycle management operation;

after receiving a second service resource management response from the CISM, the NFVO sends a first service resource management response to the VNFM, where the first service resource management response carries service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation.

10. The method of claim 9, wherein before the NFVO sends the second service resource management request to the CISM, the method further comprises:

in case that the service resources requested to be used by the containerized VNF instance in the lifecycle management operation do not exceed the service resources of the network service NS instance to which the containerized VNF instance belongs, the NFVO permits the containerized VNF instance to permit the service resources allowed to be used in the lifecycle management operation, the allowed service resources being equal to the service resources requested to be used;

in the case that the service resources requested to be used by the VNF instance in the lifecycle management operation exceed the service resources of the NS instance to which the containerized VNF instance belongs, the NFVO determines the service resources allowed to be used by the containerized VNF instance permitted by the NFVO in the lifecycle management operation, the allowed service resources being smaller than the service resources requested to be used.

11. The method according to claim 9 or 10, wherein the service resource of the containerization VNF instance is a total number of container objects contained in a container object package called by the containerization VNF instance.

12. A virtual network function manager, VNFM, comprising:

a processor and a memory coupled to each other;

wherein the processor is configured to invoke a computer program stored in the memory to perform the method of any of claims 1 to 4.

13. A network function virtualization orchestrator NFVO, comprising:

a processor and a memory coupled to each other;

wherein the processor is configured to invoke a computer program stored in the memory to perform the method of any of claims 3 to 5 or 9 to 11.

14. A container management platform, CISM, comprising:

a processor and a memory coupled to each other;

wherein the processor is configured to invoke a computer program stored in the memory to perform the method of any of claims 6 to 8.

15. A computer-readable storage medium, characterized in that,

the computer-readable storage medium stores a computer program which, when executed by a processor, is capable of performing the method of any one of claims 1 to 11.