WO2023030218A1 - Procédé de déploiement de service de réseau, nfvo et système nfv - Google Patents

Procédé de déploiement de service de réseau, nfvo et système nfv Download PDF

Info

Publication number
WO2023030218A1
WO2023030218A1 PCT/CN2022/115397 CN2022115397W WO2023030218A1 WO 2023030218 A1 WO2023030218 A1 WO 2023030218A1 CN 2022115397 W CN2022115397 W CN 2022115397W WO 2023030218 A1 WO2023030218 A1 WO 2023030218A1
Authority
WO
WIPO (PCT)
Prior art keywords
vnf
deployment
nfvo
identifier
affinity
Prior art date
Application number
PCT/CN2022/115397
Other languages
English (en)
Chinese (zh)
Inventor
李世涛
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2023030218A1 publication Critical patent/WO2023030218A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • 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.
  • Network function virtualization 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.
  • VNFs 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.
  • 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.
  • 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.
  • a first ID which is used to indicate the affinity or Anti-affinity
  • the first NS is the deployed NS
  • the second NS is the NS to be deployed
  • the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy
  • the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy
  • the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy
  • 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.
  • 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,
  • formulating the first deployment policy according to the deployment requirements of the second NS can improve the flexibility of formulating the first deployment policy.
  • the first NS is the deployed NS
  • the second NS is the NS to be deployed
  • the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy
  • the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy
  • the network function virtualization orchestrator NFVO acquires the first virtualized network function VNF associated with the first deployment policy
  • 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.
  • 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.
  • the network function virtualization orchestrator NFVO 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.
  • the network function virtualization orchestrator NFVO 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.
  • the network function virtualization orchestrator NFVO 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.
  • 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.
  • both the first NS and the second NS are NS to be deployed
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first deployment strategy further includes the same first identifier and/or second identifier as the second deployment strategy.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 first identifier is an affinity identifier
  • the second identifier is a user-scope identifier
  • 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 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.
  • the first identifier is an affinity identifier or an anti-affinity identifier
  • the second identifier is a physical node range identifier
  • 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.
  • the first identifier is an affinity identifier or an anti-affinity identifier
  • the second identifier is a virtual node range identifier
  • 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.
  • the first deployment strategy further includes the same first identifier and/or second identifier as the second deployment strategy.
  • 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.
  • 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
  • the first ID is used to indicate the affinity of resources Or anti-affinity
  • the first deployment strategy is associated with the first VNF
  • 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.
  • VNFM virtualized network function manager
  • 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.
  • FIG. 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.
  • FIG. 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.
  • 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.
  • NFV network function virtualization
  • 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.
  • NS network service
  • IP multimedia subsystem IP multimedia subsystem
  • VNF virtualized network function
  • 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
  • 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.
  • VDU virtualization deployment unit
  • CPD connection point template
  • VLD virtual connection template
  • 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.
  • 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.
  • OSS/BSS operations support system and business support system
  • VNF manager virtualization orchestrator
  • VNFM virtual network function manager
  • VIM virtual infrastructure management
  • network functions virtualization infrastructure network functions virtualization infrastructure
  • EM equipment management system
  • 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.
  • 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.
  • 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.
  • 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.
  • OSS/BSS101 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.
  • 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.
  • 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.
  • resource sharing or isolation may be complete sharing or isolation between VNFs 107 of different NSs, or partial VNF sharing or partial VNF isolation.
  • OSS/BSS101 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.
  • the deployment policy includes a user ID, a deployment task ID, and a first ID.
  • 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.
  • 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.
  • the first identifier is an affinity identifier
  • the VNF107 associated with the same deployment task of the same tenant can share resource deployment;
  • 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.
  • 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.
  • the first VNF is any one of at least one VNF in the first NS
  • 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:
  • the NFVO 102 determines that the first VNF and the second VNF are deployed in the same user resource pool.
  • 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.
  • the NFVO 102 determines that the first VNF and the second VNF are deployed on the same physical node.
  • the NFVO 102 determines that the first VNF and the second VNF are deployed on the same virtual node.
  • the NFVO 102 determines that the first VNF and the second VNF are deployed on different physical nodes.
  • the NFVO 102 determines that the first VNF and the second VNF are deployed on different virtual nodes.
  • 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.
  • the first deployment strategy is associated with two first VNFs
  • the second deployment strategy is associated with three second VNFs
  • the user identifier and deployment task identifier in the first deployment strategy and the second deployment strategy are the same
  • the first identifier is Anti-affinity ID
  • the second ID is a physical node range ID
  • the five VNFs need to be isolated from each other, that is, they are deployed on five different physical nodes
  • 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.
  • VNF 107 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.
  • the NFVO102 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.
  • the location information may be a specific physical node or virtual node.
  • 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.
  • 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.
  • 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.
  • FIG. 2 is a schematic flowchart of a first embodiment of a network service deployment method provided in an embodiment of the present application.
  • the first NS is the NS that has been deployed earlier
  • the second NS is the NS to be deployed. This embodiment includes the following steps:
  • 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.
  • 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.
  • VNF1 and VNF2 two first VNFs
  • 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.
  • 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.
  • a group is a deployment strategy
  • an NSD file may include at least one deployment strategy
  • a deployment strategy may be associated with at least one VNF.
  • 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.
  • the affinityOrAntiAffinityGroupId field defines the deployment strategy associated with the VNF.
  • VNF1 is associated with two first deployment strategies (group_1, group_3)
  • 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.
  • 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.
  • the NFVO returns an upload success response to the OSS/BSS.
  • 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.
  • 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.
  • the OSS/BSS sends a first request message for instantiating the first NS to the NFVO.
  • 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.
  • VNF1 is located in city A
  • VNF2 is located in city B.
  • the first request message also carries the deploymentId and tenant_id information assigned to each group.
  • the allocation information in this embodiment is as follows:
  • tenantId tenant-A
  • tenantId tenant-A
  • tenantId tenant-A
  • the NFVO determines the first VNF that needs to be instantiated according to the first request message and the first NSD file.
  • the NFVO sends an instruction message for instantiating the first VNF to the VNFM.
  • 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.
  • the NFVO applies to the VIM for creating the first VL instance included in the first NSD file.
  • the VNFM returns to the NFVO a response that the first VNF instance is created successfully.
  • VIM returns to the NFVO a response that the first VL instance is created successfully.
  • the NFVO returns a first NS creation success response to the OSS/BSS.
  • 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.
  • the second NSD file may also adopt a file different from the first NSD file.
  • 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).
  • the OSS/BSS uploads a second NSD file to the NFVO, where the second NSD file includes the second deployment strategy.
  • FIG. 4 is a schematic diagram of the second NSD file provided by the present application.
  • the OSS/BSS sends a second request message for instantiating the second NS to the NFVO.
  • 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.
  • the allocation information of the second deployment strategy is as follows:
  • the NFVO executes the process of instantiating the second VNF according to the second request message and the second NSD file.
  • 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.
  • 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.
  • tenantId tenant-A
  • deploymentId ID-xyz
  • group_3 of the first NS is the same as group_c of the second NS.
  • VNF3 and VNF4 associated with group_c and VNF1 and VNF2 associated with group_3 need to meet the same deployment policy.
  • 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.
  • 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
  • group_1 is deployed
  • the associated VNF1 and the VNF3 associated with group_c need to meet the same deployment policy.
  • 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.
  • VM virtual machine
  • 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.
  • 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.
  • tenant-A and deploymentId ID-ABC
  • group_2 of the first NS is the same as group_b of the second NS.
  • VNF2 associated with group_2 and VNF4 associated with group_b must meet the same deployment policy.
  • 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).
  • 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.
  • VNFVO 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • the OSS/BSS chooses to deploy the second NS to provide services for the tenant Z according to the second requirement.
  • 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.
  • the first deployment strategy may have the following two application scenarios:
  • 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.
  • the specific content of the first deployment strategy is as follows:
  • 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.
  • 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.
  • the specific content of each first deployment strategy is as follows:
  • VNF_1_id is the instance ID of VNF1
  • 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
  • VNF_2_id is used to associate the second VNF with the second deployment strategy.
  • the OSS/BSS uploads the second NSD file of the second NS to the NFVO.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second request message may also include the following second deployment strategy:
  • 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.
  • the physical nodes deployed by all the second VNFs are different from the physical nodes deployed by all the first VNFs.
  • VNF1 and VNF3 are deployed on virtual machine nodes, and VNF2 and VNF4 are deployed on isolated physical nodes.
  • 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.
  • 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.
  • FIG. 6 is a schematic flowchart of a third embodiment of a network service deployment method provided in an embodiment of the present application.
  • the tenant needs to deploy at least two NSs, that is, both the first NS and the second NS are NSs to be deployed.
  • this embodiment It is achieved through the following steps:
  • OSS/BSS uses nested NSD files to deploy a network for tenant Z according to at least two network requirements of tenant Z.
  • 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.
  • FIG. 7 is a schematic diagram of a nested NSD file provided by this application.
  • the nested NSD file contains two NSD file identifiers, namely NSD-1 and NSD-2.
  • 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.
  • the first NSD file corresponding to NSD-1 in the nested NSD file includes the content shown in Figure 8
  • 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
  • FIG. 9 is a schematic diagram of a second NSD file corresponding to NSD-2 in the nested NSD files.
  • 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.
  • the deployment task ID in the deployment strategy may not be empty, and this application does not limit this.
  • 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.
  • 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.
  • 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.
  • the OSS/BSS sends a first request message for instantiating the first NS and the second NS to the NFVO.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • VNF3 may be 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.
  • VNF4 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.
  • Steps 408-411 are similar to steps 209-212 and will not be repeated here.
  • 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.
  • 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.
  • FIG. 10 is a schematic structural diagram of an embodiment of NFVO provided by the embodiment of the present application.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first identifier is an affinity identifier
  • the second identifier is a user-scope identifier
  • 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.
  • the first identifier is an affinity identifier or an anti-affinity identifier
  • the second identifier is a physical node range identifier
  • 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.
  • the first identifier is an affinity identifier or an anti-affinity identifier
  • the second identifier is a virtual node range identifier
  • 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.
  • the first deployment strategy further includes the same first identifier and/or second identifier as the second deployment strategy.
  • 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 .
  • FIG. 11 is a schematic structural diagram of another embodiment of NFVO provided by the embodiment of the present application.
  • 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.
  • the processor 601 may be one or more chips, or one or more integrated circuits.
  • 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.
  • field-programmable gate array field-programmable gate array
  • ASIC application specific integrated circuit
  • SoC system on chip
  • CPU central processing Central processor unit
  • network processor network processor
  • DSP digital signal processing circuit
  • microcontroller microcontroller
  • programmable logic device programmable logic device
  • PLD programmable logic device
  • 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.
  • 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.
  • the disclosed system, device and method can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented.
  • 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.
  • 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.
  • 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. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procédé de déploiement de service de réseau, un orchestrateur de virtualisation de fonction de réseau (NFVO) et un système NFV, destinés à être utilisés pour améliorer la flexibilité d'isolement ou de partage de ressources pendant un déploiement de service de réseau sont divulgués dans des modes de réalisation de la présente demande. Selon les modes de réalisation de la présente demande, le procédé consiste : à obtenir, par un NFVO, une première fonction de réseau virtualisée (VNF) associée à une première politique de déploiement et une seconde VNF associée à une seconde politique de déploiement, la première VNF et la seconde VNF appartenant à différents NS, la première politique de déploiement et la seconde politique de déploiement comprenant le même identifiant d'utilisateur et le même identifiant de tâche de déploiement, la seconde politique de déploiement comprenant en outre un premier identifiant, et le premier identifiant étant utilisé pour indiquer l'affinité ou l'anti-affinité d'une ressource ; et à déterminer, par le NFVO, en fonction du premier identifiant, si la première VNF et la seconde VNF sont dans un déploiement de ressource commun.
PCT/CN2022/115397 2021-08-31 2022-08-29 Procédé de déploiement de service de réseau, nfvo et système nfv WO2023030218A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111017188.7 2021-08-31
CN202111017188.7A CN115733743A (zh) 2021-08-31 2021-08-31 网络业务部署方法、nfvo以及nfv系统

Publications (1)

Publication Number Publication Date
WO2023030218A1 true WO2023030218A1 (fr) 2023-03-09

Family

ID=85291820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/115397 WO2023030218A1 (fr) 2021-08-31 2022-08-29 Procédé de déploiement de service de réseau, nfvo et système nfv

Country Status (2)

Country Link
CN (1) CN115733743A (fr)
WO (1) WO2023030218A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017173667A1 (fr) * 2016-04-08 2017-10-12 华为技术有限公司 Procédé et dispositif de gestion
CN108696373A (zh) * 2017-04-06 2018-10-23 华为技术有限公司 虚拟资源分配方法、nfvo和系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017173667A1 (fr) * 2016-04-08 2017-10-12 华为技术有限公司 Procédé et dispositif de gestion
CN108696373A (zh) * 2017-04-06 2018-10-23 华为技术有限公司 虚拟资源分配方法、nfvo和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUAWEI: "Adding requirements for affinity and anti-affinity information", 3GPP DRAFT; S5-163201 PCR TS 28.525 ADDING REQUIREMENTS FOR AFFINITY AND ANTI-AFFINITY INFORMATION, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG5, no. Santa Cruz de Tenerife (Spain); 20160523 - 2016052, 17 May 2016 (2016-05-17), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051117014 *

Also Published As

Publication number Publication date
CN115733743A (zh) 2023-03-03

Similar Documents

Publication Publication Date Title
CN110324164B (zh) 一种网络切片的部署方法及装置
US10701139B2 (en) Life cycle management method and apparatus
CN107689882B (zh) 一种虚拟化网络中业务部署的方法和装置
US10700947B2 (en) Life cycle management method and device for network service
EP3291499B1 (fr) Procédé et appareil pour extension de capacité de service de réseau
US11271827B2 (en) Network service life cycle management grant method and apparatus
WO2017045471A1 (fr) Procédé et appareil d'acquisition d'informations de chaîne de service dans un système de cloud computing
US20210326306A1 (en) Method and apparatus for deploying virtualised network function
WO2022056845A1 (fr) Procédé de gestion de groupe de conteneurs et système associé
EP3883183A1 (fr) Procédé et dispositif de gestion de virtualisation
WO2023030218A1 (fr) Procédé de déploiement de service de réseau, nfvo et système nfv
WO2018014351A1 (fr) Procédé et appareil de configuration de ressources
WO2019011180A1 (fr) Procédé et dispositif d'envoi de licence
US12035231B2 (en) Virtualization management method and apparatus
WO2022141293A1 (fr) Procédé et appareil de mise à l'échelle souple
WO2023066224A1 (fr) Procédé et appareil de déploiement d'un service de conteneur
WO2022126389A1 (fr) Procédé et dispositif d'établissement de connexion de réseau
CN111581203B (zh) 信息处理方法、装置及存储介质
WO2021129868A1 (fr) Procédé d'instanciation de service de réseau (ns) et orchestrateur de virtualisation de fonction de réseau (nfvo)
WO2022183796A1 (fr) Procédé de création de service de réseau (ns) et appareil associé
CN118118348A (zh) 一种虚拟化网络功能vnf的实例化方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22863354

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE