WO2023030218A1

WO2023030218A1 - Network service deployment method, nfvo, and nfv system

Info

Publication number: WO2023030218A1
Application number: PCT/CN2022/115397
Authority: WO
Inventors: 李世涛
Original assignee: 华为技术有限公司
Priority date: 2021-08-31
Filing date: 2022-08-29
Publication date: 2023-03-09
Also published as: CN115733743A

Abstract

Disclosed in embodiments of the present application are a network service deployment method, a network function virtualization orchestrator (NFVO), and an NFV system, for use in improving the flexibility of resource isolation or sharing during network service deployment. The method in the embodiments of the present application comprises: an NFVO obtaining a first virtualized network function (VNF) associated with a first deployment policy and a second VNF associated with a second deployment policy, the first VNF and the second VNF belonging to different NSs, the first deployment policy and the second deployment policy comprising the same user identifier and deployment task identifier, the second deployment policy further comprising a first identifier, and the first identifier being used for indicating the affinity or anti-affinity of a resource; and the NFVO determining, according to the first identifier, whether the first VNF and the second VNF are in common resource deployment.

Description

Network service deployment method, NFVO and NFV system

This application claims the priority of the Chinese patent application with the application number 202111017188.7 and the title of the invention "Network Service Deployment Method, NFVO and NFV System" filed with the China Patent Office on August 31, 2021, the entire contents of which are incorporated herein by reference Applying.

technical field

The embodiment of the present application relates to the field of communication technologies, and in particular to a network service deployment method, NFVO and NFV system.

Background technique

Network function virtualization (network function virtualization, NFV) uses general-purpose hardware devices and virtualization technologies to carry the network functions of dedicated devices in traditional networks, thereby reducing the expensive cost of deploying dedicated devices. A virtualized network service (network service, NS) in NFV may include several virtualized network function modules (virtualized network function, VNF).

A tenant can initiate one or more NS creation requirements to the mobile network operator. Multiple NSs of the same tenant can also share or isolate resources according to the needs of the tenant, or share or isolate part of them. The mobile network operator can upload the nested network service deployment template (network service descriptor, NSD) to the network functions virtualization orchestrator (network functions virtualization orchestrator, NFVO) according to the needs of the tenants, so that NFVO can deploy multiple NSs according to the nested NSD template. Isolated or shared deployments.

For resource saving or security considerations, some VNFs need to be deployed on different nodes, and some nodes need to be deployed on the same node. When tenants have partial VNF isolation requirements between different NSs, the above method can only meet the NS level. Due to the above isolation or sharing requirements, the isolation between some VNFs of different NSs cannot be achieved.

Contents of the invention

The embodiment of the present application provides a network service deployment method, NFVO and NFV system, so as to realize resource isolation or shared deployment among VNFs of different NSs.

The first aspect of the embodiment of the present application provides a network service deployment method, the method includes: the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment strategy, and the first virtualized network function VNF associated with the second deployment strategy Two VNFs, the first VNF belongs to the first network service NS, the second VNF belongs to the second NS, the first NS and the second NS are different NSs, and the first deployment strategy and the second deployment strategy include the same user ID and deployment task ID, the user ID is used to indicate which tenant the corresponding VNF belongs to, and the deployment task ID corresponds to which specific deployment task the VNF belongs to. The second deployment strategy also includes a first ID, which is used to indicate the affinity or Anti-affinity: NFVO determines whether the first VNF and the second VNF share resources for deployment according to the first identifier. In this way, NFVO can perceive whether the VNFs of different NSs of the same user are deployed with shared resources or isolated deployments according to the deployment strategy, thus making the deployment of VNFs more flexible.

In some possible implementation manners, the first NS is the deployed NS, the second NS is the NS to be deployed, and the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy, and Before the second VNF associated with the second deployment strategy, it also includes: NFVO receives an update message sent by the operation and business support system OSS/BSS, the update message is used to update the deployment strategy of the first NS, and the update message includes the first deployment strategy; NFVO Obtain the first deployment policy from the update message. For the deployed first NS, by sending an update message to the NFVO to provide the NFVO with the first deployment strategy of the first NS, so that there is no need to formulate a deployment strategy for resource sharing or isolation for the first NS when deploying the first NS, When deploying the second NS, formulating the first deployment policy according to the deployment requirements of the second NS can improve the flexibility of formulating the first deployment policy.

In some possible implementation manners, the first NS is the deployed NS, the second NS is the NS to be deployed, and the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy, and Before the second VNF associated with the second deployment strategy, it also includes: NFVO receives the first network service description template NSD file corresponding to the first NS uploaded by OSS/BSS, and the first NSD file includes the first deployment strategy; NFVO receives from the first NSD Get the first deployment policy in the file. By extending the NSD template, the deployment policy can be carried in the NSD file, so that NFVO can perceive the deployment requirements of the corresponding NS when parsing the NSD file.

In some possible implementation manners, before the network function virtualization orchestrator NFVO obtains the first virtualized network function VNF associated with the first deployment strategy and the second VNF associated with the second deployment strategy, it further includes: NFVO receiving the OSS/ The request message sent by the BSS for instructing instantiation of the second NS, the request message includes the second deployment strategy; the NFVO obtains the second deployment strategy from the request message. By carrying the second deployment strategy in the request message, the flexibility of formulating and acquiring the second deployment strategy can be improved.

In some possible implementation manners, before the network function virtualization orchestrator NFVO obtains the first virtualized network function VNF associated with the first deployment strategy and the second VNF associated with the second deployment strategy, it further includes: NFVO receiving the OSS/ The second NSD file corresponding to the second NS uploaded by the BSS, the second NSD file includes the second deployment strategy; the NFVO obtains the second deployment strategy from the second NSD file. By extending the NSD template, the deployment policy can be carried in the NSD file, so that NFVO can perceive the deployment requirements of the corresponding NS when parsing the NSD file.

In some possible implementations, both the first NS and the second NS are NS to be deployed, and the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy, and the second deployment policy Before the associated second VNF, it includes: NFVO receives the first NSD file corresponding to the first NS uploaded by OSS/BSS and the second NSD file corresponding to the second NS, the first NSD file includes the first deployment strategy, and the second NSD file The second deployment strategy is included; the NFVO acquires the first deployment strategy from the first NSD file, and the second deployment strategy from the second NSD file. When the first NS and the second NS need to be deployed together, the extended NSD file can carry the first deployment strategy and the second deployment strategy, so that NFVO can perceive the resources of the first NS and the second NS when parsing the NSD file Isolated or shared deployment requirements, so as to deploy the first VNF and the second VNF according to the deployment requirements.

In some possible implementation manners, the first deployment strategy and the second deployment strategy may also be carried in the request message for instantiating the first NS and the second NS sent by the OSS/BSS to the NFVO.

In some possible implementation manners, the second deployment strategy further includes a second identifier, and the second identifier is used to indicate an application scope of the second deployment strategy. The second identifier includes a user scope identifier, a physical node scope identifier and a virtual node scope identifier.

In some possible implementations, when the first identifier is an affinity identifier and the second identifier is a user-scope identifier, the NFVO determining whether the first VNF and the second VNF share resources according to the first identifier includes: NFVO according to the affinity The identifier and the user scope identifier determine that the first VNF and the second VNF are deployed in the same user resource pool.

In some possible implementations, when the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a physical node range identifier, NFVO determines whether the first VNF and the second VNF share resources for deployment according to the first identifier Including: NFVO determines that the first VNF and the second VNF are deployed on the same physical node according to the affinity ID and the physical node range ID, or determines that the first VNF and the second VNF are deployed on different physical nodes according to the anti-affinity ID and the physical node range ID. node.

In some possible implementations, when the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a virtual node range identifier, NFVO determines whether the first VNF and the second VNF share resource deployment according to the first identifier Including: NFVO determines that the first VNF and the second VNF are deployed on the same virtual node according to the affinity identifier and the virtual node scope identifier, or determines that the first VNF and the second VNF are deployed on different virtual nodes according to the anti-affinity identifier and the virtual node scope identifier. node.

In some possible implementation manners, the first deployment strategy further includes the same first identifier and/or second identifier as the second deployment strategy.

In some possible implementations, the method further includes: the NFVO receives a request message for instantiating the second NS sent by the OSS/BSS; and the NFVO sends a request message for instantiating the second NS to the virtualization function manager VNFM in response to the request message. An indication message, where the indication message includes the location information of the instantiated second VNF, and the location information is allocated to the second VNF after the NFVO determines whether the first VNF and the second VNF share resources for deployment. After determining the deployment requirements of the VNFs in the first NS and the second NS according to the first deployment strategy and the second deployment strategy, the NFVO instructs the VNFM to deploy the VNFs according to the deployment requirements of the tenants, so as to complete the deployment of the second NS.

The second aspect of the embodiment of the present application provides a network service deployment method, the method includes: the operation and service support system OSS/BS sends the first deployment strategy and the second deployment strategy to the network function virtualization orchestrator NFVO; Whether the first deployment policy and the second deployment policy include the same user ID and deployment task ID; if yes, NFVO obtains the first virtualized network function VNF associated with the first deployment policy, and the second VNF associated with the second deployment policy , the first VNF belongs to the first network service NS, and the second VNF belongs to the second NS; NFVO determines whether the first VNF and the second VNF share resources according to the first identifier in the second deployment policy, wherein the first identifier is used for Indicates the affinity or anti-affinity of the resource.

In some possible implementation manners, the method further includes: the OSS/BS sends a request message for instantiating the second NS to the NFVO; and the NFVO sends an instruction to instantiate the second VNF to the virtualized network function manager VNFM in response to the request message message, the indication message includes the location information of instantiating the second VNF, and the location information is allocated for the second VNF after the NFVO determines whether the first VNF and the second VNF share resource deployment; the VNFM instantiates the second VNF at the node corresponding to the location information according to the indication message Second VNF.

The third aspect of the embodiment of the present application provides a network function virtualization orchestrator NFVO, which is characterized in that the NFVO includes: an acquisition module, configured to acquire the first virtualized network function VNF associated with the first deployment policy, and the second The second VNF associated with the deployment policy, the first VNF belongs to the first network service NS, the second VNF belongs to the second NS, the first deployment policy and the second deployment policy include the same user ID and deployment task ID, and the second deployment policy also It includes a first identification, the first identification is used to indicate resource affinity or anti-affinity; a determining module is used to determine whether the first VNF and the second VNF share resources according to the first identification.

In some possible implementations, the NFVO further includes: a receiving module, configured to receive an update message sent by the operation and business support system OSS/BSS, the update message is used to update the deployment strategy of the first NS, and the update message includes the first Deployment strategy; an acquisition module, also used to obtain the first deployment strategy from the update message.

In some possible implementations, the NFVO also includes: a receiving module, configured to receive the first network service description template NSD file corresponding to the first NS uploaded by the OSS/BSS, and the first NSD file includes the first deployment strategy; The module is further configured to obtain the first deployment policy from the first NSD file.

In some possible implementations, the receiving module is further configured to receive a request message sent by the OSS/BSS for instructing instantiation of the second NS, and the request message includes the second deployment strategy; the obtaining module is also configured to request Get the second deployment policy from the message.

In some possible implementations, the receiving module is also used to receive the second NSD file corresponding to the second NS uploaded by the OSS/BSS, and the second NSD file includes the second deployment strategy; Get the second deployment strategy from the NSD file.

In some possible implementations, the NFVO also includes: a receiving module, configured to receive the first NSD file corresponding to the first NS and the second NSD file corresponding to the second NS uploaded by the OSS/BSS, the first NSD file includes The first deployment strategy and the second NSD file include the second deployment strategy; the obtaining module is also used to obtain the first deployment strategy from the first NSD file and the second deployment strategy from the second NSD file.

In some possible implementation manners, the second deployment strategy further includes a second identifier, and the second identifier is used to indicate an application scope of the second deployment strategy.

In some possible implementations, the first identifier is an affinity identifier, and the second identifier is a user-scope identifier, and the determining module is specifically configured to: determine that the first VNF and the second VNF are deployed on the same site according to the affinity identifier and the user-scope identifier. User resource pool.

In some possible implementations, the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a physical node range identifier, and the determining module is specifically configured to: determine the first VNF according to the affinity identifier and the physical node range identifier The second VNF is deployed on the same physical node, or the first VNF and the second VNF are deployed on different physical nodes as determined according to the anti-affinity identifier and the physical node range identifier.

In some possible implementations, the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a virtual node range identifier, and the determining module is specifically configured to: determine the first VNF according to the affinity identifier and the virtual node range identifier The second VNF is deployed on the same virtual node, or the first VNF and the second VNF are deployed on different virtual nodes as determined according to the anti-affinity identifier and the virtual node range identifier.

In some possible implementations, the NFVO further includes: a receiving module, configured to receive a request message for instantiating the second NS sent by the OSS/BSS; a sending module, configured to send the instantiated second NS to the VNFM in response to the request message. An indication message of the VNF, where the indication message is used to indicate whether the second VNF is instantiated in the same resource pool/physical node/virtual node as the first VNF.

The fourth aspect of the embodiment of the present application provides a NFVO, the NFVO includes: a processor, a memory, and a transceiver, wherein the memory stores program codes, and the processor invokes the program codes stored in the memory, so that the network service deployment device executes the above-mentioned The network service deployment method in the first aspect and any possible implementation manner thereof.

The fifth aspect of the embodiment of the present application provides a network function virtualization NFV system, which is characterized in that the system includes an operation and business support system OSS/BSS and the above third or fourth aspect and any possible implementation thereof NFVO in: OSS/BSS is used to send to NFVO the first deployment policy and the second deployment policy including the user ID and the deployment task ID, the second deployment policy also includes the first ID, and the first ID is used to indicate the affinity of resources Or anti-affinity, the first deployment strategy is associated with the first VNF, and the second NS is associated with the second VNF; NFVO is used to determine whether the first VNF and the second VNF share resources for deployment according to the first identifier in the second deployment strategy.

In some possible implementations, the system further includes a virtualized network function manager VNFM; NFVO is further configured to send an indication message to the VNFM to instantiate a second VNF, the indication message includes location information for deploying the second VNF, and the location information is The NFVO determines whether the first VNF and the second VNF share resources and allocates them to the second VNF after deployment; the VNFM is used to instantiate the second VNF on the node corresponding to the location information according to the indication message.

Description of drawings

FIG. 1 is a schematic structural diagram of an NFV system 100 provided in an embodiment of the present application;

FIG. 2 is a schematic flowchart of a first embodiment of a network service deployment method provided by an embodiment of the present application;

Figure 3 is a schematic diagram of the first NSD file provided by the application;

Figure 4 is a schematic diagram of the second NSD file provided by the present application;

FIG. 5 is a schematic flowchart of a second embodiment of a network service deployment method provided by an embodiment of the present application;

FIG. 6 is a schematic flowchart of a third embodiment of a network service deployment method provided by an embodiment of the present application;

Figure 7 is a schematic diagram of the nested NSD file provided by the present application;

8 is a schematic diagram of the first NSD file corresponding to NSD-1 in the nested NSD file provided by the present application;

Fig. 9 is a schematic diagram of a second NSD file corresponding to NSD-2 in a nested NSD file;

FIG. 10 is a schematic structural diagram of an embodiment of NFVO provided by the embodiment of the present application;

FIG. 11 is a schematic structural diagram of another embodiment of NFVO provided by the embodiment of the present application.

Detailed ways

The embodiment of the present application provides a network service deployment method, NFVO and NFV system, which are used to improve the flexibility of resource isolation or sharing during network service deployment.

Network function virtualization (network function virtualization, NFV), through the use of general-purpose hardware devices and virtualization technology, to carry the functions of special equipment in traditional networks, thereby reducing the expensive cost of deploying special equipment. Through the decoupling of software and hardware, the functions of network equipment are no longer dependent on dedicated hardware. At the same time, by utilizing the characteristics of cloud computing, resources can be fully and flexibly shared, and rapid development and deployment of new services can be realized, and automatic deployment, elastic scaling, fault isolation, and self-healing can be performed based on actual business needs. A party that can receive a virtualization request and perform virtualization processing on corresponding services according to the request is generally called a virtualization service provider, and a party that initiates a virtualization request is generally called a service requester.

The virtualized network service in NFV is called a network service (NS), such as an IP multimedia subsystem (IP multimedia subsystem, IMS) network service, or a 5G core network network. One NS may also include several virtualized network function modules (virtualized network function, VNF). When an NS is deployed in virtualization, the service requester first needs to submit the service description (network service descriptor, NSD) to the service provider, also known as the NS deployment template, which mainly describes the topology of the service and the included The VNF description information (VNF descriptor, VNFD) of each VNF, in which the virtual connection information (network service virtual link descriptor, NsVld) is used in the topology information to describe the connection between VNFs. Currently, the connection type, bandwidth and other information are used To represent. VNFD is also called the deployment template of VNF, which contains virtual deployment unit (virtualization deployment unit, VDU), connection point template (connection point descriptor, CPD), virtual connection template (virtual link descriptor, VLD) and other information, where VDU can Represents a virtual machine with application software installed. The description of VDU will include the description of all virtual resources of the virtual machine. CPD represents the connection information on the virtual machine, such as virtual network card information, including IP address or MAC Address and other information, VLD describes the virtual network connection requirements between VDUs, including connection type, bandwidth and other information. VNFD also includes the external connection point VnfExtCpd of this VNF, and this VnfExtCpd is connected with NsVld, so as to realize the connection between VNFs.

As shown in FIG. 1 , FIG. 1 is a schematic structural diagram of an NFV system 100 provided in an embodiment of the present application. The NFV system 100 includes an operation support system and a business support system (operations support system and business support system, OSS/BSS) 101 of a mobile network, a network functions virtualization orchestrator (network functions virtualization orchestrator, NFVO) 102, and a virtual network function manager (VNF manager, VNFM) 103, virtual infrastructure manager (virtual infrastructure management, VIM) 104, network functions virtualization infrastructure (network functions virtualization infrastructure, NFVI) 105, equipment management system (equipment management, EM) 106 and multiple A VNF107 and other functional components.

NFVO102 is mainly responsible for handling the lifecycle management of virtualization services, as well as the allocation and scheduling of virtual infrastructure and virtual resources in NFVI105. NFVO102 can communicate with one or more VNFM103 to execute resource-related requests, send configuration information to VNFM103, and collect status information of VNF107. In addition, NFVO 102 may also communicate with VIM 104 to perform resource allocation, and/or reserve exchange virtualization hardware resource configuration and status information.

VNFM103 is responsible for lifecycle management of one or more VNFs, such as instantiating, updating, querying, scaling, and terminating VNF107. VNFM103 can communicate with VNF to complete VNF107 life cycle management and exchange configuration and status information. There may be multiple VNFMs 103 in the NFV system 100, which are responsible for lifecycle management of different types of VNFs 107.

NFV is the infrastructure layer of NFV, which includes a hardware resource layer and/or a virtualization layer to establish a virtualized environment, deploy, manage and implement VNF107. The hardware resource layer and/or the virtualization layer are used to provide VNFs with virtualized resources, such as virtual machines and other forms of virtual containers. The hardware resource layer includes computing hardware, storage hardware, and network hardware. As an implementation manner, resources of computing hardware and storage hardware may be gathered together. The virtualization layer in NFVI105 abstracts hardware resources and decouples VNF107 from the underlying hardware resource layer. The virtualization layer includes virtual computing obtained by abstracting computing hardware, virtual storage obtained by abstracting storage hardware, and virtual network obtained by abstracting network hardware.

VIM104, controlling and managing the interaction between VNF107 and computing hardware, storage hardware, network hardware, virtual computing, virtual storage, and virtual network. For example, VIM 104 performs resource management functions, including managing infrastructure resources, allocation (such as adding resources to virtual containers) and running functions (such as collecting NFVI 105 fault information). VNFM103 and VIM104 can communicate with each other, request resource allocation, and exchange virtualized hardware resource configuration and status information.

EM106 is a system used to configure and manage equipment in traditional telecommunication systems. In NFV system 100, EM106 can also be used to configure and manage VNF107, and initiate life cycle management such as instantiation of new VNF107 to VNFM103 operate.

OSS/BSS101 supports various end-to-end telecommunication services. The management functions supported by OSS include: network configuration, service provision, fault management, etc. BSS handles orders, payment, income, etc., and supports product management, order management, revenue management and customer management.

Customers in vertical industries, such as power companies or Internet of Vehicles companies, can submit network construction requirements to OSS/BSS101, such as requirements for network bandwidth, delay, and geographical location, and OSS/BSS101 will generate corresponding deployments based on user requirements Policy, to instruct the NFV system 100 to complete the deployment of the NS according to the information in the deployment policy. For OSS/BSS101, a customer in an industry can also be regarded as a tenant, and network resources between different tenants can be shared or isolated according to requirements.

The same tenant can initiate one or more NS creation requirements to OSS/BSS101. In order to reduce the impact of physical machine or virtual machine downtime and improve the security and availability of network services, between multiple NSs of the same tenant, the tenant There may be a requirement for resource isolation; and in order to improve resource utilization, tenants may also have a requirement for resource sharing among multiple NSs of the same tenant. Specifically, when a tenant needs to create a new second NS, there may be resource sharing or isolation requirements between the second NS and the previously deployed first NS; when a tenant needs to create multiple new second NSs, There is a resource sharing or isolation requirement among multiple second NSs. Tenants may also need to be isolated from NS resources of other tenants. Wherein, resource sharing or isolation may be complete sharing or isolation between VNFs 107 of different NSs, or partial VNF sharing or partial VNF isolation.

According to the resource isolation or sharing requirements of tenants for different NSs, OSS/BSS101 generates corresponding deployment policies, and each deployment policy is associated with at least one VNF107 in NS, and OSS/BSS101 sends the deployment policy to NFVO102. NFVO102 compares the parameters in different deployment strategies to determine whether the associated VNF107 needs isolation or shared resource deployment.

Specifically, in this embodiment of the application, the deployment policy includes a user ID, a deployment task ID, and a first ID. Wherein, the user identifier is the unique identifier of the tenant in the NFV system, and is used to indicate which tenant the associated VNF 107 belongs to. The deployment task identifier is used to identify a specific deployment task. If the user IDs and deployment task IDs in different deployment policies are the same, it means that these deployment policies belong to the same deployment task of the same tenant, and the VNFs 107 associated with these deployment policies need to isolate resource deployment or share resource deployment.

Whether the VNFs 107 associated with the same deployment task of the same tenant are isolated resource deployment or shared resource deployment depends on the first identifier. The first identifier is used to indicate the affinity or anti-affinity of the resource, and the first identifier may be an affinity identifier or an anti-affinity identifier. When the first identifier is an affinity identifier, the VNF107 associated with the same deployment task of the same tenant can share resource deployment; when the first identifier is an anti-affinity identifier, the VNF107 associated with the same deployment task of the same tenant Resource deployment needs to be isolated.

The deployment strategy may further include a second identifier, and the second identifier is used to indicate the application scope of the deployment strategy. The second identifier may specifically be a user-scoped identifier, a physical node-scoped identifier, or a virtual node-scoped identifier. The first identifier and the second identifier jointly indicate at which resource level the VNFs 107 under the same deployment task are isolated or shared.

Specifically, NFVO102 determines the second deployment policy with the same user ID and deployment task ID according to the user ID and deployment task ID in the second deployment policy, obtains the first VNF in the first NS associated with the first deployment policy, and the second deployment policy Second, deploy the second VNF in the second NS associated with the policy. Wherein, the first VNF is any one of at least one VNF in the first NS, and the second VNF is any one of at least one VNF in the second NS. Further determine whether the first VNF and the second VNF are deployed on common resources according to the first identifier and the second identifier:

When the first identifier in the first deployment strategy and/or the second deployment strategy is an affinity identifier and the second identifier is a user scope identifier, the NFVO 102 determines that the first VNF and the second VNF are deployed in the same user resource pool. Wherein, the user resource pool is the physical resource and/or virtual resource allocated for the tenant corresponding to the user ID in the NFV system for the tenant to carry out business, and the resources in the user resource pool of the tenant are not shared with other tenants.

When the first identifier in the first deployment strategy and/or the second deployment strategy is an affinity identifier and the second identifier is a physical node range identifier, the NFVO 102 determines that the first VNF and the second VNF are deployed on the same physical node.

When the first identifier in the first deployment strategy and/or the second deployment strategy is an affinity identifier and the second identifier is a virtual node range identifier, the NFVO 102 determines that the first VNF and the second VNF are deployed on the same virtual node.

When the first identifier in the first deployment strategy and/or the second deployment strategy is an anti-affinity identifier and the second identifier is a physical node range identifier, the NFVO 102 determines that the first VNF and the second VNF are deployed on different physical nodes.

When the first identifier in the first deployment strategy and/or the second deployment strategy is an anti-affinity identifier and the second identifier is a virtual node range identifier, the NFVO 102 determines that the first VNF and the second VNF are deployed on different virtual nodes.

It should be noted that when there are multiple VNFs 107 in the NS to be deployed, NFVO 102 can obtain the deployment strategy associated with each VNF 107, and then obtain other VNFs 107 belonging to the same deployment task according to the deployment strategy based on the above method, so as to determine the Whether there is a requirement for resource isolation or sharing, and determine which VNF107 resources are isolated or shared.

It should be noted that when a certain deployment policy is associated with at least two VNFs 107, these VNFs 107 need to follow the same deployment rules. For example, the first deployment strategy is associated with two first VNFs, and the second deployment strategy is associated with three second VNFs, and the user identifier and deployment task identifier in the first deployment strategy and the second deployment strategy are the same, if the first identifier is Anti-affinity ID, the second ID is a physical node range ID, then the five VNFs need to be isolated from each other, that is, they are deployed on five different physical nodes; if the first ID is an affinity ID, the second ID is When the physical node range is identified, the five VNFs need to be deployed on the same physical node.

When a certain VNF 107 is associated with at least two deployment policies at the same time, that is, when the VNF 107 and at least two VNFs 107 have deployment requirements respectively, the VNF 107 needs to meet these deployment requirements at the same time during deployment. For example, after analyzing the deployment strategy, NFVO102 determines that the first VNF and the second VNF need to be deployed on separate physical nodes, and the first VNF and the third VNF in the third NS need to be deployed on the same physical node. Then, when allocating deployment resources, NFVO102 It must be satisfied that the first VNF and the second VNF are deployed on different physical nodes, and at the same time, the first VNF and the third VNF are deployed on the same physical node.

After determining the deployment requirements of the VNF107 to be deployed, the NFVO102 sends an instruction message to the virtualization function manager VNFM103 to instantiate the VNF107 to be deployed. The indication message includes instantiated location information of the second VNF to be deployed, and the location information is allocated to the second VNF after the NFVO 102 determines whether the first VNF and the second VNF share resources for deployment. Wherein, the location information may be a specific physical node or virtual node. For example, when the first VNF has been deployed, and the first VNF and the second VNF have a common physical node or virtual node deployment requirement, the location information may include Deploy the physical node or virtual node of the first VNF to instruct the VNFM103 to deploy the second VNF on the physical node or virtual node where the first VNF is located. The location information can also be used to constrain the location range when the VNFM103 instantiates the second VNF. For example, when the first VNF has been deployed, and the first VNF and the second VNF have requirements for isolated deployment of physical nodes or virtual nodes, The location information includes a requirement to exclude the physical node or virtual node where the first VNF is deployed, so as to instruct the VNFM103 to deploy the second VNF on a node other than the physical node or virtual node where the first VNF is located. The location information may further include geographic location information, that is, which province, city, or district the second VNF is deployed in.

Based on the above NFV system 100, according to different requirements of tenants, this application provides the following embodiments, so that VNFO can perceive the deployment requirements of NS, and then allocate resources for VNF 107 in NS according to the deployment requirements.

As shown in FIG. 2 , FIG. 2 is a schematic flowchart of a first embodiment of a network service deployment method provided in an embodiment of the present application. In this embodiment, the first NS is the NS that has been deployed earlier, and the second NS is the NS to be deployed. This embodiment includes the following steps:

201: The OSS/BSS determines to deploy the first NS for the tenant Z according to the first requirement of the tenant Z.

The first requirement includes the network function desired by the tenant Z and the geographical location of the network function. The OSS/BSS determines the quantity of the first VNF and the geographical location where the first VNF is deployed according to the quantity and geographical location of the network functions in the first requirement, and generates the first NSD file of the first NS.

For example, tenant Z needs to establish a network and provide services for city B (such as Internet of Vehicles service or electric power service), where the control part of the network is located in central city A, and the edge server that provides transmission services for end users is located in city B, then OSS/BSS It is determined that the first NS deployed for tenant Z includes two first VNFs (VNF1 and VNF2), wherein VNF1 is located in city A as a control server, and VNF2 is located in city B as an edge server.

202: The OSS/BSS uploads the first NSD file to the NFVO, where the first NSD file includes the first deployment strategy.

This implementation expands the NSD file, adding a user ID field (tenantId) and a deployment task ID field (deploymentId) to the deployment policy.

Exemplarily, this embodiment continues to take the example that the first NS includes two VNFs (VNF1 and VNF2), as shown in FIG. 3 , which is a schematic diagram of the first NSD file provided by this application. Wherein, a group is a deployment strategy, an NSD file may include at least one deployment strategy, and a deployment strategy may be associated with at least one VNF. It can be understood that for the content of the NSD file, the embodiment of the present application only gives a description of the relevant parts of the present application, and other parts that are not relevant to the present patent are not reflected here; and the number of VNFs and deployment strategies is only used as an example, not As a limitation to this application, an NSD file can include 1 deployment strategy, 2 deployment strategies, 4 deployment strategies, 5 deployment strategies or more, and a VNF can also be associated with 1, 3 or more deployment strategies The association is specifically adjusted according to requirements, which is not limited in this application.

Among them, the affinityOrAntiAffinityGroupId field defines the deployment strategy associated with the VNF. For example, VNF1 is associated with two first deployment strategies (group_1, group_3), and VNF2 is also associated with two first deployment strategies (group_2, group_3).

affinityOrAntiAffinity is a first identification field, which is used to define a first identification, and the first identification may be affinity (ie, affinity identification) or AntiAffinity (ie, anti-affinity identification). This field is specifically used to indicate whether the VNF associated with the deployment policy is affinity (shared) or AntiAffinity (isolated).

Scope is the second identification field, which defines the application scope of the deployment policy. The second identifier may be a user-wide identifier (tenant), a physical node-wide identifier (NFVI_NODE) or a virtual node-wide identifier (VM). tenant is a newly added Scope parameter in this application. The combination of the first identifier and the second identifier can determine which scope affinity or anti-affinity the VNF associated with the deployment policy is. For example, when the first identifier is affinity (affinity identifier) and the second identifier is tenant, it indicates that the NFVO allocates resources for the VNF associated with the deployment policy from the user resource pool of the tenant. Exemplarily, both VNF1 and VNF2 are associated with group3, indicating that VNF1 and VNF2 need to be deployed in the same user resource pool.

In the first NSD file uploaded in this step, each parameter in the first deployment strategy may not be assigned a value. That is, the affinityOrAntiAffinityGroupId, Scope, tenantId, and deploymentId in group1, group2, and group3 are all empty. It is also possible to only assign values to Scope and tenantId in group3, while other groups and other groups are not assigned values.

203: The NFVO returns an upload success response to the OSS/BSS.

204: The OSS/BSS initiates a request to the NFVO to create the first NS instance ID of the first NS, and the request includes the file identifier of the first NSD file.

205: The NFVO returns the first NS instance ID created for the first NS to the OSS/BSS.

The NFVO determines the first NSD file whose instance ID is to be created according to the file identifier, so as to associate the created first NS instance ID with the first NS. The first NS instance ID is used to uniquely identify the first NS. If the message carries the first NS instance ID during the subsequent message exchange between the NFVO and the OSS/BSS, it can be determined according to the first NS instance ID that the message acts on the first NS.

206: The OSS/BSS sends a first request message for instantiating the first NS to the NFVO.

Wherein, the first request message carries the first NS instance ID. The first request message is used to instruct the NFVO to trigger the first VNF instantiation process in the first NS.

The deployment geographic location information of the first VNF may also be carried in the first request message. For example, VNF1 is located in city A, and VNF2 is located in city B.

Because no value is assigned to the first deployment policy in step 202 . In this step, the first request message also carries the deploymentId and tenant_id information assigned to each group. Specifically, the allocation information in this embodiment is as follows:

group_1:

tenantId: tenant-A

deploymentId: ID-123

group_2:

tenantId: tenant-A

deploymentId:ID-ABC

group_3:

tenantId: tenant-A

deploymentId:ID-xyz

When the first NS is created, it is not clear whether future tenants will continue to create NS, and whether the VNF in the new NS is isolated from those VNF resources in the first NS, or which VNF resources are shared, so other parameters are temporarily used in this step. No allocation, so that tenants can flexibly realize the isolation or sharing requirements of tenants when they create the second NS.

207: The NFVO determines the first VNF that needs to be instantiated according to the first request message and the first NSD file.

208: The NFVO sends an instruction message for instantiating the first VNF to the VNFM.

Exemplarily, in the process of instantiating VNF1 and VNF2, VNFM needs to initiate a resource authorization request to NFVO respectively, and NFVO carries the user resource pool information for allocating resources in the authorization reply message. Since both VNF1 and VNF2 are associated with group_3, they need to be deployed in In the same user resource pool, the user resource pool information carried in the authorization response messages that NFVO replies to VNFM respectively is the same.

209: The NFVO applies to the VIM for creating the first VL instance included in the first NSD file.

210: The VNFM returns to the NFVO a response that the first VNF instance is created successfully.

211: The VIM returns to the NFVO a response that the first VL instance is created successfully.

212: The NFVO returns a first NS creation success response to the OSS/BSS.

213: The OSS/BSS determines to deploy a second NS for the tenant Z according to the second requirement of the tenant Z.

The second requirement includes the network function desired by the tenant Z and the geographical location of the network function.

The OSS/BSS determines the quantity of the second VNF and the geographical location where the second VNF is deployed according to the quantity and geographical location of the network functions in the second requirement, and generates the second NSD file of the second NS. The second NSD file can use the same file as the first NSD file. Certainly, the second NSD file may also adopt a file different from the first NSD file.

Exemplarily, tenant Z expects to deploy a new network, which requires the network control part to be located in central city A, the edge server that provides data caching to be located in city B, and some network functions located in central city A do not require isolation, from resource utilization In terms of rate, the part deployed by the tenant in the central city can be shared. The OSS/BSS determines that the second NS deployed for the tenant includes two second VNFs (VNF3 and VNF4).

214: The OSS/BSS uploads a second NSD file to the NFVO, where the second NSD file includes the second deployment strategy.

Exemplarily, as shown in FIG. 4, FIG. 4 is a schematic diagram of the second NSD file provided by the present application.

215. The OSS/BSS sends a second request message for instantiating the second NS to the NFVO.

According to the second NSD file and the requirements of the tenant, the second request message carries the deployment task identifier assigned to the second NS, the first identifier and the second identifier of the user representation.

Exemplarily, the allocation information of the second deployment strategy is as follows:

216: The NFVO executes the process of instantiating the second VNF according to the second request message and the second NSD file.

Specifically, according to the user ID and deployment task ID in the second deployment policy, NFVO searches other stored deployment policies for a deployment policy with the same user ID and deployment task ID, and determines that the first deployment policy and the second deployment policy include the same The user ID and deployment task ID for .

The NFVO acquires the first VNF associated with the first deployment strategy, the second VNF associated with the second deployment strategy, and the first identifier in the second deployment strategy. Determine whether the first VNF and the second VNF are deployed with shared resources or deployed with isolated resources according to the first identifier.

Exemplarily, when the second deployment strategy is group_c, group_3 with the same tenantId and deploymentId is found according to tenantId: tenant-A and deploymentId: ID-xyz, that is, group_3 of the first NS is the same as group_c of the second NS. During deployment, VNF3 and VNF4 associated with group_c and VNF1 and VNF2 associated with group_3 need to meet the same deployment policy. Further, according to the affinityOrAntiAffinity and scope information of group_c, it is confirmed that VNF1, VNF2, VNF3 and VNF4 all belong to the same tenant, and the resources all belong to the same user resource pool.

When the second deployment strategy is group_a, find group_1 with the same tenantId and deploymentId according to tenantId: tenant-A and deploymentId: ID-123, that is, group_1 of the first NS is the same as group_a of the second NS, and group_1 is deployed The associated VNF1 and the VNF3 associated with group_c need to meet the same deployment policy. Further, according to the affinityOrAntiAffinity and scope information of group_c, it is confirmed that the policy of group_c is the affinity of scope as VM, that is, the VNF3 associated with group_c and the VNF1 associated with group_1 can be deployed in a virtual machine (VM), that is, VNF3 can be shared with VNF1 The same VNF instance. Then NFVO does not need to initiate a new VNF3 instantiation process, and judges whether the resources on the VNF1 instance in the first NS meet the requirements of VNF3, and if so, directly allocates the VNF1 instance to the second NS. If the resources on the VNF1 instance are insufficient to meet the requirements of VNF3, the capacity of VNF_1 will be expanded and then allocated to the second NS.

When the second deployment strategy is group_b, for group_2, group_2 with the same tenantId and deploymentId is found according to tenantId: tenant-A and deploymentId: ID-ABC, that is, group_2 of the first NS is the same as group_b of the second NS. During deployment, VNF2 associated with group_2 and VNF4 associated with group_b must meet the same deployment policy. Further, according to the affinityOrAntiAffinity and scope information of group_b, confirm that the policy of group_b is the anti-affinity scope of NFVI-NODE, that is, the VNF4 associated with group_b and the VNF2 associated with group_2 need to be isolated and deployed on physical machines (NFVI-NODE). Then NFVO initiates the instantiation process of VNF4 to VNFM, and instructs VNFM to deploy the user resource pool information of VNF4 instance as in step 208, but the physical machine selected for deployment is different from the VNF2 deployed on the first NS.

When a VNF is associated with two or more deployment strategies, NFVO allocates resources for the VNF in accordance with these deployment strategies. For example, VNF2 is associated with group2 and group3, VNF4 is associated with groupb and groupc, group2 is the same as groupb, and group3 is the same as groupc, then VNF2 and VNF4 must be deployed in the same user resource pool and must be deployed on different physical nodes requirements.

For deployment strategies with at least one different user ID and deployment task ID, there is no requirement for resource isolation or resource sharing between their associated VNFs. The location and the remaining resources in the user resource pool can be used to allocate resources to these VNFs, which may be deployed on the same physical node or virtual node, or may be deployed on different physical nodes or different virtual nodes.

The NFVO sends an indication message for instantiating the second VNF to the VNFM, and the indication message carries the location information of the second VNF. Exemplarily, when NFVO instructs VNF4 to be deployed, the instruction message carries location information such as city B information, user resource pool information, and information on nodes not shared with VNF2, so that VNFM selects qualified physical nodes to deploy VNF4 based on these information.

217-220: the creation of the second VNF and the second VL is completed, and the deployment of the second NS is completed.

For details, refer to steps 209-212, which will not be repeated here.

In this embodiment, by adding the user ID, deployment task ID, first ID, and second ID in the NSD file, NFVO can perceive the deployment requirements of tenants based on these parameters, so as to complete the deployment of network services according to the deployment requirements, so that VNFs between different NSs can flexibly isolate resource deployment or share resource deployment, improving network service security and resource utilization.

As shown in FIG. 5 , FIG. 5 is a schematic flowchart of a second embodiment of a network service deployment method provided in an embodiment of the present application. The difference from the first embodiment of the network service deployment method is that in this embodiment, the timing and carrier of the first deployment policy sent by the OSS/BSS to the NFVO are different. This embodiment includes the following steps:

301-312: Create the first NS.

Steps 301-312 are similar to steps 201-212. The difference is that in this embodiment, there is no need to expand the NSD template, that is, there is no need to update the NSD file. There is no user identification field and deployment task identification field in the first NSD file. The second identifier also has no user scope identifier. In the first request message, there is no need to assign a user ID and a deployment task ID to the first NS.

313: The OSS/BSS chooses to deploy the second NS to provide services for the tenant Z according to the second requirement.

314: The OSS/BSS sends an update message to the NFVO, where the update message is used to add the first deployment policy to the first NS.

In this embodiment, the first deployment strategy may have the following two application scenarios:

Application Scenario 1: The first deployment strategy can be a deployment strategy at the NS level, which instructs the first NS to isolate or share resources with other NSs. Each VNF in the first NS is associated with the first deployment strategy, which can be applied to A scenario where all VNFs in the second NS need to isolate or share resources from all VNFs in the first NS.

Exemplarily, when the first deployment strategy is a deployment strategy on the NS level, the specific content of the first deployment strategy is as follows:

Wherein, NS_1_id is the first NS instance ID, and the meanings of other parameters are as explained in the first embodiment, so they are not repeated here, and are used here to associate the first NS with the first deployment strategy. That is, a second deployment strategy is defined, which is an anti-affinity feature whose scope is nfvi-node (physical node scope), and whose object is the entire first NS (NS_1) instance.

Application Scenario 2: The first deployment strategy can also be a deployment strategy at the VNF level, that is, the first deployment strategy can only be associated with some VNFs in the first NS, and only limit the resource isolation or sharing of the associated VNFs. It is applied to a scenario where some second VNFs need to be isolated or shared with some first VNF resources.

Exemplarily, when the first deployment strategy is a deployment strategy on the VNF level, if the update message includes two first deployment strategies, the specific content of each first deployment strategy is as follows:

Among them, VNF_1_id is the instance ID of VNF1, and VNF_2_id is the instance ID of VNF2, which are allocated by NFVO. VNF_1_id is used to associate the first VNF with the first deployment strategy, and VNF_2_id is used to associate the second VNF with the second deployment strategy.

315: The OSS/BSS uploads the second NSD file of the second NS to the NFVO.

In this embodiment, the second NSD file does not update and expand the NSD file, that is, the second NSD file does not include user identification fields, deployment task fields, and the like.

316: The OSS/BSS sends a second request message for instantiating the second NS to the NFVO, where the second request message carries the second deployment policy.

The second request message contains the second deployment strategy. The first identifier, second identifier, user identifier, and deployment task identifier in the second deployment strategy are the same as those in the first deployment strategy, indicating that the deployment of the second NS is the same as that of the first NS. Follow the same deployment strategy.

Exemplarily, if the tenant's requirement is that the second NS is isolated from the physical machine of the first NS, that is, each second VNF in the second NS is not deployed on a physical machine with any first VNF in the first NS, then the first The details of the second deployment strategy are as follows:

The NFVO determines according to the first deployment strategy and the second deployment strategy that the first NS instance and the second NS instance need physical machine isolation. Since the tenantId of the first deployment strategy and the second deployment strategy are both tenant-A, it means that the first NS and the second NS belong to the same tenant and need to be deployed in the same user resource pool.

Exemplarily, if the tenant's requirement is that VNF1 and VNF3 in the second NS are deployed on a common virtual node, and VNF2 and VNF4 in the second NS are deployed on separate physical nodes, then the content of each second deployment strategy is as follows:

The number of deployment strategies carried in the second request message may also be adjusted according to actual needs. Exemplarily, when VNF3 and VNF4 also require physical node isolation, the second request message may also include the following second deployment strategy:

317: The NFVO executes the process of instantiating the second VNF according to the second request message and the second NSD file.

This step is similar to step 216, that is, by matching the first deployment strategy and the second deployment strategy with the same user identifier and deployment task identifier, and then determining the first deployment strategy and the second deployment strategy according to the first identifier and the second identifier Whether resource sharing or resource isolation between associated VNFs is omitted here.

Exemplarily, in the case of application scenario 1, the physical nodes deployed by all the second VNFs are different from the physical nodes deployed by all the first VNFs.

Exemplarily, in the case of application scenario 2, VNF1 and VNF3 are deployed on virtual machine nodes, and VNF2 and VNF4 are deployed on isolated physical nodes.

318-321: the creation of the second VNF and the second VL is completed, and the deployment of the second NS is completed.

For details, refer to steps 209-212, which will not be repeated here.

In this embodiment, when the second NS is deployed, the OSS/BSS obtains the requirements of the tenants, then generates the first deployment strategy of the first NS, and sends the first deployment strategy of the first NS to NFVO, so that the first deployment strategy And the formulation of the second deployment strategy is more flexible.

In some other implementations, OSS/BSS can provide the first deployment strategy to NFVO through the first NSD file as a carrier, and provide the second strategy to NFVO through the second request message as a carrier, that is, steps 201 to 212, and steps Steps 313 to 321 are combined as one embodiment. OSS/BSS can also provide the first deployment strategy to NFVO through the update message as the carrier, and provide the second strategy to NFVO through the second NSD file as the carrier, that is, steps 301 to 312, and steps 212 to 218 are combined as an embodiment . This application is not limited to this.

As shown in FIG. 6 , FIG. 6 is a schematic flowchart of a third embodiment of a network service deployment method provided in an embodiment of the present application. In this embodiment, the tenant needs to deploy at least two NSs, that is, both the first NS and the second NS are NSs to be deployed. As for how to implement resource isolation or sharing between the two NSs to be deployed, this embodiment It is achieved through the following steps:

401: OSS/BSS uses nested NSD files to deploy a network for tenant Z according to at least two network requirements of tenant Z.

In this embodiment, two network requirements of tenants are taken as an example for illustration.

The nested NSD file contains NSD file identifiers of two NSD files, and the NSD file corresponding to each NSD file identifier is used to deploy an NS.

Exemplarily, as shown in FIG. 7, FIG. 7 is a schematic diagram of a nested NSD file provided by this application.

As shown in Figure 7, the nested NSD file (NSD-3) contains two NSD file identifiers, namely NSD-1 and NSD-2. According to the tenant's requirements, the first NSD file corresponding to NSD-1 and the second NSD file corresponding to NSD-2 are used to deploy the two networks required by the tenant, among which VNF1 in the first NS and VNF3 in the second NS need to be deployed In the central city A, it is deployed on the same physical machine; VNF2 in the first NS is deployed in city B, and VNF4 in the second NS is deployed in city C, and they are isolated from each other. In response to this requirement, the first NSD file corresponding to NSD-1 in the nested NSD file includes the content shown in Figure 8, and the second NSD file corresponding to NSD-2 in the nested NSD file includes the content shown in Figure 9 content. FIG. 8 is a schematic diagram of a first NSD file corresponding to NSD-1 in the nested NSD files provided by the present application, and FIG. 9 is a schematic diagram of a second NSD file corresponding to NSD-2 in the nested NSD files.

In the embodiment of this application, the deployment policy used to indicate that the associated VNF is deployed in the tenant's resource pool (including the deployment policy of the user scope identifier, that is, the deployment policy whose scope is tenant, such as group_3, group_c), due to the application of the deployment policy The scope is all VNFs of the tenant, not only some VNFs of the tenant, and the deployment task ID in all deployment policies can be empty. Of course, the deployment task ID in the deployment strategy may not be empty, and this application does not limit this.

In this embodiment, the first deployment strategy and the second deployment strategy have the same first identifier and second identifier in addition to the same user identifier and deployment task identifier. Of course, in the case where the first deployment strategy and the second deployment strategy have the same user ID and deployment task ID, only one of the first deployment strategy and the second deployment strategy may have the first ID and the second ID. This application is not limited.

402-405: The OSS/BSS uploads the nested NSD file, the first NSD file and the second NSD file to the NFVO, and applies to the NFVO for the first NS instance ID of the first NS and the second NS instance ID of the second NS instance.

Steps 402-405 are similar to steps 202 to 205, so details will not be repeated here.

406: The OSS/BSS sends a first request message for instantiating the first NS and the second NS to the NFVO.

407: The NFVO executes a process of instantiating the second VNF according to the first request message and the nested NSD file, the first NSD file, and the second NSD file.

Specifically, NFVO compares at least one first deployment strategy in the first NSD file and at least one second deployment strategy in the second NSD file, and determines the first deployment strategy and the second deployment strategy with the same user ID and deployment task ID. Policy, to determine whether the associated first VNF and the second VNF share resource deployment.

Exemplarily, NFVO obtains and parses the nested NSD file, obtains the first NSD file according to the first NSD file identifier in the nested NSD file, and obtains the second NSD file according to the second NSD file. NFVO determines that the affinityOrAntiAffinity in group_3 in the first NSD file and group_c in the second NSD file are both AFFINITY, the scope is both tenant and the tenantID is tenant-A, then determine the VNF1 and VNF2 associated with group_3 and the VNF associated with group_c Both VNF3 and VNF4 are deployed in the same user resource pool.

Further, group_1 in the first NSD file and group_a in the second NSD file have the same tenantId and deploymentId, thus indicating that group_a and group_1 have the same deployment strategy, and their associated objects VNF1 and VNF3 need to follow the same deployment strategy. Affinity and anti-affinity rules for . The affinityOrAntiAffinity in group_a and group_1 is AFFINITY, and the scope is NFVI-NODE, that is, VNF1 and VNF3 have affinity on physical nodes and need to be deployed on the same physical node.

Further, group_2 in the first NSD file and group_b in the second NSD file have the same tenantId and deploymentId, thus indicating that group_2 and group_b have the same deployment strategy, and their associated objects VNF2 and VNF4 need to follow the same deployment strategy deployment strategy. The affinityOrAntiAffinity in group_2 and group_b is AntiAffinity, and the scope is NFVI-NODE, that is, VNF2 and VNF4 are anti-affinities of physical nodes, and need to be deployed on different physical nodes.

In this embodiment, the NFVO may first send an instruction message to the VNFM to instantiate the first VNF to complete the deployment of the first NS, and receive the physical node or virtual node information returned by the VNFM to deploy the first VNF. Then according to the affinity and anti-affinity relationship determined by the associated deployment strategy between the second VNF and the first VNF, the NFVO sends an instruction message to instantiate the second VNF to the VNFM, and the instruction message carries the physical node or virtual node information of the first VNF , so that the VNFM deploys the second VNF on the same physical node or virtual node, or on different physical nodes or virtual nodes.

Exemplarily, the NFVO may first instruct the VNFM to complete the deployment of the VNF1 and VNF2 in the first NS according to the first NSD file, and obtain the physical nodes on which the VNF1 and VNF2 are deployed. Then instruct the VNFM to complete the deployment of VNF3 and VNF4 according to the second NSD file. When deploying VNF3, according to the physical node where the deployed VNF1 is located, it is provided to the VNFM to complete the deployment of VNF3, so as to realize the common physical machine deployment of VNF1 and VNF3. When deploying VNF4, according to the physical node where the deployed VNF2 is located, provide it to VNFM and instruct VNFM to use different physical nodes to complete the deployment of VNF4, so as to realize the isolated deployment of physical nodes of VNF2 and VNF4.

408-411: The first VNF and the first VL, as well as the second VNF and the second VL are created, and the deployment of the first NS and the second NS is completed.

Steps 408-411 are similar to steps 209-212 and will not be repeated here.

In this embodiment, for multiple NSs that need to be deployed together, the corresponding deployment strategy is uploaded to NFVO by means of nested NSD, so that NFVO can use the user identifier, deployment task identifier, first identifier, and second Identify and determine the deployment requirements among the VNFs of multiple NSs, so as to allocate resources for the VNFs in these NSs according to the deployment requirements, and complete the deployment of NSs.

In some other implementations, the NSD file may not be expanded, that is, the first deployment strategy and the second deployment strategy are not carried in the NSD file, but the OSS/BSS requests the instantiation of the first NS and the second NS. The message carries the first deployment strategy and the second deployment strategy. For details, refer to the update message or the format of the deployment strategy in the second request message in the second embodiment of the network service deployment method, so details are not repeated here.

As shown in FIG. 10 , FIG. 10 is a schematic structural diagram of an embodiment of NFVO provided by the embodiment of the present application. In this embodiment, NFVO500 includes:

The obtaining module 501 is configured to obtain a first virtualized network function VNF associated with the first deployment strategy and a second VNF associated with the second deployment strategy, the first VNF belongs to the first network service NS, and the second VNF belongs to the second NS, The first deployment strategy and the second deployment strategy include the same user identifier and deployment task identifier, and the second deployment strategy further includes a first identifier, and the first identifier is used to indicate resource affinity or anti-affinity.

A determining module 502, configured to determine whether the first VNF and the second VNF are deployed on the same resource according to the first identifier.

In some other implementation manners, NFVO500 also includes a receiving module 503, configured to receive an update message sent by the operation and business support system OSS/BSS, the update message is used to update the deployment strategy of the first NS, and the update message includes the first deployment strategy . The acquiring module 501 is also configured to acquire the first deployment strategy from the update message.

In some other implementation manners, NFVO500 further includes a receiving module 503, configured to receive a first network service description template NSD file corresponding to the first NS uploaded by the OSS/BSS, and the first NSD file includes the first deployment strategy. The acquiring module 501 is further configured to acquire the first deployment strategy from the first NSD file.

In some other implementation manners, the receiving module 503 is further configured to receive a request message sent by the OSS/BSS for instructing instantiation of the second NS, where the request message includes the second deployment strategy. The acquiring module 501 is further configured to acquire the second deployment policy from the request message.

In some other implementation manners, the receiving module 503 is further configured to receive a second NSD file corresponding to the second NS uploaded by the OSS/BSS, where the second NSD file includes the second deployment strategy. The acquiring module 501 is further configured to acquire the second deployment policy from the second NSD file.

In some other implementation manners, the receiving module 503 is configured to receive the first NSD file corresponding to the first NS and the second NSD file corresponding to the second NS uploaded by the OSS/BSS, the first NSD file includes the first deployment strategy, the second NSD file The second NSD file includes the second deployment policy. The acquiring module 501 is also configured to acquire the first deployment strategy from the first NSD file and the second deployment strategy from the second NSD file.

Wherein, the second deployment strategy further includes a second identifier, and the second identifier is used to indicate the scope of application of the second deployment strategy.

In some other implementations, the first identifier is an affinity identifier, and the second identifier is a user-scope identifier, and the determination module 502 is specifically configured to determine that the first VNF and the second VNF are deployed on the same user according to the affinity identifier and the user-scope identifier. resource pool.

In some other implementation manners, the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a physical node range identifier, and the determining module 502 is specifically configured to determine the first VNF and The second VNF is deployed on the same physical node, or it is determined according to the anti-affinity identifier and the physical node range identifier that the first VNF and the second VNF are deployed on different physical nodes.

In some other implementation manners, the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a virtual node range identifier, and the determination module 02 is specifically configured to determine the first VNF and The second VNF is deployed on the same virtual node, or it is determined according to the anti-affinity identifier and the virtual node range identifier that the first VNF and the second VNF are deployed on different virtual nodes.

In some other implementation manners, the first deployment strategy further includes the same first identifier and/or second identifier as the second deployment strategy.

In some other implementation manners, the receiving module 503 is configured to receive a request message for instantiating the second NS sent by the OSS/BSS. NFVO500 also includes a sending module 504, configured to send an indication message of instantiating a second VNF to the VNFM in response to the request message, where the indication message is used to indicate whether the second VNF is instantiated in the same resource pool/physical node/virtual node as the first VNF .

As shown in FIG. 11 , FIG. 11 is a schematic structural diagram of another embodiment of NFVO provided by the embodiment of the present application. In this embodiment, the NFVO 600 may include one or more processors 601, a memory 602, and a transceiver 603, and the memory 602 stores one or more application programs or data. The transceiver 603 is used to send and receive messages with the transceivers of the OSS/BSS and the VNFM.

Wherein, the processor 601 may be one or more chips, or one or more integrated circuits. For example, the processor 601 may be one or more field-programmable gate array (field-programmable gate array, FPGA), application specific integrated circuit (ASIC), system chip (system on chip, SoC), central processing Central processor unit (CPU), network processor (network processor, NP), digital signal processing circuit (digital signal processor, DSP), microcontroller (micro controller unit, MCU), programmable logic device (programmable logic device , PLD) or other integrated chips, or any combination of the above chips or processors, etc.

Memory 602 may be volatile storage or persistent storage. The program stored in the memory 602 may include one or more modules, and each module may include a series of instructions to operate on the server. Furthermore, the processor 601 may be configured to communicate with the memory 602 , and execute a series of instruction operations in the memory 602 on the NFVO 600 .

The processor 601 may execute the operations performed by the NFVO in the foregoing embodiments shown in FIGS. 2 to 4 , and details are not described here again.

Those skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

If the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or part of the contribution to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), magnetic disk or optical disc, etc., which can store program codes. .

Claims

A network service deployment method, characterized in that the method comprises:

The network function virtualization orchestrator NFVO obtains the first virtualized network function VNF associated with the first deployment strategy, and the second VNF associated with the second deployment strategy, the first VNF belongs to the first network service NS, and the second VNF Belonging to the second NS, the first deployment policy and the second deployment policy include the same user ID and deployment task ID, and the second deployment policy also includes a first ID, and the first ID is used to indicate resource affinity or anti-affinity;

The NFVO determines whether the first VNF and the second VNF are deployed on the same resource according to the first identifier.
The method according to claim 1, wherein the first NS is a deployed NS, the second NS is a NS to be deployed, and the network function virtualization orchestrator NFVO obtains the first deployment policy association Before the first virtualized network function VNF, and the second VNF associated with the second deployment policy, further include:

The NFVO receives an update message sent by an operation and business support system OSS/BSS, the update message is used to update the deployment strategy of the first NS, and the update message includes the first deployment strategy;

The NFVO acquires the first deployment policy from the update message.
The method according to claim 1, wherein the first NS is a deployed NS, the second NS is a NS to be deployed, and the network function virtualization orchestrator NFVO obtains the first deployment policy association Before the first virtualized network function VNF, and the second VNF associated with the second deployment policy, further include:

The NFVO receives the first network service description template NSD file corresponding to the first NS uploaded by the OSS/BSS, and the first NSD file includes the first deployment strategy;

The NFVO obtains the first deployment policy from the first NSD file.
The method according to claim 2 or 3, wherein the network function virtualization orchestrator NFVO obtains the first virtualized network function VNF associated with the first deployment strategy, and the second VNF associated with the second deployment strategy. ,Also includes:

The NFVO receives a request message sent by the OSS/BSS for instructing instantiation of the second NS, where the request message includes the second deployment strategy;

The NFVO acquires the second deployment policy from the request message.
The method according to claim 2 or 3, wherein the network function virtualization orchestrator NFVO obtains the first virtualized network function VNF associated with the first deployment strategy, and the second VNF associated with the second deployment strategy. ,Also includes:

The NFVO receives a second NSD file corresponding to the second NS uploaded by the OSS/BSS, and the second NSD file includes the second deployment strategy;

The NFVO obtains the second deployment policy from the second NSD file.
The method according to claim 1, wherein both the first NS and the second NS are NSs to be deployed, and the network function virtualization orchestrator NFVO obtains the first virtualization associated with the first deployment policy. Before the network function VNF, and the second VNF associated with the second deployment policy, include:

The NFVO receives the first NSD file corresponding to the first NS and the second NSD file corresponding to the second NS uploaded by the OSS/BSS, the first NSD file includes the first deployment strategy, and the The second NSD file includes the second deployment strategy;

The NFVO obtains the first deployment strategy from the first NSD file, and the second deployment strategy from the second NSD file.
The method according to any one of claims 1 to 6, wherein the second deployment strategy further includes a second identifier, and the second identifier is used to indicate an application scope of the second deployment strategy.
The method according to claim 7, wherein the first identifier is an affinity identifier, the second identifier is a user scope identifier, and the NFVO determines the relationship between the first VNF and the first VNF according to the first identifier. Whether the second VNF is deployed with shared resources includes:

The NFVO determines, according to the affinity identifier and the user range identifier, that the first VNF and the second VNF are deployed in the same user resource pool.
The method according to claim 7, wherein the first identifier is an affinity identifier or an anti-affinity identifier, the second identifier is a physical node range identifier, and the NFVO determines the Whether the first VNF and the second VNF share resource deployment includes:

The NFVO determines that the first VNF and the second VNF are deployed on the same physical node according to the affinity ID and the physical node range ID, or determines according to the anti-affinity ID and the physical node range ID The first VNF and the second VNF are deployed on different physical nodes.
The method according to claim 7, wherein the first identifier is an affinity identifier or an anti-affinity identifier, the second identifier is a virtual node range identifier, and the NFVO determines the Whether the first VNF and the second VNF share resource deployment includes:

The NFVO determines that the first VNF and the second VNF are deployed on the same virtual node according to the affinity ID and the virtual node range ID, or determines according to the anti-affinity ID and the virtual node range ID The first VNF and the second VNF are deployed on different virtual nodes.
The method according to any one of claims 7 to 10, wherein the first deployment strategy further includes the same first identifier and/or the second identifier as the second deployment strategy.
The method according to any one of claims 1 to 11, further comprising:

The NFVO receives a request message for instantiating the second NS sent by the OSS/BSS;

The NFVO sends, in response to the request message, an indication message for instantiating the second VNF to the virtualization function manager VNFM, where the indication message includes location information for instantiating the second VNF, and the location information is The NFVO determines whether the first VNF and the second VNF share resources and allocate them to the second VNF after deployment.
A network service deployment method, characterized in that the method comprises:

The operation and business support system OSS/BS sends the first deployment strategy and the second deployment strategy to the network function virtualization orchestrator NFVO;

The NFVO judges whether the first deployment strategy and the second deployment strategy include the same user identifier and deployment task identifier;

If yes, the NFVO acquires the first virtualized network function VNF associated with the first deployment strategy and the second VNF associated with the second deployment strategy, the first VNF belongs to the first network service NS, The second VNF belongs to a second NS;

The NFVO determines whether the first VNF and the second VNF are deployed on the same resource according to a first identifier in the second deployment policy, where the first identifier is used to indicate resource affinity or anti-affinity.
The method according to claim 13, further comprising:

The OSS/BS sends a request message for instantiating the second NS to the NFVO;

The NFVO sends, in response to the request message, an indication message for instantiating the second VNF to the virtualized network function manager VNFM, where the indication message includes location information for instantiating the second VNF, and the location information is The NFVO determines whether the first VNF and the second VNF share resources and allocate them to the second VNF after deployment;

The VNFM instantiates the second VNF at the node corresponding to the location information according to the indication message.
A network function virtualization orchestrator NFVO is characterized in that the NFVO includes:

An acquisition module, configured to acquire a first virtualized network function VNF associated with a first deployment strategy, and a second VNF associated with a second deployment strategy, the first VNF belongs to the first network service NS, and the second VNF belongs to the second VNF Two NSs, the first deployment policy and the second deployment policy include the same user ID and deployment task ID, and the second deployment policy also includes a first ID, and the first ID is used to indicate resource affinity or anti-affinity;

A determining module, configured to determine, according to the first identifier, whether the first VNF and the second VNF are co-resource-deployed.
The NFVO according to claim 15, wherein the NFVO further comprises:

A receiving module, configured to receive an update message sent by an operation and business support system OSS/BSS, where the update message is used to update the deployment strategy of the first NS, and the update message includes the first deployment strategy;

The acquiring module is further configured to acquire the first deployment strategy from the update message.
The NFVO according to claim 15, wherein the NFVO further comprises:

A receiving module, configured to receive a first network service description template NSD file corresponding to the first NS uploaded by the OSS/BSS, where the first NSD file includes the first deployment strategy;

The acquiring module is further configured to acquire the first deployment strategy from the first NSD file.
NFVO according to claim 16 or 17, characterized in that,

The receiving module is further configured to receive a request message sent by the OSS/BSS for instructing instantiation of the second NS, where the request message includes the second deployment strategy;

The acquiring module is further configured to acquire the second deployment policy from the request message.
NFVO according to claim 16 or 17, characterized in that,

The receiving module is further configured to receive a second NSD file corresponding to the second NS uploaded by the OSS/BSS, where the second NSD file includes the second deployment strategy;

The acquiring module is further configured to acquire the second deployment policy from the second NSD file.
The NFVO according to claim 15, wherein the NFVO further comprises:

A receiving module, configured to receive a first NSD file corresponding to the first NS and a second NSD file corresponding to the second NS uploaded by the OSS/BSS, the first NSD file includes a first deployment strategy, and the The second NSD file includes a second deployment strategy;

The acquiring module is further configured to acquire the first deployment strategy from the first NSD file, and the second deployment strategy from the second NSD file.
The NFVO according to any one of claims 15 to 20, wherein the second deployment strategy further includes a second identifier, and the second identifier is used to indicate an application scope of the second deployment strategy.
The NFVO according to claim 21, wherein the first identifier is an affinity identifier, the second identifier is a user range identifier, and the determining module is specifically used for:

According to the affinity identifier and the user range identifier, it is determined that the first VNF and the second VNF are deployed in the same user resource pool.
The NFVO according to claim 21, wherein the first identifier is an affinity identifier or an anti-affinity identifier, the second identifier is a physical node range identifier, and the determining module is specifically used for:

Determine that the first VNF and the second VNF are deployed on the same physical node according to the affinity ID and the physical node range ID, or determine that the second VNF is deployed on the same physical node according to the anti-affinity ID and the physical node range ID A VNF and the second VNF are deployed on different physical nodes.
The NFVO according to claim 21, wherein the first identifier is an affinity identifier or an anti-affinity identifier, and the second identifier is a virtual node range identifier, and the determining module is specifically used for:

Determine that the first VNF and the second VNF are deployed on the same virtual node according to the affinity ID and the virtual node range ID, or determine that the second VNF is deployed according to the anti-affinity ID and the virtual node range ID A VNF and the second VNF are deployed on different virtual nodes.
The NFVO according to any one of claims 21 to 24, wherein the first deployment strategy further includes the same first identifier and/or the second identifier as the second deployment strategy.
The NFVO according to any one of claims 15 to 25, wherein the NFVO further comprises:

a receiving module, configured to receive a request message sent by the OSS/BSS to instantiate the second NS;

A sending module, configured to send an indication message of instantiating the second VNF to the VNFM in response to the request message, where the indication message is used to indicate whether the second VNF is instantiated in the same VNF as the first VNF Resource pool/the physical node/the virtual node.
A network function virtualization orchestrator NFVO is characterized in that it includes:

A processor, a memory, and a transceiver, wherein the memory stores program codes, and the processor invokes the program codes stored in the memory, so that the network service deployment device executes the method described in any one of claims 1-12. The network service deployment method described above.
A network function virtualization NFV system, characterized in that the system includes an operation and business support system OSS/BSS and a network function virtualization orchestrator NFVO according to any one of claims 15 to 27;

The OSS/BSS is configured to send a first deployment policy and a second deployment policy including a user ID and a deployment task ID to the NFVO, the second deployment policy also includes a first ID, and the first ID is used to indicate resource affinity or anti-affinity, the first deployment strategy is associated with the first VNF, and the second NS is associated with the second VNF;

The NFVO is configured to determine whether the first VNF and the second VNF are deployed on the same resource according to the first identifier in the second deployment policy.
The system of claim 28, further comprising a virtualized network function manager (VNFM);

The NFVO is further configured to send an indication message for instantiating the second VNF to the VNFM, where the indication message includes location information for deploying the second VNF, and the location information determines the second VNF for the NFVO. Whether a VNF shares resources with the second VNF and is allocated to the second VNF after deployment;

The VNFM is configured to instantiate the second VNF at the node corresponding to the location information according to the indication message.