WO2020233205A1

WO2020233205A1 - Container service management method and device

Info

Publication number: WO2020233205A1
Application number: PCT/CN2020/079320
Authority: WO
Inventors: 李飞; 夏海涛
Original assignee: 华为技术有限公司
Priority date: 2019-05-22
Filing date: 2020-03-13
Publication date: 2020-11-26
Also published as: CN111988263B; CN111988263A

Abstract

Provided are a container service management method and device. The method comprises: when a VNFI needs to use a service provided by a container service instance, sending, to a container manager, a token request carrying identification information of the VNFI and identification information of a VNFM. Moreover, a token generated by the container manager according to the token request also comprises the identification information of the VNFI and the identification information of the VNFM. Accordingly, it is ensured that a token generated by a container manager for a certain VNFI cannot be used if the token is stolen by a VNFI managed by a different VNFM, thereby improving the security performance of a token used when a VNFI in an NFV system requests a service provided by a container service instance.

Description

Container service management method and device

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office, the application number is 201910429966X, and the application name is "Container Service Management Method and Apparatus" on May 22, 2019, the entire content of which is incorporated into this application by reference.

Technical field

This application relates to communication technology, and in particular to a container service management method and device.

Background technique

Network function virtualization (NFV) is a technology that uses universal hardware and network virtualization to construct a communication network system. It can be used to carry the software processing functions in the communication network and realize the virtualization and flexible deployment of the communication network. , Flexible expansion, and reduce the expensive equipment cost of the communication network system. The VNF instance (VNFI) obtained after the virtualized network function (VNF) in the NFV system is instantiated can be deployed on a virtual machine and used as a softwareized network element to perform network element related functions. For example, VNFI can correspond to a network element with physical network functions in a traditional non-virtualized communication network, and is used to implement, for example, mobile management entity (MME), serving gateway (SGW), and packet data. Gateway (packet data network gateway, PGW) and other functions. The virtualized network function management (VNFM) in the NFV system is used for VNFI management. At the same time, the container service instances in the NFV system can provide high-performance and scalable container application management services for each VNFI. These management services are packaged into portable containers (docker), while the container management in the NFV system The container manager is used to manage the container service instances in the NFV system.

In the prior art, when the VNFI needs to use the service provided by the container service instance, the VNFI needs to send a token application to the container manager through the VNFM; when the container manager receives the token application from the VNFI, it generates a token corresponding to the VNFI (token ), where the token includes the identification information (instance id) of the VNFI, the container service instance that the VNF can use, and the expiration time that the VNF can use the container service instance; then the container manager sends the token to the VNFI through the VNFM, so that the VNFI After receiving the token sent by the container manager, it can request the corresponding container service instance to provide services according to the token within the deadline.

However, the token requested by the existing VNFI from the container manager can still be used when it is stolen by the VNFI managed by a different VNFM, resulting in low security performance of the token. Therefore, how to improve the security performance of the token used when VNFI requests the service provided by the container service instance is a technical problem to be solved urgently in this field.

Summary of the invention

The present application provides a container service management method and device to improve the security performance of the token used when VNFI requests the service provided by the container service instance.

The first aspect of the present application provides a container management method, including: if a virtual network function instance VNFI needs to use the service provided by the container service instance, the VNFI sends a token request to a container manager used to manage the container service instance; wherein , The token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The VNFI receives the token sent by the container manager; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for all The container service instance verifies the VNFI that uses the token to request the service.

In summary, in this embodiment, VNFI sends a token request to the container manager when it needs to use the service provided by the container service instance, and the token generated by the container manager according to the token request includes the identification information of the VNFI and the VNFM The identification information. Since the generated token includes the identification information of the VNFM, when the VNFI requests services from the container service instance based on the token, the container service instance will not only verify the identification information of the VNFI in the token, but also verify the identification information of the VNFM in the token. This ensures that the token generated by the container manager for a certain VNFI cannot be used after being stolen by the VNFI managed by a different VNFM, thereby improving the security performance of the token used when the VNFI requests the service provided by the container service instance in the NFV system.

In an embodiment of the first aspect of the present application, after the VNFI receives the token sent by the container manager, it further includes: the VNFI sends a service request to the container service instance, and the service request includes the token , So that the container service instance verifies the VNFI according to the identification information of the VNFI and the identification information of the VNFM in the token; if the verification is successful, the VNFI uses the service provided by the container service instance .

In summary, in this embodiment, when the VNFI requests services from the container service instance based on the token, the container service instance will not only verify the identification information of the VNFI in the token, but also verify the identification information of the VNFM in the token. Only after the identification information of the VNFM and the identification information of the VNFM pass the verification, the container service instance will only provide the service. For two different VNFIs managed by two VNFMs, even if they have the same VNFI identification information, because the two VNFMs have different identification information, and the container service instance will also perform the VNFM identification information when the VNFI requests the container service Verification, therefore, when a VNFI applies for a token to the container manager, even if its token is stolen by another VNFI, the identification information of the VNFM in the token sent by the stolen VNFI is different from the actual VNFM identification information of the VNFI. The container service If the instance fails to verify the token, the container service instance will not provide container services to the VNFI that steals the token. As a result, even if the token is stolen by other VNFIs across VNFMs, the VNFI that stolen the token cannot use the service provided by the container service instance based on the token, which ensures that the token generated by the container manager for a certain VNFI is stolen by VNFIs managed by different VNFMs. However, it cannot be used later, which improves the security performance of the token used when VNFI requests the service provided by the container service instance in the NFV system.

In an embodiment of the first aspect of the present application, the token further includes: identification information of the container service instance;

The VNFI sending a service request to the container service instance according to the token includes: the VNFI sending a service request to a container service instance corresponding to the identification information of the container service instance according to the token.

To sum up, in this embodiment, when the container manager generates a VNFI token, the VNFI directly carries the VNFI in the token, and can determine the range of container service instances that can be provided to VNFI according to the identification information of the container service instance requested by the token. Qualify. As a result, VNFI needs to request service from the container service instance specified by the container manager in the token. Once the token is stolen across VNFM, other VNFIs cannot request service from the container service instance in the VNF system where the original token is located, which can also enhance the token. The security performance makes the token unusable after being stolen across VNFM.

In an embodiment of the first aspect of the present application, the VNFI sending a token request to the container manager includes: when the VNFM instantiates the VNFI, the VNFI sends the token to the container manager request;

Alternatively, after the VNFM instantiates the VNFI, the VNFI sends the token request to the container manager.

The second aspect of the present application provides a container service management method, including:

The container manager receives the token request sent by the virtual network function instance VNFI; wherein the VNFI needs to use the service provided by the container service instance managed by the container manager, and the token request includes the identification information of the VNFI , And the identification information of the virtual network function manager VNFM used to manage the VNFI;

The container manager generates a token according to the token request; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for all The container service instance verifies the VNFI that uses the token to request service;

The container manager sends the token to the VNFI.

In an embodiment of the second aspect of the present application, the token further includes: identification information of the container service instance; wherein the identification information of the container service instance is used for the VNFI to the container service instance The container service instance corresponding to the identification information requests the service.

The third aspect of the present application provides a container service management method, including: if a virtual network function instance VNFI managed by a virtual network function manager VNFM needs to use the service provided by the container service instance, the VNFM provides information for managing the container service instance The container manager sends a token request; wherein the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The VNFM receives the token sent by the container manager, and sends the token to the VNFI; wherein, the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification of the VNFI The information and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request the service.

In an embodiment of the third aspect of the present application, the token further includes: identification information of the container service instance;

The identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.

In an embodiment of the third aspect of the present application, the VNFM sending a token request to the container manager includes: when the VNFM instantiates the VNFI, the VNFM sends the token to the container manager request;

Alternatively, after the VNFM instantiates the VNFI, the VNFM sends the token request to the container manager.

A fourth aspect of the present application provides a container service management method, including: a container manager receives a token request sent by a virtual network function manager VNFM; wherein the virtual network function instance VNFI managed by the VNFM needs to use the container management For services provided by the container service instance managed by the server, the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The container manager sends the token to the VNFM, so that the VNFM sends the token to the VNFI.

In an embodiment of the fourth aspect of the present application, the token further includes: the identification information of the container service instance; wherein the identification information of the container service instance is used to send the VNFI to the container service instance The container service instance corresponding to the identification information requests the service.

A fifth aspect of the present application provides a container service management device, including:

The sending module is used to send a token request to the container manager for managing the container service instance if the virtual network function instance VNFI needs to use the service provided by the container service instance; wherein the token request includes the VNFI identifier Information, and identification information of the virtual network function manager VNFM used to manage the VNFI;

The receiving module is configured to receive the token sent by the container manager; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for The VNFI that uses the token to request the service is verified in the container service instance.

In an embodiment of the fifth aspect of the present application, it further includes: a processing module;

The sending module is further configured to send a service request to the container service instance, and the service request includes the token, so that the container service instance can according to the identification information of the VNFI in the token and the The identification information of the VNFM verifies the VNFI;

The processing module is configured to use the service provided by the container service instance if the verification is successful.

In an embodiment of the fifth aspect of the present application, the token further includes: identification information of the container service instance;

The sending module is specifically configured to send a service request to the container service instance corresponding to the identification information of the container service instance according to the token.

In an embodiment of the fifth aspect of the present application, the sending module is specifically configured to send the token request to the container manager when the VNFM instantiates the VNFI; or, when the VNFM instantiates the VNFI After the VNFI, the token request is sent to the container manager.

A sixth aspect of the present application provides a container service management device, including:

The receiving module is configured to receive a token request sent by a virtual network function instance VNFI; wherein, the VNFI needs to use the service provided by the container service instance managed by the container manager, and the token request includes the VNFI Identification information, and identification information of the virtual network function manager VNFM used to manage the VNFI;

The processing module is configured to generate a token according to the token request; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for all The container service instance verifies the VNFI that uses the token to request service;

The sending module is used to send the token to the VNFI.

In an embodiment of the sixth aspect of the present application, the token further includes: identification information of the container service instance; wherein, the identification information of the container service instance is used to send the VNFI to the container service instance The container service instance corresponding to the identification information requests the service.

A seventh aspect of the present application provides a container service management device, including:

The sending module is configured to send a token request to the container manager for managing the container service instance if the virtual network function instance VNFI managed by the virtual network function manager VNFM needs to use the service provided by the container service instance; wherein, the token The request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The receiving module is configured to receive the token sent by the container manager, and send the token to the VNFI through the sending module; wherein the token includes the identification information of the VNFI and the identification of the VNFM Information, the identification information of the VNFI and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request the service.

In an embodiment of the seventh aspect of the present application, the token further includes: identification information of the container service instance;

In an embodiment of the seventh aspect of the present application, the sending module is specifically configured to send the token request to the container manager when the VNFM instantiates the VNFI; or, when the VNFM instantiates the VNFI After the VNFI, the token request is sent to the container manager.

An eighth aspect of the present application provides a container management service device, including:

The receiving module is configured to receive a token request sent by the virtual network function manager VNFM; wherein the virtual network function instance VNFI managed by the VNFM needs to use the service provided by the container service instance managed by the container manager, and The token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The sending module is configured to send the token to the VNFM, so that the VNFM sends the token to the VNFI.

In an embodiment of the eighth aspect of the present application, the token further includes: identification information of the container service instance; wherein, the identification information of the container service instance is used to send the VNFI to the container service instance The container service instance corresponding to the identification information requests the service.

A ninth aspect of the present application provides a VNFI, including: a processor and a communication interface;

If the VNFI needs to use the service provided by the container service instance, the processor is configured to send a token request to the communication interface; wherein, the token request includes the identification information of the VNFI and is used to manage the VNFI The identification information of the virtual network function manager VNFM;

The communication interface is used to send the token request to a container manager for managing the container service instance;

The communication interface is also used to receive the token sent by the container manager and send the token to the processor; wherein the token includes the identification information of the VNFI and the identification information of the VNFM The identification information of the VNFI and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request the service.

In an embodiment of the ninth aspect of the present application, the processor is further configured to send a service request to the communication interface, and the service request includes the token, so that the container service instance is configured according to the token The identification information of the VNFI and the identification information of the VNFM verify the VNFI;

The communication interface is also used to send the service request to the container service instance;

If the verification is successful, the processor is further configured to use the service provided by the container service instance.

In an embodiment of the ninth aspect of the present application, the token further includes: identification information of the container service instance pair;

The communication interface is specifically configured to send the service request to the container service instance corresponding to the identification information of the container service instance.

In an embodiment of the ninth aspect of the present application, the processor is specifically configured to send the token request to the communication interface when the VNFM instantiates the VNFI; or the processor specifically uses Therefore, after the VNFM instantiates the VNFI, the token request is sent to the communication interface.

A tenth aspect of the present application provides a container manager, including: a communication interface and a processor;

The communication interface is used to receive a token request sent by a virtual network function instance VNFI, and send the token request to the processor; wherein, the VNFI needs to use a container service instance managed by the container manager For the provided service, the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The processor is configured to generate a token according to the token request, and send the token to the communication interface; wherein, the token includes the identification information of the VNFI and the identification information of the VNFM, and the VNFI The identification information and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request services;

The communication interface is also used to send the token to the VNFI.

In an embodiment of the tenth aspect of the present application, the token further includes: identification information of the container service instance; wherein, the identification information of the container service instance is used to send the VNFI to the container service instance The container service instance corresponding to the identification information requests the service.

The eleventh aspect of the present application provides a VNFM, including: a communication interface and a processor;

If the virtual network function instance VNFI managed by the VNFM needs to use the service provided by the container service instance, the processor is configured to send a token request to the communication interface; wherein, the token request includes identification information of the VNFI, And the identification information of the virtual network function manager VNFM used to manage the VNFI;

The communication interface is used to send the token request to a container manager for managing the service instance;

The communication interface is also used to receive the token sent by the container manager and send the token to the VNFI; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, so The identification information of the VNFI and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request services.

In an embodiment of the eleventh aspect of the present application, the token further includes: identification information of the container service instance;

A twelfth aspect of the present application provides a container manager, including: a communication interface and a processor;

The communication interface is used to receive a token request sent by a virtual network function manager VNFM, and send the token request to the processor; wherein the virtual network function instance VNFI managed by the VNFM needs to use the container For services provided by the container service instance managed by the manager, the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The processor is configured to generate a token according to the token request, and send the token to the communication interface; wherein, the token includes the identification information of the VNFI and the identification information of the VNFM, and the VNFI The identification information and the identification information of the VNFM are used by the container service instance to verify the VNFI using the token to request services; the communication interface is also used for sending the token to the VNFM so that the The VNFM sends the token to the VNFI.

In an embodiment of the twelfth aspect of the present application, the token further includes: identification information of the container service instance; wherein, the identification information of the container service instance is used to send the VNFI to the container service instance The container service instance corresponding to the identification information requests service.

In the thirteenth aspect, the embodiments of the present application also provide a computer-readable storage medium, including instructions, which when run on a computer, cause the computer to execute the first, second, third or fourth aspects of the present application. The method of any one of aspects.

In a fourteenth aspect, an embodiment of the present application provides an NFV system, the system includes the device described in the fifth aspect and the device described in the sixth aspect; or, the system includes the device described in the seventh aspect. The device and the communication device according to the eighth aspect; or, the system includes the VNFI according to the ninth aspect and the container manager according to the tenth aspect; or, the system includes the eleventh aspect VNFM and the container manager described in the twelfth aspect above.

Description of the drawings

Figure 1 is a schematic structural diagram of an embodiment of an NFV system;

2 is a schematic flowchart of an embodiment of a container service management method provided by this application;

3 is a schematic flowchart of an embodiment of a container service management method provided by this application;

4 is a schematic flowchart of an embodiment of a container service management method provided by this application;

FIG. 5 is a schematic flowchart of an embodiment of a container service management method provided by this application;

Figure 6 is a schematic structural diagram of another embodiment of an NFV system;

FIG. 7 is a schematic structural diagram of a container service management device provided by this application;

FIG. 8 is a schematic structural diagram of a device for executing a container management method provided by this application.

Detailed ways

The container service management method and device provided by each embodiment of the present application can be applied to a network function virtualization (NFV) system. Before formally introducing the application, the NFV system applied in each embodiment of the application and the problems existing in the prior art will be described with reference to FIG. 1.

Figure 1 is a schematic diagram of the structure of the NFV system. As shown in Figure 1, the NFV system is a technology that uses universal hardware and network virtualization to build a communication network system. Among them, the NFV system includes: operation support system/business support system (operation support system/business support system, OSS/ BSS)11, element management system (EMS), virtualized network function (VNFI), container service instance, network function virtualization infrastructure: virtual machine (VM), network function Virtualized orchestrator (NFV orchestrator, NFVO) 16, virtualized network function management (VNFM) 17, container manager 18, and virtualized infrastructure manager (VIM) 19.

VNFM17 is used to manage the VNFI and perform various management functions, such as initialization, update, query, and/or termination of the VNFI. The VNFM 17 instantiates a virtualized network function (virtualized network function) VNF to obtain the VNFI. One VNFM can manage at least one VNFI. For example, the VNFM 17 in FIG. 1 can manage VNFI131, VNFI132, and VNFI133.

When the VNFM17 instantiates the VNF, it can be obtained that the VNFI can be deployed on the virtual machine VM, and perform its related functions as a network element as a softwareized network element. For example, in the example shown in Figure 1, VNFI 131 is deployed on VM151, VNFI132 is deployed on VM152, and VNFI133 is deployed on VM153.

OSS/BSS11 provides integrated network management and business operation functions for telecom service operators, including network management (such as fault monitoring, network information collection, etc.), billing management, and customer service management.

NFVO16 is used to manage the life cycle of VNFI, orchestrate management resources to implement VNFI services according to the service request of OSS/BSS11, and to monitor VNFI, network function virtualization infrastructure resources and operating status information in real time.

Each VNFI corresponds to a physical network function (physical network function, PNF for short) in a traditional non-virtualized network, such as a virtualized evolved packet core (EPC) node. For example, virtualized EPC nodes include: mobile management entity (mobile management entity, MME), serving gateway (serving gateway, SGW), packet data network gateway (packet data network gateway, PGW), etc.

EMS can be used to manage one or more VNFIs. For each managed VNF13, it can implement fault management, configuration management, billing management, performance management, and security management (Fault Management, Configuration Management, Accounting Management, Performance Management, Security) of VNF13. Management, FCAPS) function. For example, in the example shown in FIG. 1, EMS121 is used to manage VNFI131, EMS122 is used to manage VNFI132, and EMS123 is used to manage VNFI133.

VIM 19 can be used to control and manage the network function virtualization infrastructure corresponding to VNFI. The network function virtualization infrastructure can include computing hardware, storage hardware, hardware resource layer composed of network hardware, virtualization layer, and virtual computing (such as virtual computing). Machine), virtual storage and virtual network. In the system example shown in Fig. 1, the network function virtualization infrastructure is implemented through a virtual machine (virtual machine, VM).

The NFV system mainly includes the following related interfaces:

Ve-Vnfm: Between VNFM and EMS, VNFM and VNFI, used for VNF life cycle management and exchange configuration information.

Or-Vnfm: Between NFVO and VNFM, it is used for VNF life cycle management to request resources, send configuration information, and collect status information.

Vi-Vnfm: between VNFM and VIM, used for resource allocation request, virtualized resource configuration and status information exchange.

Or-Vi: Between NFVO and VIM, it is used for resource reservation, allocation request, virtualized resource configuration and status information exchange.

Nf-Vi: between VIM and VM, used for specific resource allocation, virtual resource status information exchange, and hardware resource configuration.

Vn-Nf: Between VM and VNF, used for VM to provide actual execution environment to VNF.

Os-Ma: VNFI life cycle management, NS life cycle management, strategy management, etc.

Cm-Vnfm: Between the VNFM and the container manager, it is used for the management of container service calls and queries.

Nf-K8S: Between the container service instance and the container manager, it is used for the management of container service creation, deletion, and update.

Vi-K8S: Between the container manager and VIM, it is used to request and call container resources.

At the same time, the container service instance 14 can provide VNFI with services such as load balancing in the form of a virtualized container. When the VNFI uses the service provided by the container service instance 14, it needs to request the container service instance 14 to provide the service for the VNFI from the container manager 18 for managing the container service instance 14. In the existing NFV system, the service authorization mechanism based on Oauth2.0 is usually adopted.

For example, in the NFV system shown in Figure 1, when VNFI131 needs to use the service provided by the container service instance, VNFI131 sends a token request to the container manager 18 through VNFM17 to obtain the container service from the container manager 18. Token. Then when the container manager 18 receives the VNFI service application, it authorizes the container service that VNFI131 can use, generates a token corresponding to the VNFI131 requesting the service, and returns it to the VNFI131 sending the service application through VNFM17; the token includes the VNFI131 The identification information (instance id), the container service instance that the VNF can use, and the expiration time for the VNF to use the container service instance. The token is used to ensure that the VNFI uses the container service instance to verify the VNFI and ensure that the container service instance can only Provide services to the VNFI (VNFI131) corresponding to the token. Subsequently, VNFI 13 sends a service request to the corresponding container service instance 141 according to the received token, and carries the token in the service request. When the container service instance 141 receives the service request sent by the VNFI131, it verifies the token in the service request, and after the token verification is passed, the container service instance 141 provides the container service to the VNFI131.

In the prior art, the supplier of the NFV system will set up multiple VNFMs to manage their respective VNFIs according to business requirements; and, the VNFMs set by the suppliers of different NFV systems must be different, and the VNFMs set by the different suppliers manage their respective VNFMs. VNFI. However, in the prior art, even if different VNFMs manage their own different VNFIs, all VNFMs will assign instant IDs to the VNFIs managed by the VNFM itself according to the same rules and sequence, resulting in the management of VNFMs belonging to different VNFMs. VNFI may have the same instant ID. For example: VNFM1 in a certain NFV system assigns instant IDs to the VNFIs it manages as A1, B2, and C3; while VNFM2 in another NFV system assigns instant IDs to VNFIs it manages as A1. B2 and C3.

Therefore, in the above scenario, the token requested by the VNFI11 managed by VNFM1 from the container manager is stolen by the VNFI21 managed by a different VNFM2, assuming that the instant ID assigned by VNFM1 to VNFI11 and the instant ID assigned by VNFM2 to VNFI21 If the assigned instant ID is the same, VNFI21 obtained by stolen token can directly use the container manager to request service from the container service instance from the token assigned by VNFI11, and the container service instance will still provide it to the VNFI21 who stolen the token after the token is verified. Container service, which in turn causes the security performance of the token to be low.

Therefore, based on the above technical problems, this application proposes a container service management method and device to improve the security performance of the token used when the VNFI requests services provided by the container service instance in the NFV system.

The container service management method and device provided by the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a schematic flow chart of an embodiment of a container service management method provided by this application. The embodiment shown in Fig. 2 can be applied to the NFV system shown in Fig. 1, and objects in the NFV system execute the corresponding method , The container service management method provided in this embodiment includes:

S101: The VNFI sends a token request to the container manager to request the token used when the VNFI requests services from the container service instance; wherein the token request includes identification information of the VNFI and identification information of the VNFM used to manage the VNFI.

Specifically, when VNFI determines that it needs to use the container service provided by the container service instance, it needs to send a token request to the container manager used to manage the container service instance, so that the container manager can perform processing on the container service provided by VNFI using the container service example. Authorize and generate token. Wherein, the token request is used to request from the container manager the token used when VNFI requests a service from the container service example. Correspondingly, the container manager receives the token request sent by VNFI in S101.

In particular, the token request described in this embodiment includes: identification information of the VNFI and identification information of the VNFM used to manage the VNFI. Wherein, the identification information of the VNFI may be the VNFM used to manage the VNFI, and the instant ID assigned to the VNFI when the VNF is instantiated as the VNFI. Optionally, the instant ID allocated by the VNFM to the VNFI may be a string of characters such as "vnf-AMF-123", or may be a string of random numbers, such as "0x4257369973". This application does not limit the specific representation of the instant ID assigned by the VNFM to the VNFI. The identification information of the VNFM may be the VNFM ID used to identify the VNFM in the NFV system. Optionally, the VNFM ID may be a character such as "vnfm-EPC-123", or may be a string of random numbers, such as "0x4257369973". This application does not limit the specific representation of the VNFM ID in the NFV system.

Optionally, in a specific implementation of this embodiment, the token request specifically includes: "VNFI identification information, VNFM identification information, the requested service name (Expected service name), and the requested token Expiration".

For example, if a VNFI needs to use the load balancing service provided by the target container service instance, the VNFI needs to obtain authorization to use the container service instance from the container manager that manages the target container service instance, then the VNFI can send a token to the container manager Request to apply for the container manager to authorize VNFI to use the load balancing service provided by the target container service example, and provide tokens for VNFI. At the same time, the token sent by VNFI to the container manager also needs to carry the deadline of the requested token. Before the deadline, when VNFI can use the token to send service requests to the target container service instance, the target container service instance can provide VNFI Load balancing service; after the deadline, if VNFI continues to use the token to send service requests to the target container service example, the target container service example will no longer provide load balancing services to VNFI.

Exemplarily, the token sent by the VNFI to the container manager in this embodiment may include: "VNFI instant ID (vnf-AMF-123), VNFM ID (vnfm-EPC-123), VNFI requested load Balanced service name (load balance) and deadline (2020-01-01)".

Optionally, during or after the specific instantiation of the VNFI, a token request is sent to the container manager through S101. Among them, the VNFM specifically instantiates the VNF to obtain the VNFI. The implementation manner and principle of VNFM instantiating VNF can refer to the prior art, which is not limited in this embodiment.

S102: After receiving the token request sent by the VNFI through S101, the container manager authorizes the VNFI to use the service provided by the container service instance according to the token request, and generates a token corresponding to the VNFI; wherein the token includes: VNFI identification information And VNFM identification information.

Specifically, the token generated by the container manager in this embodiment includes: VNFI identification information and VNFM identification information. Wherein, the identification information of the VNFI may be the VNFM used to manage the VNFI, the instant ID assigned to the VNFI when the VNF is instantiated as the VNFI, and the identification information of the VNFM may be the VNFM ID used to identify the VNFM in the NFV system. The identification information of the VNFI and the identification information of the VNFM included in the token are used by the container service instance to verify the VNFI that uses the token to request services.

Optionally, the container manager may specifically determine the identification information of the VNFI and the identification information of the VNFM through the token request received in S101.

In a specific implementation manner, the token generated by the container manager in S102 specifically includes: after the container manager generates a claim (declaration) part according to the token request, it is signed by the container manager to obtain the token. Among them, the container manager can use the symmetric key shared with the container service instance to sign, and the subsequent container service instance can verify the token according to the symmetric key; or, the container manager can use the private key of the container manager to sign , The subsequent container service instance can verify the token according to the public key of the container manager.

For example, the claim in the token generated by the container manager in this embodiment includes:

1. ID of service management: The ID of the container service instance manager. That is, the identification information of the container manager is used to identify the container manager that generated the token.

2. VNF Instance ID of the service consumer and VNFM ID of the service consumer: the identification information of the VNFI requesting the container service and the identification information of the VNFM used to manage the VNFI. That is, the Instance ID of the VNFI and the VNFM ID of the VNFM.

3. Service name of the producers: the service name of the container service instance that can provide container services. Among them, because in the NFV system, the container service instance requested by the VNFI is usually a resource pool scenario such as load balancing, the VNFI can request container services from multiple container service instances through a token. Then the token generated by the container manager usually only carries the service name that the container service instance can provide, and the VNFI specifically determines to apply for service from one or more container service instances.

4. Expiration time: Expiration time. That is, before the deadline, when VNFI uses the token to send a service request to the container service instance, the container service instance will provide the container service to VNFI; and after the deadline, the token expires, VNFI uses the token to send services to the container service instance When requested, the container service instance will not provide container services to VNFI.

S103: The container manager sends the token generated in S102 to the VNFI, so that the VNFI can request the container service from the container service instance according to the token received by the VNFI.

Subsequently, after the container manager authorizes the VNFI according to the token request in S102 and generates the VNFI token, the container manager sends the generated token to the VNFI, so that the VNFI can send the token to the VNFI after obtaining the container manager’s token. The corresponding container service instance requests the container service.

Further, in order to implement the embodiment shown in FIG. 2, this application also provides an NFV system, wherein FIG. 6 is a schematic structural diagram of another embodiment of the NFV system. The NFV system shown in Figure 6 is based on the NFV system shown in Figure 1. The VNFI and the container manager also include a Ve-Cm interface for VNFI to request an authorized container service instance from the container manager, then the VNFI The token request can be sent to the container manager through the Ve-Cm interface, and the token sent by the container manager can be received through the Ve-Cm interface.

In summary, in the container service management method provided in this embodiment, when the VNFI needs to use the service provided by the container service instance, it sends a token request carrying the identification information of the VNFI and the identification information of the VNFM to the container manager to the container manager. When the container manager receives the token request sent by the VNFI, the token generated according to the token request also includes the identification information of the VNFI and the identification information of the VNFM. Finally, after the container manager sends the generated token to VNFI, VNFI can request service from the container service instance based on the received token.

In particular, since the token generated in this embodiment includes the identification information of the VNFM, when the VNFI requests services from the container service instance based on the token, the container service instance will not only verify the identification information of the VNFI in the token, but also verify the VNFM in the token. The identification information of the VNFI is verified. Only after the identification information of the VNFI and the identification information of the VNFM are both verified, the container service instance will be provided by the VNFI. For two different VNFIs managed by two VNFMs, even if they have the same VNFI identification information, because the two VNFMs have different identification information, and the container service instance will also perform the VNFM identification information when the VNFI requests the container service Verification, therefore, when a VNFI applies for a token to the container manager, even if its token is stolen by another VNFI, the identification information of the VNFM in the token sent by the stolen VNFI is different from the actual VNFM identification information of the VNFI. The container service If the instance fails to verify the token, the container service instance will not provide container services to the VNFI that steals the token.

As a result, even if the token is stolen by other VNFIs across VNFMs, the VNFI that stolen the token cannot use the service provided by the container service instance based on the token, which ensures that the token generated by the container manager for a certain VNFI is stolen by VNFIs managed by different VNFMs. However, it cannot be used later, which improves the security performance of the token used when VNFI requests the service provided by the container service instance in the NFV system.

In the following, in conjunction with FIG. 3, in this embodiment, after the VNFI obtains a token through the embodiment shown in FIG. 2, the VNFI uses the token to request a service from the container service instance.

3 is a schematic flow chart of an embodiment of a container service management method provided by this application, where this embodiment can be applied to the VNF system shown in FIG. 1, where the VNFI requests services from the container service instance. As shown in FIG. 3, the container service management method provided by this embodiment, after S103 shown in FIG. 1, further includes:

S104: The VNFI sends a service request to the container service instance; the service request carries the token requested in S103.

Specifically, after VNFI receives the token in S103, it can request service from the container service instance corresponding to the token. Among them, the VNFI sends a service request to the container service instance that can provide the requested service according to the service name of the container service instance that can provide the container service included in the token, so as to request the container service instance to provide the service to the VNFI. Among them, the service request sent by the VNFI to the container service instance carries the token applied by the first device to the container manager in the embodiment shown in FIG. 2.

S105: After the container service instance receives the service request sent by the VNFI, it can verify the token according to the public key of the container manager to determine whether the token is generated by the container manager. Moreover, in this embodiment, the container service instance is further based on whether the identification information of the VNFI that sends the service request and the identification information of the VNFM that manages the VNFI is related to the identification information of the VNFI and the identification information of the VNFM included in the token in the service request. Consistent.

For example, in this embodiment, the identification information of the VNFI that sends the service request to the container service instance is recorded as A, and the identification information of the VNFM used to manage the VNFI is recorded as B; the identification information of the VNFI included in the token is recorded as C , And mark the identification information of the VNFM recorded in the token as D. Subsequently, the container service instance judges whether A and C are consistent, B and D are consistent, and only after A and C are consistent and B and D are consistent, the container service instance will execute the subsequent S203, that is, the container service instance provides services to VNFI .

It is understandable that, as shown in Figure 3, the VNFI requests the container manager to authorize the service provided by the container service instance, so that the container manager generates a token containing the identification information of the VNFI and the identification information of the VNFM for the VNFI. . Therefore, after VNFI obtains the token generated and sent by the container manager, it can carry the token when requesting services from the container service instance. At this time, the container service instance can successfully verify the identification information of the VNFI, the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNMF in the token. Therefore, in S106, the container service instance provides services to the VNFI, and correspondingly, the VNFI uses the service provided by the container service instance.

In particular, in the embodiment shown in FIG. 3, it is shown that the VNFI requesting a token from the container manager uses the requested token to request a service from the container service instance. In the embodiment shown in FIG. 4, the process of requesting service from the container service instance by the VNFI of the stolen token is shown. FIG. 4 is a schematic flowchart of an embodiment of the container service management method provided by this application.

If the VNFI as shown in FIG. 3 applies for a token from the container manager, if it is stolen by the VNFI as shown in FIG. 4, the VNFI with the stolen token can send a service request to the container service instance through S201, and carry the stolen token.

At this point, in S202, after receiving the service request through S201, the container service instance will also verify the token, verifying whether the VNFI identification information and VNMF identification information included in the token are consistent with the VNFI identification information that sent the service request Whether the information and the identification information of the VNFM are the same.

Obviously, if the VNFI identification information of the stolen token is different from the VNFI identification information of the original VNFI, the container service instance fails to verify the token and will not provide services to the stolen VNFI, that is, step S203 in the figure will not be performed. If the VNFI identification information of the VNFI with the stolen token is the same as the VNFI identification information of the original VNFI, since two different VNFMs are assigned to the two VNFIs respectively, the identification information of the VNFM of the VNFI with the stolen token is the same as that of the original VNFI. The identification information of the VNFM is different. The container service instance fails to verify the token, and the container service instance will also not provide services to the VNFI that embezzled the token.

In summary, it can be seen from the embodiments shown in Figures 3 and 4 that after VNFI obtains the token provided by the container manager, it can request service from the corresponding container service instance according to the token; then the corresponding container service instance The token needs to be verified to determine whether it can provide services to VNFI. Since the token includes the identification information of the VNFI and the identification information of the VNFM, when the container service instance verifies the token, it needs to verify the identification information of the VNFI and the identification information of the VNFM. Only after the two are verified to be consistent , The container service instance is determined to be able to provide services to VNFI. Therefore, the verification of the token is strengthened through the identification information of the VNFI and the identification information of the VNFM carried in the token, so that after the token is stolen by the VNFI across VNFM, even if the identification information of the VNFI is the same, the container service will be due to the different identification information of the VNFM. The instance fails to pass the verification, which improves the security performance of the token used when VNFI requests the service provided by the container service instance.

Further, on the basis of the foregoing embodiments, this application also provides another specific implementation manner of claim in the token generated by the container manager. Among them, the claim in the token generated by the container manager includes:

1. ID of service management: The ID of the container service instance manager.

2. VNF Instance ID of the service consumer and VNFM ID of the service consumer: The identification information of the VNFI and the identification information of the VNFM that request the container service.

3. Service ID of the producers: the identification information of the container service instance that can provide the container service. The identification information of the container service instance is set by the container manager, and it can be a string of characters assigned by the container manager when managing the container service instance, such as "LB-CONTAINER-service", or it can be a string of random numbers such as "0x254830203", this application does not limit the specific representation of the identification information of the container service instance.

4. Expiration time: Expiration time.

Specifically, in the specific implementation of the claim in the token provided in this embodiment, the specific descriptions of 1, 2, and 4 included in the claim, and the specific method of generating the token by the container management server can refer to the embodiment shown in FIG. 2. No longer.

The difference is that the claim of this embodiment includes the identification information of the container service instance that can provide the container service. That is, when the container manager authorizes the VNFI for the container service instance, it further determines the identification of the specific container service instance that the VNFI can use. Information, limiting VNFI can only request services from specific container service instances from the identification information included in the token.

Optionally, the token provided in this example can be applied to the embodiment shown in FIG. 3, and the VNFI needs to request service from the corresponding container service instance according to the identification information of the container service instance in the token. For the container service instance to verify whether to provide services to VNFI, it is also necessary to verify the identification information of the container service instance included in the token.

For example, in S105 shown in Figure 3, after obtaining the token carried in the service request sent by VNFI, the container service instance verifies the identification information of the container service instance included in the token. If the container service instance determines that the token includes the token The identification information of the container service instance is determined to provide services to the VNFI; and if the container service instance determines that the token does not include the identification information of the container service instance, it means that the VNFI has not applied for the service from the correct container service instance, and the container service instance does not Provide services to VNFI.

Therefore, in the specific implementation of the claim provided in this embodiment, when the container manager generates a VNFI token, the VNFI directly carries the VNFI in the token, and can provide the VNFI with the identification information of the container service instance requested by the token. The scope of the container service instance is limited. As a result, VNFI needs to request service from the container service instance specified by the container manager in the token, and once the token is stolen across VNFM, other VNFIs cannot request service from the container service instance in the VNF system where the original token is located, which can also enhance the token. The security performance makes the token unusable after being stolen across VNFM.

Further, in the above-mentioned embodiment shown in Figs. 2-4 of this application, a method is provided in which VNFI sends a token request to the container manager and directly receives the token sent by the container manager. In another implementation of this application, the VNFM that manages the VNFI can also send a token request to the container manager instead of the VNFI, and forward the received token to the VNFI, so that the VNFI can request service from the container service instance .

The following describes with reference to FIG. 5, where FIG. 4 is a schematic flowchart of an embodiment of a container service management method provided by this application. The method provided in this embodiment includes:

S301: If the VNFI managed by the VNMF needs to use the service provided by the container service instance, the VNFM sends a token request to the container manager that manages the container service instance. The token request is used to request from the container manager that the VNFI service the container. The token used when the sample requests the service. Correspondingly, the container manager receives the token request sent by the VNFM in S301.

In particular, the token request described in this embodiment includes: identification information of the VNFI and identification information of the VNFM used to manage the VNFI.

Optionally, during the process of VNFM instantiating the VNFI, or after the VNFM instantiating the VNFI, the VNFM sends a token request to the container manager through S301. Among them, the VNFM specifically instantiates the VNF to obtain the VNFI. The implementation manner and principle of VNFM instantiating VNF can refer to the prior art, which is not limited in this embodiment.

It should be noted that this embodiment emphasizes that VNFM replaces VNFI to send a token request to the container server. For the specific implementation of the VNFI identification information and VNFM identification information included in the token request, please refer to the description in the embodiment in FIG. 2 ,No longer.

Optionally, since the VNFM allocates identification information to the VNFI when instantiating the VNFI, such as the instant ID of the VNFI, the VNFM can determine the identification information allocated to the VNFI before sending the token request to the container manager, then in S301 VNFM combines the identification information of the VNFM itself, and the VNFM can carry the identification information of the VNFI and the identification information of the VNFM together in the token and send it to the container manager. In this embodiment, the VNFM plays the role of applying for a token from the container manager instead of the VNFI, and forwarding the token generated by the container manager to the VNFI.

S302: After receiving the token request sent by the VNFM through S301, the container manager authorizes the VNFI to use the service provided by the container service instance according to the token request, and generates a token corresponding to the VNFI; wherein the token includes: VNFI identification information And VNFM identification information.

For the specific implementation of the identification information of the VNFI and the identification information of the VNFM included in the token in this embodiment, reference may be made to the description in the embodiment of FIG. 2 and will not be repeated.

Subsequently, after the token is generated, the container manager sends the token to the VNFM through S303.

When the VNFM receives the token sent by the container manager, the VNFM is further sent to the VNFI through S304. Accordingly, after the VNFI receives the token sent by the VNFM in S305, it can request service from the container service instance based on the token, and the VNFI sends the container For the specific process of the service instance requesting service, please refer to the embodiment of S104-S106 shown in FIG. 3, which is not repeated here.

It is understandable that the container service management method provided in this embodiment can be applied to the NFV system as shown in Figure 1. After the VNFM instantiates the VNF through the Ve-Vnfm interface to obtain the VNFI, the VNFM sends the VNFM through the Cm-Vnfm interface. The container manager sends a token request; the VNFM also receives the token sent by the container manager through the Cm-Vnfm interface, and sends the token to the VNFI through the Ve-Vnfm interface.

In the embodiments provided by the foregoing embodiments of the present application, the methods provided by the present application are introduced and explained from the perspectives of VNFI, VNFM, and container manager. In order to realize the functions in the methods provided in the foregoing embodiments of the present application, VNFI, The VNFM and the container manager may include a hardware structure and/or a software module, and the above functions are implemented in the form of a hardware structure, a software module, or a hardware structure plus a software module. Whether one of the above-mentioned functions is executed in a hardware structure, a software module, or a hardware structure plus a software module depends on the specific application and design constraint conditions of the technical solution.

For example, FIG. 7 is a schematic structural diagram of a container service management apparatus provided by this application. The apparatus shown in FIG. 7 includes: a receiving module 701, a processing module 702, and a sending module 703.

When the container service management apparatus shown in FIG. 7 is the VNFI in the embodiment shown in FIG. 2-3, the sending module 703 is used to send the service provided by the container service instance if the virtual network function instance VNFI needs to use the service provided by the container service instance. The container manager of the container service instance sends a token request; the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The receiving module 701 is used to receive the token sent by the container manager; among them, the token includes the identification information of VNFI and the identification information of VNFM. The identification information of VNFI and the identification information of VNFM are used by the container service instance to perform the VNFI request service using the token. verification.

Optionally, the sending module is also used to send a service request to the container service instance, the service request includes a token, so that the container service instance verifies the VNFI according to the identification information of the VNFI and the identification information of the VNFM in the token; the processing module uses Therefore, if the verification is successful, use the service provided by the container service instance.

Optionally, the token also includes: identification information of the container service instance; the sending module is specifically configured to send a service request to the container service instance corresponding to the identification information of the container service instance according to the token.

Optionally, the sending module 703 is specifically configured to send a token request to the container manager when the VNFM instantiates the VNFI; or, after the VNFM instantiates the VNFI, send a token request to the container manager.

The container service management apparatus provided in this embodiment can specifically implement the container service management method in the embodiment shown in FIG. 2-3, and the implementation method and principle are the same, and will not be repeated.

When the container service management apparatus shown in FIG. 7 is the container manager in the embodiment shown in FIG. 2-3, the receiving module 701 is configured to receive a token request sent by the virtual network function instance VNFI; among them, VNFI requires Using the service provided by the container service instance managed by the container manager, the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI; the processing module 702 is used to generate the token according to the token request; Wherein, the token includes the identification information of the VNFI and the identification information of the VNFM. The identification information of the VNFI and the identification information of the VNFM are used for the container service instance to verify the VNFI using the token to request the service; the sending module 703 is used for sending the token to the VNFI.

Optionally, the token also includes: the identification information of the container service instance; where the identification information of the container service instance is used for VNFI to request service from the container service instance corresponding to the identification information of the container service instance.

When the container service management apparatus shown in FIG. 7 is the VNFM in the embodiment shown in 5, the sending module 703 is used if the virtual network function instance VNFI managed by the virtual network function manager VNFM needs to use the service provided by the container service instance , Send a token request to the container manager used to manage the container service instance; wherein the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI; the receiving module 701 is used to receive the container The token sent by the manager is sent to the VNFI through the sending module; the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for the container service instance to request services using the token VNFI for verification.

Optionally, the token also includes: the identification information of the container service instance; the identification information of the container service instance is used for VNFI to request service from the container service instance corresponding to the identification information of the container service instance.

Optionally, the sending module is specifically configured to send a token request to the container manager when the VNFM instantiates the VNFI; or, after the VNFM instantiates the VNFI, send a token request to the container manager.

The container service management apparatus provided in this embodiment can specifically implement the container service management method in the embodiment shown in FIG. 5, and its implementation manner and principle are the same, and will not be repeated.

When the container service management apparatus shown in FIG. 7 is the container manager in the embodiment shown in 5, the receiving module 701 is used to receive a token request sent by the virtual network function manager VNFM; among them, the virtual network function manager VNFM The network function instance VNFI needs to use the service provided by the container service instance managed by the container manager,

The token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI; the processing module 702 is used to generate the token according to the token request; among them, the token includes the identification information of the VNFI and the identification information of the VNFM The identification information of the VNFI and the identification information of the VNFM are used for the container service instance to verify the VNFI using the token request service; the sending module 703 is used for sending the token to the VNFM so that the VNFM sends the token to the VNFI.

The division of modules in the foregoing embodiments of the present application is illustrative, and is only a logical function division. In actual implementation, there may be other division methods. In addition, the functional modules in the various embodiments of the present application may be integrated in A processor may also exist alone physically, or two or more modules may be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or software functional modules.

Further, FIG. 8 is a schematic structural diagram of a device for executing the container management method provided by this application. The device shown in FIG. 8 includes a communication interface 1010, a processor 1020, and a memory 1030. Wherein, the communication interface 1010 may be a transceiver, a circuit, a bus, or other forms of interfaces for communicating with other devices through a transmission medium; the communication interface 1010, the processor 1020 and the memory 1030 are coupled, the coupling in the embodiment of the present application It is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms, used for information exchange between devices, units or modules.

The embodiment of the present application does not limit the specific connection medium between the communication interface 1010, the processor 1020, and the memory 1030. In the embodiment of the present application in FIG. 8, the communication interface 1010, the memory 1030, and the processor 1020 are connected by a bus 1040. The bus is represented by a thick line in FIG. 8. The connection mode between other components is only for schematic illustration. , Is not limited. The bus can be divided into address bus, data bus, control bus, etc. For ease of presentation, only one thick line is used in FIG. 8 to represent, but it does not mean that there is only one bus or one type of bus.

Exemplarily, if the device shown in FIG. 8 is the VNFI shown in FIG. 2-3, the memory 1030 stores code. When the processor 1020 calls and executes the instruction, if the VNFI needs to use the container service instance To provide services, the processor 1020 sends a token request to the communication interface; where the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI; the communication interface 1010 receives the processor 1020's transmission And send the token request to the container manager for managing the container service instance; the communication interface 1010 is also used to receive the token sent by the container manager and send the token to the processor 1020; where the token includes VNFI identification information and VNFM identification information, VNFI identification information and VNFM identification information are used by the container service instance to verify the VNFI that uses the token to request the service.

Optionally, when the processor 1020 calls and executes the instruction, the processor 1020 is further configured to send a service request to the communication interface 1010, and the service request includes the token, so that the container service instance can be based on the identification information of the VNFI in the token. Verify the VNFI with the identification information of the VNFM;

The communication interface 1010 is also used to receive the service request sent by the processor 1020 and send the service request to the container service instance; if the verification is successful, the processor 1020 is also used to use the service provided by the container service instance.

Optionally, the token also includes: identification information of the container service instance pair; the communication interface 1010 is specifically used to send the service request to the container service instance corresponding to the identification information of the container service instance.

Optionally, the processor 1020 is specifically configured to send a token request to the communication interface when the VNFM instantiates the VNFI; or the processor 1020 is specifically configured to, after the VNFM instantiates the VNFI, Send the token request to the communication interface.

For another example, if the device shown in FIG. 8 is the container manager shown in FIG. 2-3, the communication interface 1010 is used to receive the token request sent by the virtual network function instance VNFI, and send the token request To the processor 1020; where the VNFI needs to use the service provided by the container service instance managed by the container manager, and the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI; then the storage Code is stored in 1030. When the processor 1020 calls and executes the instruction, the processor 1020 is used to generate a token according to the token request, and send the token to the communication interface 1010; among them, the token includes the identification information of VNFI and the identification of VNFM Information, the identification information of the VNFI and the identification information of the VNFM are used for the container service instance to verify the VNFI using the token to request the service; the communication interface 1010 is also used to send the token to the VNFI.

Exemplarily, if the device shown in FIG. 8 is the VNFM shown in FIG. 5, code is stored in the memory 1030. When the processor 1020 calls and executes the instruction, if the virtual network function instance VNFI managed by the VNFM is The service provided by the container service instance needs to be used, and the processor 1020 is used to send a token request to the communication interface 1010; wherein the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI; The communication interface 1010 is used to send a token request to the container manager for managing service instances; the communication interface 1010 is also used to receive the token sent by the container manager and send the token to VNFI; wherein the token includes the identification information of the VNFI And the identification information of the VNFM, the identification information of the VNFI and the identification information of the VNFM are used for the container service instance to verify the VNFI that uses the token to request the service.

Exemplarily, if the device shown in FIG. 8 is the container manager shown in FIG. 5, the communication interface 1010 is used to receive a token request sent by the virtual network function manager VNFM, and send the token request to the processing The virtual network function instance VNFI managed by the VNFM needs to use the service provided by the container service instance managed by the container manager. The token request includes the identification information of the VNFI and the virtual network function manager VNFM used to manage the VNFI Identification information; the memory 1030 stores code, when the processor 1020 calls and executes the instruction, the processor 1020 is used to generate a token according to the token request, and send the token to the communication interface 1010; wherein the token includes the VNFI identification Information and VNFM identification information, VNFI identification information and VNFM identification information are used by the container service instance to verify the VNFI using the token request service; the communication interface 1010 is also used to send the token to the VNFM so that the VNFM can send the token To VNFI.

In the embodiments of the present application, the processor may be a general-purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and may implement or Perform the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

In the embodiment of the present application, the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or a volatile memory (volatile memory), for example Random-access memory (random-access memory, RAM). The memory is any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. The memory in the embodiments of the present application may also be a circuit or any other device capable of realizing a storage function, for storing program instructions and/or data.

The methods provided in the embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer may be a general-purpose computer, a dedicated computer, a computer network, network equipment, user equipment, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center. Transmission to another website, computer, server, or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center integrated with one or more available media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a digital video disc (digital video disc, DVD for short)), or a semiconductor medium (for example, SSD).

Obviously, those skilled in the art can make various changes and modifications to the application without departing from the scope of the application. In this way, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalent technologies, this application also intends to include these modifications and variations.

Claims

A container service management method is characterized in that it includes:

If the virtual network function instance VNFI needs to use the service provided by the container service instance, the VNFI sends a token request to the container manager for managing the container service instance; wherein the token request includes the identification information of the VNFI, And the identification information of the virtual network function manager VNFM used to manage the VNFI;

The VNFI receives the token sent by the container manager; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for all The container service instance verifies the VNFI that uses the token to request the service.
The method according to claim 1, wherein after the VNFI receives the token sent by the container manager, the method further comprises:

The VNFI sends a service request to the container service instance, where the service request includes the token, so that the container service instance can pair the VNFI identification information and the VNFM identification information in the token The VNFI performs verification;

If the verification is successful, the VNFI uses the service provided by the container service instance.
The method according to claim 2, wherein:

The token also includes: identification information of the container service instance;

The VNFI sending a service request to the container service instance according to the token includes:

The VNFI sends a service request to the container service instance corresponding to the identification information of the container service instance according to the token.
The method according to any one of claims 1-3, wherein the sending of the token request by the VNFI to the container manager comprises:

When the VNFM instantiates the VNFI, the VNFI sends the token request to the container manager;

or,

After the VNFM instantiates the VNFI, the VNFI sends the token request to the container manager.
A container service management method is characterized in that it includes:

The container manager receives the token request sent by the virtual network function instance VNFI; wherein the VNFI needs to use the service provided by the container service instance managed by the container manager, and the token request includes the identification information of the VNFI , And the identification information of the virtual network function manager VNFM used to manage the VNFI;

The container manager generates a token according to the token request; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for all The container service instance verifies the VNFI that uses the token to request service;

The container manager sends the token to the VNFI.
The method of claim 5, wherein:

The token also includes: identification information of the container service instance; wherein the identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.
A container service management method is characterized in that it includes:

If the virtual network function instance VNFI managed by the virtual network function manager VNFM needs to use the service provided by the container service instance, the VNFM sends a token request to the container manager for managing the container service instance; wherein, in the token request Including the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The VNFM receives the token sent by the container manager, and sends the token to the VNFI; wherein, the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification of the VNFI The information and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request the service.
The method according to claim 7, wherein:

The token also includes: identification information of the container service instance;

The identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.
The method according to claim 7 or 8, wherein the sending of the token request by the VNFM to the container manager comprises:

When the VNFM instantiates the VNFI, the VNFM sends the token request to the container manager;

or,

After the VNFM instantiates the VNFI, the VNFM sends the token request to the container manager.
A container service management method is characterized in that it includes:

The container manager receives the token request sent by the virtual network function manager VNFM; wherein the virtual network function instance VNFI managed by the VNFM needs to use the service provided by the container service instance managed by the container manager, and the token request Includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The container manager generates a token according to the token request; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, and the identification information of the VNFI and the identification information of the VNFM are used for all The container service instance verifies the VNFI that uses the token to request service;

The container manager sends the token to the VNFM, so that the VNFM sends the token to the VNFI.
The method according to claim 10, wherein:

The token also includes: identification information of the container service instance; wherein the identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.
A virtual network function instance VNFI, which is characterized by comprising: a processor and a communication interface;

If the VNFI needs to use the service provided by the container service instance, the processor is configured to send a token request to the communication interface; wherein, the token request includes the identification information of the VNFI and is used to manage the VNFI The identification information of the virtual network function manager VNFM;

The communication interface is used to send the token request to a container manager for managing the container service instance;

The communication interface is also used to receive the token sent by the container manager and send the token to the processor; wherein the token includes the identification information of the VNFI and the identification information of the VNFM The identification information of the VNFI and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request the service.
The VNFI according to claim 12, wherein:

The processor is further configured to send a service request to the communication interface, and the service request includes the token, so that the container service instance can be based on the identification information of the VNFI and the VNFM in the token. To verify the VNFI;

The communication interface is also used to send the service request to the container service instance;

If the verification is successful, the processor is further configured to use the service provided by the container service instance.
The VNFI according to claim 13, wherein:

The token also includes: identification information of the container service instance pair;

The communication interface is specifically configured to send the service request to the container service instance corresponding to the identification information of the container service instance.
The VNFI according to any one of claims 12-14, wherein:

The processor is specifically configured to send the token request to the communication interface when the VNFM instantiates the VNFI;

Alternatively, the processor is specifically configured to send the token request to the communication interface after the VNFM instantiates the VNFI.
A container manager, characterized by comprising: a communication interface and a processor;

The communication interface is used to receive a token request sent by a virtual network function instance VNFI, and send the token request to the processor; wherein, the VNFI needs to use a container service instance managed by the container manager For the provided service, the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The processor is configured to generate a token according to the token request, and send the token to the communication interface; wherein, the token includes the identification information of the VNFI and the identification information of the VNFM, and the VNFI The identification information and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request services;

The communication interface is also used to send the token to the VNFI.
The container manager of claim 16, wherein:

The token also includes: identification information of the container service instance; wherein the identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.
A virtual network function manager VNFM, which is characterized by comprising: a communication interface and a processor;

If the virtual network function instance VNFI managed by the VNFM needs to use the service provided by the container service instance, the processor is configured to send a token request to the communication interface; wherein, the token request includes identification information of the VNFI, And the identification information of the virtual network function manager VNFM used to manage the VNFI;

The communication interface is used to send the token request to a container manager for managing the service instance;

The communication interface is also used to receive the token sent by the container manager and send the token to the VNFI; wherein the token includes the identification information of the VNFI and the identification information of the VNFM, so The identification information of the VNFI and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request services.
The VNFM according to claim 18, wherein:

The token also includes: identification information of the container service instance;

The identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.
A container manager, characterized by comprising: a communication interface and a processor;

The communication interface is used to receive a token request sent by a virtual network function manager VNFM, and send the token request to the processor; wherein the virtual network function instance VNFI managed by the VNFM needs to use the container For services provided by the container service instance managed by the manager, the token request includes the identification information of the VNFI and the identification information of the virtual network function manager VNFM used to manage the VNFI;

The processor is configured to generate a token according to the token request, and send the token to the communication interface; wherein, the token includes the identification information of the VNFI and the identification information of the VNFM, and the VNFI The identification information and the identification information of the VNFM are used by the container service instance to verify the VNFI that uses the token to request services;

The communication interface is also used to send the token to the VNFM, so that the VNFM sends the token to the VNFI.
The container manager of claim 20, wherein:

The token also includes: identification information of the container service instance; wherein the identification information of the container service instance is used for the VNFI to request a service from the container service instance corresponding to the identification information of the container service instance.