WO2021088444A1 - 实例化ns的方法及nfvo - Google Patents

实例化ns的方法及nfvo Download PDF

Info

Publication number
WO2021088444A1
WO2021088444A1 PCT/CN2020/107121 CN2020107121W WO2021088444A1 WO 2021088444 A1 WO2021088444 A1 WO 2021088444A1 CN 2020107121 W CN2020107121 W CN 2020107121W WO 2021088444 A1 WO2021088444 A1 WO 2021088444A1
Authority
WO
WIPO (PCT)
Prior art keywords
node type
vnf
identifier
vnfp
vnfd
Prior art date
Application number
PCT/CN2020/107121
Other languages
English (en)
French (fr)
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 华为技术有限公司
Priority to EP20885666.6A priority Critical patent/EP4040292A4/en
Publication of WO2021088444A1 publication Critical patent/WO2021088444A1/zh
Priority to US17/731,714 priority patent/US11929879B2/en

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
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • This application relates to the computer field, and in particular to a method of instantiating a network service (NS, network service) and a network function virtualization orchestrator (NFVO, network function virtualization orchestrator).
  • NS network service
  • NFVO network function virtualization orchestrator
  • Network function virtualization refers to the use of general hardware equipment and virtualization technology to carry the functions of special equipment in traditional networks, so that network functions and NS are no longer dependent on special equipment, thereby reducing the deployment of special equipment.
  • the high cost of equipment At the same time, various resources in the cloud platform can be flexibly shared, so as to quickly develop and deploy various new NSs in combination with actual business needs.
  • NFV introduces a virtualization layer, through network management and orchestration, virtualized network functions (VNF, virtualized network function) and life cycle management of NS are realized.
  • the NS usually contains one or more VNFs; that is, the NS is an upper-layer network service implemented by one or more VNFs.
  • the service requester can provide the service provider with network service description information (NSD, network Service descriptor) of the NS.
  • NSD network Service descriptor
  • NSD can also be called NS deployment template.
  • the virtualized network function description information (VNFD) of each VNF can be described by the node type of each VNF. Among them, VNFD can also be called VNF deployment template.
  • the service provider can parse the NSD to obtain the node type of one or more VNFs contained in the NSD; for each node type obtained, the VNFD used to instantiate the corresponding VNF can be determined, based on the determination The VNFD instantiates the corresponding VNF to complete the instantiation of the NS.
  • VNFP virtualized network function package
  • VNF package also contains the definition file of the node type of the VNF.
  • the definition file of the node type may not be included in the VNF package.
  • the node type of each VNF contained in the NSD needs to be manually processed, and it takes a lot of time to manually analyze the VNF package in order to determine the support instance If the VNFD identifier of the VNF corresponding to the node type is converted, the efficiency of instantiating the NS is low.
  • the embodiment of the present application provides a method for instantiating NS and NFVO, which are beneficial to improve the efficiency of instantiating NS.
  • a method for instantiating NS is provided, the method is applied to NFVO, and the method includes:
  • VNFPI virtualized network function package information
  • VNF package info virtualized network function package information
  • VNFM virtualized network function manager
  • the method further includes:
  • the VNFP includes a meta file, the meta file includes a declaration keyword, and the value of the declaration keyword is the node type;
  • the obtaining the node type from the VNFP includes: querying the declaration keyword in the metafile included in the VNFP, and obtaining the node type from the declaration keyword.
  • the VNFP includes a meta file, the meta file includes a declaration keyword, and the value of the declaration keyword is a storage path of the definition file of the node type in the VNFP;
  • the obtaining the node type from VNFP includes:
  • the method further includes:
  • the associating the node type with the VNFPI includes: determining the identifier of the VNFPI, and associating the node type with the identifier of the VNFPI;
  • the obtaining the VNFPI associated with the node type includes: obtaining the identifier of the VNFPI associated with the node type, and obtaining the VNFPI according to the identifier of the VNFPI.
  • the VNFP includes a manifest file, and the manifest file includes an identifier of the VNFD;
  • the obtaining the identifier of the VNFD from the VNFP includes: obtaining the identifier of the VNFD from the manifest file included in the VNFP.
  • an NFVO in a second aspect, is provided, and the NFVO includes:
  • the transceiver unit is used to receive an instantiated network service NS request
  • the processing unit is configured to determine the NSD according to the instantiation NS request, and the NSD contains the node type of the VNF; obtain the VNFPI associated with the node type, and obtain the VNFD identifier from the VNFPI; according to the VNFD The identity of the request VNFM to instantiate the VNF.
  • the processing unit is further configured to obtain the node type from the VNFP, associate the node type with the VNFPI; obtain the VNFD identifier from the VNFP, and store the VNFD identifier in the VNFD. In the VNFPI.
  • the VNFP includes a meta file, the meta file includes a declaration keyword, and the value of the declaration keyword is the node type;
  • the processing unit is specifically configured to query the declaration keyword in the metafile included in the VNFP, and obtain the node type from the declaration keyword.
  • the VNFP includes a meta file, the meta file includes a declaration keyword, and the value of the declaration keyword is a storage path of the definition file of the node type in the VNFP;
  • the processing unit is specifically configured to query the declaration keyword in the metafile contained in the VNFP, and obtain the storage path of the definition file of the node type in the VNFP from the declaration keyword ; Acquire the node type from the definition file of the node type according to the storage path.
  • the processing unit is further configured to determine the address information of the definition file of the node type according to the storage path and the storage location of the VNFP;
  • the transceiver unit is further configured to send the node type and the address information to the service requester, so that the service requester generates the NSD, and the NSD includes the node type and the address information.
  • the processing unit is specifically configured to determine the identifier of the VNFPI, to associate the node type with the identifier of the VNFPI; and specifically to obtain the identifier of the VNFPI associated with the node type, and according to Obtain the VNFPI by the identifier of the VNFPI.
  • the VNFP includes a manifest file, and the manifest file includes an identifier of the VNFD;
  • the processing unit is specifically configured to obtain the identifier of the VNFD from the manifest file included in the VNFP.
  • a computer-readable storage medium for storing instructions that, when the instructions are executed by a processor of a computing device, enable the computing device to implement the method described in any one of the above-mentioned first aspects .
  • a computer program product includes computer program code.
  • the computer program code runs on a computing device, the computing device executes any one of the above-mentioned aspects of the first aspect. The method described.
  • a computing device including a memory and a processor, the memory is stored with executable code, and when the processor executes the executable code, it implements any one of the foregoing aspects of the first aspect. Methods.
  • a chip system in a sixth aspect, includes a processor for implementing the functions of the NFVO described in the above aspects, for example, receiving or processing the data and/or involved in the method of the first aspect above. Or information.
  • the chip system further includes a memory, and the memory is used to store program instructions and/or data.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • the NFVO can associate the VNF package info with the node type of the VNF contained in the NSD, and store the VNFD identifier in the VNF package info.
  • NFVO receives a request to instantiate an NS, it can first determine the NSD of the NS that needs to be instantiated. For the node type of the VNF contained in the NSD, obtain the VNF package info associated with the node type, and then from the VNF package info Obtain the VNFD ID. After that, the NFVO can request the VNFM to instantiate the VNF according to the VNFD's identification.
  • Fig. 1 is a system framework diagram of a network function virtualization system to which an embodiment of the application is applicable.
  • FIG. 2 is a schematic flowchart of a method for instantiating NS provided in an embodiment of the application.
  • Fig. 3 is a file structure diagram of an exemplary VNF package in an embodiment of the application.
  • FIG. 4 is a schematic flowchart of another method for instantiating NS provided in an embodiment of the application.
  • Figure 5 is a schematic structural diagram of an NFVO provided in an embodiment of the application.
  • Fig. 1 is a system framework diagram of a network function virtualization system to which an embodiment of the application is applicable.
  • the NFV system 100 mainly includes the following functional entities:
  • NFVO102 is mainly used for life cycle management of NS, and for the allocation and scheduling of virtual resources in network functions virtualization infrastructure (NFVI, network functions virtualization infrastructure) 104.
  • the NFVO 102 may communicate with one or more VNFM 106 to perform related operations of instantiating the NS, such as sending corresponding configuration information to the VNFM 106, and requesting the status information of one or more VNF 108 from the VNFM 106.
  • the NFVO 102 can also communicate with a virtual infrastructure manager (VIM, virtualized infrastructure manager) 110 to perform allocation and/or reservation of various resources in the NFVI 104, and exchange resource configuration and status information.
  • VIP virtual infrastructure manager
  • the VNFM106 is mainly responsible for the life cycle management of one or more VNFs 108, such as instantiating the VNF 108, updating the VNF 108, querying the VNF 108, scaling the VNF 108, and terminating the VNF 108.
  • the VNFM106 can communicate with the VNF108 to manage the life cycle of the VNF108 and exchange configuration information and status information with the VNF.
  • the NFV system 100 may include one or more VNFMs 106, and each VNFM 106 performs life cycle management on different types of VNFs 108 respectively.
  • NFVI104 refers to the infrastructure of the NFV system 100, which includes hardware components, software components and their combination to establish a virtualized environment, and deploy, manage, and implement VNF108 in the virtualized environment.
  • NFVI104 can at least include computing hardware 1041, storage hardware 1042, network hardware 1043; the virtualization layer 1044 of NFVI104 can abstract the aforementioned hardware, decouple each hardware and VNF108, and obtain corresponding virtual computing resources 1045, virtual storage resources 1046, and virtual network resources 1047, so as to provide virtual machines and other forms of virtualized containers for the VNF 108.
  • the VIM 110 is mainly used to control and manage the interaction between the VNF 108 and the computing hardware 1041, the storage hardware 1042, the network hardware 1043, the virtual computing resources 1045, the virtual storage resources 1046, and the virtual network resources 1047.
  • the VIM 110 can perform resource management functions, such as adding corresponding virtual resources to virtual machines or other forms of virtual containers, and collecting fault information of the NFVI 104 during system operation.
  • the VIM 110 can communicate with the VNFM 106, such as receiving a resource allocation request from the VNFM 106, and feeding back resource configuration and status information to the VNFM 106.
  • the VNF 108 can run in one or more virtual machines or other forms of virtual containers, corresponding to a set of network functions originally implemented by dedicated devices.
  • the equipment management system (EMS, equipment management system) 112 may be used to configure and manage the VNF 108, and initiate life cycle management operations such as the instantiation of a new VNF 108 to the VNFM 106. It can be understood that one or more EMS 112 may be included in the NFV system 100.
  • the operations support system (OSS, operations support system) or the business support system (BSS, business support system) 114 can support various end-to-end telecommunication services.
  • the management functions supported by OSS can include network configuration, service provision, fault management, etc.; BSS can be used for order processing, payment, income and other related services, and supports product management, order management, revenue management, and customer management functions.
  • the OSS/BSS114 can be used as the service requester to request the NFVO to instantiate the NS, and the computing device on which the OSS/BSS114 or OSS/BSS114 depends can generally be referred to as the service requester.
  • the aforementioned functional entities may be deployed in different computing devices, or some functional entities may be integrated into the same computing device.
  • the VNFD used to support the instantiation of the VNF included in the NS is usually located in the VNF package.
  • the VNF package contains the definition file of the node type of the VNF.
  • the definition file of the node type may not have a fixed storage path or file name in the VNF package. . Therefore, in the process of NFVO102 instantiating NS based on the NSD of NS, the node type of each VNF contained in the NSD needs to be manually processed, and it takes a lot of time to manually analyze the VNF package before it can be determined.
  • the efficiency of instantiating the NS is low.
  • NFVO can be used as a service provider to associate the VNF package info with the node type of the VNF contained in the NSD, and set it in the VNF package info
  • the identifier of the VNFD is stored in.
  • a service requester such as the OSS/BSS or computing device deploying OSS/BSS as shown in Figure 1
  • NFVO can instantiate the VNF contained in the NSD of the NS as required Node type, obtain the VNF package info associated with the node type, and then obtain the VNFD identifier from the VNF package info.
  • the NFVO can request the VNFM to instantiate the VNF according to the VNFD's identification.
  • the VNFM106 is a functional entity responsible for instantiating the VNF108.
  • the VNFM 106 may receive the VNF instance identifier creation request carrying the identifier of the VNFD from the NFVO 102, and create/allocate the VNF instance identifier corresponding to the identifier of the VNFD. After the VNF instance identifier created/allocated by the VNFM is returned to the NFVO, the NFVO may further send a VNF instantiation request carrying the VNF instance identifier to the VNFM.
  • the VNFM After the VNFM receives the VNF instantiation request carrying the VNF instance identifier from the NFVO, it can obtain the corresponding VNFD or the VNF package containing the VNFD according to the corresponding VNFD identifier; and then according to the VNFD obtained or the VNFD containing the VNFD
  • the VNF package applies for virtual resources from VIM110, and after applying for virtual resources, an instance of VNF108 is configured to complete the instantiation of VNF108. , And then complete the instantiation of NS.
  • an embodiment of the present application provides a method for instantiating NS.
  • the method is applied to NFVO and may include at least the following steps 21-27.
  • step 21 a request to instantiate an NS is received.
  • the instantiation NS request comes from the service requester, and the service requester includes but is not limited to the OSS or BSS as shown in FIG. 1.
  • the instantiation NS request is used to request the NFVO to instantiate the corresponding NS.
  • step 23 an NSD is determined according to the instantiated NS request, and the NSD contains the node type of the VNF.
  • the determined NSD is the NSD of the NS that needs to be deployed by the service requester sending the instantiated NS request.
  • the NFV may use any one of a variety of specifications to define the NSD of the NS, as well as the VNFD used to support the instantiation of each VNF included in the NS. Regardless of the NSD defined by any specification, the NSD should contain the node types of each VNF included in the NS that the service requester needs to deploy.
  • the NSD may further include one or more dynamic information required when instantiating a VNF, such as instantiation level, min number of instances, and maximum instance.
  • instantiation level such as instantiation level, min number of instances, and maximum instance.
  • the maximum number of instances, these dynamic information and the node type of the VNF can form the node information of the VNF in the NSD (or called the node definition of the VNF).
  • step 25 the VNF package info associated with the node type is obtained, and the VNFD identifier is obtained from the VNF package info.
  • the node type of each VNF is included in the NSD of the NS.
  • NFVO can quickly obtain support from the VNF package info associated with the node type Instantiate the VNFD identifier of the VNF corresponding to the node type.
  • step 27 the VNFM is requested to instantiate the VNF according to the identifier of the VNFD.
  • the VNFM After the VNFM receives the identifier carrying the VNFD, it can perform corresponding processing to complete the instantiation of the VNF, and then complete the instantiation of the NS.
  • each VNF may correspond to a VNF package.
  • the VNFD used to support instantiation of the VNF is included in the VNF package corresponding to the VNF, and the VNF package should also include the node type of the VNF and the VNFD identifier .
  • the NFVO before receiving the instantiation NS request from the service requester, can create a VNF package info in the NFVO for each VNF included in the NS that the service requester needs to deploy. , Obtain the node type of the VNF from the VNF package corresponding to the VNF, and associate the node type with the VNF package info; then obtain the VNFD identifier contained in the VNF package from the VNF package corresponding to the VNF, and add the The identifier of the VNFD is stored in the VNF package info.
  • the VNF package info created by NFVO can assign the VNF package info identifier, and associate the VNF package info identifier with the node type of the corresponding VNF, so as to associate the corresponding VNF package info with the node type of the corresponding VNF.
  • the node type is associated with the VNF package info.
  • the NFV may adopt any one of a variety of specifications to define the NSD of the NS and define the VNFD used to support the instantiation of each VNF contained in the NS.
  • NFV adopts the topology and orchestration specification for cloud applications (TOSCA, topology and orchestration specification for cloud applications) to define NSD and VNFD as examples, and exemplifies the technical solutions of the embodiments of this application. description.
  • the VNFD When TOSCA is used to define a VNFD, the VNFD is usually located in a VNF package in zip format, and the VNF package also complies with the packaging format defined by TOSCA.
  • the VNF package containing the VNFD may have a file structure as shown in FIG. 3.
  • the VNF package can contain a top-level file "TOSCA-Metadata", the "TOSCA-Metadata” contains the meta file “TOSCA-Meta”, and the "TOSCA-Meta” describes the basic information of the VNF package.
  • the meta file "TOSCA-Meta” can describe at least the following information of the VNF package:
  • CSAR-Version 1.1# The version number of the packaging format followed by the VNF package.
  • the version number is 1.1
  • OASIS TOSCA TC# The designer of the VNF package, for example, the designer can be OASIS TOSCA TC
  • Entry-Definitions definitions/Example_VNF1.yaml#The address of the entry file of the VNF package in the VNF package.
  • the file “Example_VNF1.yaml” is the TOSCA file in the VNF package that needs to be processed first except for the top-level file. This file can be Put it in the "definitions” folder under the VNF package; it should be noted that the entry file should be a "yaml" format file that conforms to the TOSCA grammar.
  • example_VNF1_Type.yaml can be a definition file of the node type of the VNF corresponding to the VNF package.
  • the definition file of the node type may have different names in different VNF packages and may be located in different positions in the VNF package.
  • the definition file of the node type of the VNF can include the node type of the VNF, and can also include the properties of the node type (properties), the descriptor identifier (descriptor_id) and the type of the descriptor identifier, the preference identifier (flavour_id), and preferences. Type of logo, etc.
  • the meta file of the VNF package contains a declaration keyword
  • the value of the declaration keyword is the VNF The node type of the VNF corresponding to the package.
  • the meta file "TOSCA-Meta" contained in the VNF package may contain the following information of the VNF package:
  • NFVO can query the declaration keywords from the metafile contained in the VNF package, and obtain the node type of the VNF corresponding to the VNF package from the declaration keywords. For example, query “Declaration” in "TOSCA-Meta” included in the VNF package, and obtain the value of "Declaration” "tosca.nodes.nfv.example_VNF1".
  • the meta file of the VNF package contains a declaration keyword
  • the value of the declaration keyword is: The storage path of the definition file of the node type of the VNF corresponding to the package in the VNF package.
  • the declaration keyword is "Declaration”
  • the node type contained in “example_VNF1_Type.yaml” is “tosca.nodes.nfv.example_VNF1”
  • the storage path of "example_VNF1_Type.yaml” in the VNF package is "definitions/example_VNF1_Type.yaml” "
  • the meta file "TOSCA-Meta" contained in the VNF package may contain the following information of the VNF package:
  • NFVO can query the declaration keywords from the metafile contained in the VNF package, and obtain the storage path of the VNF node type definition file corresponding to the VNF package in the VNF package from the declaration keywords, and then according to the obtained The storage path obtains the node type of the VNF corresponding to the VNF package from the node type definition file.
  • the VNFD contained in a VNF package is usually composed of multiple service modules (or called service files), and multiple service modules can be specifically divided into a top level service template and at least one low level service module ( low-level service template); among them, the top-level service module is usually defined as an entry file in the meta file included in the VNF package.
  • the VNFD included in the VNF package can include the top-level service module Example_VNF1.yaml and the low-level service modules VNF_DF1.yaml and VNF_DF2.yaml.
  • the location of Example_VNF1.yaml in the VNF package can be stored in the VNF package meta file TOSCA- Meta.
  • the top-level service module included in the VNF package is mainly used to describe the static information of the VNF corresponding to the VNF package. For example, describe the node type, properties, requirements and other information of the VNF.
  • Each low-level service module included in the VNF package represents a VNF deployment preference (VNF deployment flag).
  • VNF deployment flag When the VNF is instantiated, the VNF can be selected to deploy the VNF according to the preference identifier carried in the NSD of the NS that needs to be instantiated or the request for instantiation of the VNF. It can be understood that when VNFs are deployed corresponding to different deployment preferences, the requirements for virtual resources may be different; that is, the composition of different low-level service modules may be different.
  • VNF_DF2.yaml the deployment preferences described in VNF_DF2.yaml can be for scenarios where a large number of users are connected.
  • VDU_1 and VDU_2 two virtual deployment unit (VDU) resources, VDU_1 and VDU_2, are required to provide services together; described in VNF_DF1.yaml It is a scenario where a small number of users is connected. At this time, only one VDU_1 needs to be deployed to provide services.
  • each low-level service module contained in it can be associated with the top-level service module.
  • the low-level service module can be associated with the top-level service module by replacing the node type (node type) defined in the substitution mapping and the preference identifier (flavour_id) defined in the properties (properties).
  • top-level service module Example_VNF1.yaml included in the VNF package is described by the following method:
  • the node type "tosca.nodes.nfv.example_VNF1" can uniquely identify the VNFD to which the top-level service module belongs; the value "12345-xyz" of the descriptor identifier (descriptor_id) is the identifier of the VNFD to which the top-level service module belongs.
  • the preference identifier indicated in the instantiation VNF request is flavour1, and the flavour_id in Example_VNF1.yaml obtains the value of flavour in the instantiated VNF request through get_input(flavour), for example, flavour1.
  • the preference identifier contained in VNF_DF1.yaml is flavour1
  • the preference identifier contained in VNF_DF1.yaml is flavour2
  • both VNF_DF1.yaml and VNF_DF2.yaml contain the node type tosca.nodes.nfv of the VNF corresponding to the VNFpackage. example_VNF1.
  • Example_VNF1.yaml can be associated with the VNF_DF1.yaml in the two low-level service modules through tosca.nodes.nfv.example_VNF1 and flavour1, so that the VNFM can deploy the VNF through VNF_DF1.yaml, including the deployment of the VDU and virtual connections contained in VNF_DF1.yaml (VL, virtual link) and connection point (CP, connection point).
  • VL virtual link
  • CP connection point
  • the NFVO may obtain the VNFD identifier from the top-level service module of the VNFD included in the VNF package.
  • the VNF package may also include a manifest file, and the VNFD identifier is included in the manifest file.
  • the manifest file is an optional file in DOSCA.
  • the manifest file is usually used to store the certification and security-related information of the VNF package, and the basic information of the VNF package itself, such as storing the VNF package. Name, release date, version number, etc., the amount of information stored in the manifest file is relatively small.
  • the VNFD identifier is stored in the manifest file included in the VNF package. NFVO does not need to spend much time to analyze the VNFD included in the VNF package, and the VNF package can be quickly obtained from the manifest file containing a small amount of information. The identifier of the included VNFD.
  • a field/primary key (for example, vnfd_id) used to describe the identifier of the VNFD may be added to the manifest file, and the VNFD identifier may be stored in the manifest file as the value of the field/primary key.
  • "manifest.mf" can be a manifest file included in the VNF package.
  • the identifier of the VNF package and the identifier of the VNFD can be the same.
  • the VNF package may also include other files in addition to the above-exemplified files, such as mirroring files and script files required to deploy a VNF. Still referring to Figure 3, the VNF package can also include the file “files”, and under “files” can also include the file “ChangeLog.txt” for storing log information, and the file “image” for storing the pictures needed to instantiate the VNF. (s)", the file “tests” used to store test data, etc.
  • the NSD of the NS can usually contain the node information of each VNF included in the NS, the node type of each VNF is correspondingly included in the node information, and the definition file of the node type is included in the VNF package.
  • NFVO can analyze and verify the NSD based on the definition file of each VNF node type contained in the NS after obtaining the NSD of the NS that the service requester needs to deploy. .
  • NFVO can according to the storage of the VNF package before receiving the instantiation NS request from the service requester Location, the storage path of the VNF node type definition file contained in the VNF package in the VNF package, and determine the address information of the node type definition file; then, send the node type and address information to the service requester for service request The party generates an NSD containing the node type and the address information.
  • the node type of the VNF is tosca.nodes.nfv.example_VNF1
  • the storage path of the definition file example_VNF1_Type.yaml of this node type in the VNF package is definitions/Example_VNF1.yaml
  • the VNF package can be accessed in NFVO or NFVO
  • the storage location on the computing/storage device is NFVO/VNF package_1.
  • the address information of the definition file Example_VNF1.yaml of the node type is: NFVO/VNF package_1/definitions/Example_VNF1.yaml.
  • NFVO can obtain the NSD generated by the service requester before receiving the instantiation NS request from the service requester, and then according to the address information contained in the NSD, the NFVO or NFVO can Obtain the definition file of the node type from the VNF package stored on the accessed computing/storage device, and verify the NSD according to the definition file of the node type.
  • the process of information interaction between NFVO, OSS/BSS, and VNFM to complete the instantiation of NS will be exemplified.
  • the process of instantiating NS may specifically include the following steps 401-416.
  • Step 401 OSS/BSS sends a VNF package info creation request to NFVO.
  • the OSS/BSS can send a VNF package info creation request to the NFVO for each VNF included in the NS to be deployed.
  • Step 402 NFVO sends the identifier of VNF package info to OSS/BSS.
  • VNF package info is created by NFVO when it receives a VNF package info creation request from OSS/BSS.
  • the VNF package info is assigned by NFVO, and the VNF package info can be used in NFVO.
  • Step 403 The OSS/BSS sends the VNF package and the identifier of the VNF package info to the NFVO.
  • the OSS/BSS may also send the address information of the VNF package and the identifier of the VNF package info to the NFVO, so that the NFVO can obtain the VNF package according to the address information of the VNF package.
  • step 404 the NFVO queries the declaration key in the metafile of the VNF package, obtains the storage path from the declaration key, and obtains the node type of the VNF from the node type definition file contained in the VNF package according to the storage path.
  • the value of the declaration keyword is the storage path of the definition file of the node type of the VNF corresponding to the VNF package in the VNF package.
  • the value of the declaration key may also be the node type of the VNF corresponding to the VNF package.
  • Step 405 The NFVO obtains the identifier of the VNFD included in the VNF package from the manifest file included in the VNF package.
  • Step 406 The NFVO associates the node type of the VNF with the VNF package info, and stores the VNFD identifier in the VNF package info.
  • the NFVO can associate the node type of the VNF corresponding to the VNF package with the identifier of the VNF package info, so as to realize the association between the node type of the VNF and the VNF package info.
  • Step 407 NFVO sends address information and the node type of the VNF to the OSS/BSS.
  • the address information refers to the address information of the definition file of the node type of the VNF, which can be determined by the NFVO according to the storage path of the definition file of the node type in the VNF package, and the computing/storage device that the VNF package can access in the NFVO or NFVO On the storage location to determine.
  • the foregoing steps 401 to 407 may be performed for each VNF included in the NS to be deployed.
  • the OSS/BSS can generate the NSD of the NS that it needs to deploy based on the node type of each VNF it receives and the address information of the definition file of the node type of each VNF.
  • the address information of the definition file of each VNF node type can be stored in the NSD as the value of a designated keyword (for example, imports) when the NSD is generated.
  • Step 408 OSS/BSS sends an NSD info creation request to NFVO.
  • Step 409 NFVO sends the NSD info identifier to OSS/BSS.
  • NSD info is created by NFVO when it receives an NSD info creation request from OSS/BSS.
  • the NSD info identifier is allocated by NFVO, and the NSD info identifier should be able to be used for the NSD info in NFVO. Make unique identification.
  • Step 410 The OSS/BSS sends the NSD generated by the OSS/BSS and the identification of the NSDinfo to the NFVO.
  • the OSS/BSS may send the address information of the NSD generated by the OSS/BSS and the identification of the NSDinfo to the NFVO, so that the NFVO can obtain the NSD generated by the OSS/BSS according to the address information of the NSD.
  • Step 411 NFVO verifies the NSD.
  • the NSD can contain the node information of each VNF contained in the NS that needs to be deployed, and the node information of each VNF correspondingly contains its node type and dynamic information; the NSD also contains the definition file of the node type of each VNF. Address information in NFVO.
  • NFVO can obtain the definition file of the node type from the corresponding VNF package according to the address information of the definition file of the node type contained in the node information, thereby using the definition file Analyze and verify the dynamic information contained in the node information.
  • the NFVO can also import the dynamic information in the node information into the VNFD contained in the VNF package according to the node type in each node information contained in the NSD.
  • NFVO can also obtain the identifier of the VNF package info associated with the node type according to each node type contained in the NSD, and store the identifier of the VNF package info Go to NSD info.
  • NFVO can return the verification result to OSS/BSS.
  • step 412 the OSS/BSS sends an NS instance identifier creation request to the NFVO.
  • NS instance ID creation request is used to request NFVO to create an NS instance ID related to the NSD info.
  • Step 413 NFVO sends the NS instance identifier to OSS/BSS.
  • Step 414 The OSS/BSS sends an instantiating NS request carrying the NS instance identifier to the NFVO.
  • Step 415 For each node type included in the NSD, the NFVO obtains the VNF package info associated with the node type, and obtains the VNFD identifier from the VNF package info.
  • OSS/BSS when OSS/BSS sends NSD or NSD address information to NFVO, it also sends the identification of NSD info, that is to say, the identification of NSD info is associated with NSD. Therefore, if the NFVO contains multiple NSDs, the NFVO can determine the NSD of the NS to be deployed by the OSS/BSS according to the NS instance identifier, and execute step 415 and other processing procedures for the determined NSD.
  • NFVO in the case that NFVO has stored the identification of the VNF package info associated with each node type contained in the NSD in the NSD info, NFVO can target each VNF package info contained in the NSD info.
  • the identifier, the identifier of the VNFD is obtained from the VNF package info indicated by the identifier of the VNF package info.
  • the NFVO requests the VNFM to instantiate the VNF according to the VNFD identifier.
  • NFVO may first send a VNF instance identifier creation request carrying the identifier of the VNFD to the VNFM for each NVFD identifier obtained in step 415, so that the VNFM assigns the VNF instance identifier to the identifier of the VNFD; NFVO may After receiving the VNF instance identifier assigned by the VNFM for the VNFD identifier, it further sends an instantiated VNF request carrying the VNF instance identifier to the VNFM, so that the VNFM can obtain the corresponding VNFD or the VNF package containing the VNFD, and use the VNFD or The VNF package that contains the VNFD instantiates the VNF, that is, the VNFD or the VNF package that contains the VNFD performs corresponding information interaction with the VIM to complete the creation of the VNF.
  • an embodiment of the present application also provides an NFVO102, and the NFVO102 includes:
  • the transceiver unit 1021 is configured to receive an instantiated network service NS request
  • the processing unit 1023 is configured to determine an NSD according to the instantiation NS request, and the NSD contains the node type of the VNF; obtain the VNFPI associated with the node type, and obtain the VNFD identifier from the VNFPI; The identification of the VNFD requests the VNFM to instantiate the VNF.
  • the processing unit 1023 is further configured to obtain the node type from VNFP, associate the node type with the VNFPI; obtain the VNFD identifier from the VNFP , Storing the identifier of the VNFD in the VNFPI.
  • the VNFP includes a meta file, the meta file includes a declaration keyword, and the value of the declaration keyword is the node type;
  • the processing unit 1023 is specifically configured to query the declaration keyword in the metafile included in the VNFP, and obtain the node type from the declaration keyword.
  • the VNFP includes a meta file
  • the meta file includes a declaration keyword
  • the value of the declaration keyword is the storage of the definition file of the node type in the VNFP path
  • the processing unit 1023 is specifically configured to query the declaration keyword in the metafile contained in the VNFP, and obtain the storage of the definition file of the node type in the VNFP from the declaration keyword Path; obtaining the node type from the definition file of the node type according to the storage path.
  • the processing unit 1023 is further configured to determine the address information of the definition file of the node type according to the storage path and the storage location of the VNFP;
  • the transceiver unit 1021 is further configured to send the node type and the address information to the service requester, so that the service requester generates the NSD, and the NSD includes the node type and the address information.
  • the processing unit 1023 is specifically configured to determine the identifier of the VNFPI, to associate the node type with the identifier of the VNFPI; and specifically to obtain information related to the node type And obtain the VNFPI identifier according to the identifier of the VNFPI.
  • the VNFP includes a manifest file, and the manifest file includes an identifier of the VNFD;
  • the processing unit 1023 is specifically configured to obtain the identifier of the VNFD from the manifest file included in the VNFP.
  • An embodiment of the present application also provides a computer-readable storage medium for storing instructions.
  • the instructions When the instructions are executed by a processor of a computing device, the computing device realizes the example provided in any one of the embodiments of the present application.
  • the method of NS The method of NS.
  • An embodiment of the application provides a computer program product.
  • the computer program product includes computer program code.
  • the computer program code runs on a computing device, the computing device executes any one of the embodiments provided in this application.
  • the method of instantiating NS is not limited to any one of the embodiments provided in this application.
  • An embodiment of the present application provides a computing device, including a memory and a processor, the memory stores executable code, and when the processor executes the executable code, it implements the method provided in any one of the embodiments of the present application. Method to instantiate NS.
  • the embodiment of the present application also provides a chip system, which includes a processor, which is used to implement the function of the NFVO described in any embodiment of the present application, for example, to receive or process the function of any one of the embodiments of the present application.
  • the data and/or information involved in the method of instantiating NS In a possible design, the chip system further includes a memory, and the memory is used to store program instructions and/or data.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • the size of the sequence number of the above-mentioned processes does not mean the order of execution.
  • the execution order of the processes should be determined by their functions and internal logic, and should not be dealt with.
  • the implementation process of the embodiments of the present application constitutes any limitation.
  • the device embodiments described above are illustrative, for example, the division of the modules/units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be Combined or can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

Abstract

一种实例化NS的方法及NFVO。所述实例化NS的方法应用于NFVO，该方法包括：接收实例化NS请求（21）；根据实例化NS请求确定NSD，该NSD中包含VNF的节点类型（23）；获取与该节点类型相关联的VNF package info，从该VNF package info中获取VNFD的标识（25）；根据该VNFD的标识请求VNFM实例化VNF（27）。所述方法无需花费较多的时间对VNF package进行手动解析，即可快速确定用于实例化包含于NSD的节点类型对应的VNF的VNFD的标识，更为快速的完成对NS所包含的VNF的实例化，有利于提高实例化NS的效率。

Description

实例化NS的方法及NFVO
本申请要求于2019年11月05日提交中国专利局、申请号为201911072099.5、申请名称为“实例化NS的方法及NFVO”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机领域，尤其涉及实例化网络服务(NS，network service)的方法及网络功能虚拟化编排器(NFVO，network function virtualization orchestrator)。
背景技术
网络功能虚拟化(NFV，network function virtualization)，是指使用通用的硬件设备及虚拟化技术，来承载传统网络中专用设备的功能，使得网络功能和NS不再依赖于专用设备，从而降低部署专用设备所带来的高昂成本。同时，还可以灵活的共享云平台中的各项资源，以便结合实际业务需求快速开发和部署各种新的NS。
NFV引入了虚拟化层，通过网络管理和编排，实现虚拟化网络功能(VNF，virtualized network function)和NS的生命周期管理。NS中通常包含一个或多个VNF；也就是说，NS为通过一个或多个VNF来实现的上层的网络服务。如果业务请求方需要实例化一个NS，即业务请求方需要部署一个NS，业务请求方则可向业务提供方提供该NS的网络服务描述信息(NSD，network Service descriptor)。NSD也可被称为NS部署模板，可以通过各个VNF的节点类型，来描述各个VNF的虚拟化网络功能描述信息(VNFD，virtualized network function descriptor)；其中，VNFD也可称为VNF部署模板，主要用于描述VNF，比如用于描述VNF需要运行的软件和虚拟资源，具体如中央处理器(CPU，central processing unit)资源、存储资源。相应的，业务提供方可以对NSD进行解析，得到NSD中包含的一个或多个VNF的节点类型；对于得到的每个节点类型，可以确定出用于实例化相应的VNF的VNFD，从而基于确定的VNFD实例化相应的VNF，完成NS的实例化。
然而，用于支持实例化VNF的VNFD通常位于虚拟化网络功能包(VNFP，VNF package)中，该VNF package中还包含VNF的节点类型的定义文件，节点类型的定义文件在VNF package中可能并没有固定的存储路径或文件名称。如此，基于NS的NSD实例化NS的过程中，针对NSD包含的各个VNF的节点类型，则需要通过人工处理的方式，花费较多的时间对VNF package进行手动解析，才能确定出用于支持实例化该节点类型对应的VNF的VNFD的标识，实例化NS的效率较低。
发明内容
本申请实施例中提供了一种实例化NS的方法及NFVO，有利于提高实例化NS的效率。
本申请实施例中至少提供了如下技术方案：
第一方面，提供了一种实例化NS的方法，所述方法应用于NFVO，所述方法包 括：
接收实例化NS请求；
根据所述实例化NS请求确定NSD，所述NSD中包含VNF的节点类型；
获取与所述节点类型相关联的虚拟化网络功能包信息(VNFPI，VNF package info)，从所述VNFPI中获取VNFD的标识；
根据所述VNFD的标识请求虚拟化网络功能管理器(VNFM，virtualized network function manager)实例化VNF。
在一种可能的实施方式中，
在所述接收实例化NS请求之前，所述方法还包括：
从VNFP中获取所述节点类型，将所述节点类型和所述VNFPI进行关联；
从所述VNFP中获取所述VNFD的标识，将所述VNFD的标识存储到所述VNFPI中。
在一种可能的实施方式中，
所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型；
所述从VNFP中获取所述节点类型，包括：在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型。
在一种可能的实施方式中，
所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型的定义文件在所述VNFP中的存储路径；
所述从VNFP中获取所述节点类型，包括：
在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型的定义文件在所述VNFP中的存储路径；
根据所述存储路径从所述节点类型的定义文件中获取所述节点类型。
在一种可能的实施方式中，
在所述接收实例化NS请求之前，所述方法还包括：
根据所述存储路径和所述VNFP的存储位置，确定所述节点类型的定义文件的地址信息；
向业务请求方发送所述节点类型和所述地址信息，以便所述业务请求方生成所述NSD，所述NSD中包含所述节点类型和所述地址信息。
在一种可能的实施方式中，
所述将所述节点类型和所述VNFPI进行关联，包括：确定所述VNFPI的标识，将所述节点类型和所述VNFPI的标识进行关联；
所述获取与所述节点类型相关联的VNFPI，包括：获取与所述节点类型相关联的所述VNFPI的标识，并根据所述VNFPI的标识获取所述VNFPI。
在一种可能的实施方式中，
所述VNFP中包含清单文件，所述清单文件中包含所述VNFD的标识；
所述从所述VNFP中获取所述VNFD的标识，包括：从所述VNFP包含的所述清单文件中获取所述VNFD的标识。
第二方面，提供了一种NFVO，所述NFVO包括：
收发单元，用于接收实例化网络服务NS请求；
处理单元，用于根据所述实例化NS请求确定NSD，所述NSD中包含VNF的节点类型；获取与所述节点类型相关联的VNFPI，从所述VNFPI中获取VNFD的标识；根据所述VNFD的标识请求VNFM实例化VNF。
在一种可能的实施方式中，
所述处理单元，还用于从VNFP中获取所述节点类型，将所述节点类型和所述VNFPI进行关联；从所述VNFP中获取所述VNFD的标识，将所述VNFD的标识存储到所述VNFPI中。
在一种可能的实施方式中，
所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型；
所述处理单元，具体用于在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型。
在一种可能的实施方式中，
所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型的定义文件在所述VNFP中的存储路径；
所述处理单元，具体用于在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型的定义文件在所述VNFP中的存储路径；根据所述存储路径从所述节点类型的定义文件中获取所述节点类型。
在一种可能的实施方式中，
所述处理单元，还用于根据所述存储路径和所述VNFP的存储位置，确定所述节点类型的定义文件的地址信息；
所述收发单元，还用于向业务请求方发送所述节点类型和所述地址信息，以便所述业务请求方生成所述NSD，所述NSD中包含所述节点类型和所述地址信息。
在一种可能的实施方式中，
所述处理单元，具体用于确定所述VNFPI的标识，将所述节点类型和所述VNFPI的标识进行关联；以及具体用于获取与所述节点类型相关联的所述VNFPI的标识，并根据所述VNFPI的标识获取所述VNFPI。
在一种可能的实施方式中，
所述VNFP中包含清单文件，所述清单文件中包含所述VNFD的标识；
所述处理单元，具体用于从所述VNFP包含的所述清单文件中获取所述VNFD的标识。
第三方面，提供了一种计算机可读存储介质，用于存储指令，当所述指令被计算设备的处理器执行时，使得所述计算设备实现上述第一方面中任一项所述的方法。
第四方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机程序代码，当所述计算机程序代码在计算设备上运行时，使得所述计算设备执行上述第一方面中任一项所述的方法。
第五方面，提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可 执行代码，所述处理器执行所述可执行代码时，实现上述第一方面中任一项所述的方法。
第六方面，提供了一种芯片系统，该芯片系统包括处理器，用于实现上述各个方面中所述的NFVO的功能，例如，接收或处理上述第一方面的方法中所涉及的数据和/或信息。在一种可能的实施方式中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和/或数据。该芯片系统可以由芯片构成，也可以包括芯片和其他分立器件。
根据本申请实施例中提供的技术方案，NFVO可以将VNF package info和NSD中包含的VNF的节点类型进行关联，并在VNF package info中存储VNFD的标识。当NFVO接收到实例化NS请求时，即可首先确定需要实例化的NS的NSD，针对NSD中包含的VNF的节点类型，获取与该节点类型相关联的VNF package info，然后从VNF package info中获取VNFD的标识。之后，NFVO即可根据VNFD的标识请求VNFM实例化VNF。如此，在基于NS的NSD实例化NS的过程中，无需花费较多的时间对VNF package进行手动解析，即可快速确定用于支持实例化VNF的VNFD的标识，更为快速的完成对NS所包含的VNF的实例化，有利于提高实例化NS的效率。
附图说明
下面对实施例或现有技术描述中所需使用的附图作简单地介绍。
图1为本申请实施例适用的一种网络功能虚拟化系统的系统框架图。
图2为本申请实施例中提供的一种实例化NS的方法的流程示意图。
图3为本申请实施例中示例性的VNF package的文件结构图。
图4为本申请实施例中提供的另一种实例化NS的方法的流程示意图。
图5为本申请实施例中提供的一种NFVO的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
图1为本申请实施例适用的一种网络功能虚拟化系统的系统框架图。如图1所示，NFV系统100主要包括如下功能实体：
NFVO102，主要用于负责NS的生命周期管理，以及负责网络功能虚拟基础设施(NFVI，network functions virtualization infrastructure)104中虚拟资源的分配和调度。NFVO102可以与一个或多个VNFM106通信，执行实例化NS的相关操作，比如向VNFM106发送相应的配置信息、从VNFM106请求一个或多个VNF108的状态信息。另外，NFVO102还可以与虚拟基础设施管理器(VIM，virtualized infrastructure manager)110通信，执行对NFVI104中的各项资源进行分配和/或预留，交换资源配置和状态信息等。
VNFM106，主要负责一个或多个VNF108的生命周期管理，比如实例化(instantiating)VNF108、更新(updating)VNF108、查询VNF108、弹性伸缩(scaling)VNF108，终止(terminating)VNF108等。VNFM106可以与VNF108通信，从而管理VNF108的生命周期、与VNF交换配置信息和状态信息等。可以理解，NFV系统100中可以包含一个或多个VNFM106，各个VNFM106分别对不同类型的VNF108进行生 命周期管理。
NFVI104，指的是NFV系统100的基础设施，包含硬件部件、软件部件及其结合，以便建立虚拟化环境，在虚拟化环境中部署、管理及实现VNF108。NFVI104至少可以包含计算(computing)硬件1041、存储硬件1042、网络硬件1043；NFVI104的虚拟化层1044可以对前述各个硬件进行抽象，解耦各个硬件与VNF108，得到相应的虚拟计算(virtual computing)资源1045、虚拟存储资源1046、虚拟网络资源1047，从而为VNF108提供虚拟机以及其它形式的虚拟化容器。
VIM110，主要用于控制和管理VNF108与计算硬件1041、存储硬件1042、网络硬件1043、虚拟计算资源1045、虚拟存储资源1046、虚拟网络资源1047的交互。比如，VIM110可以执行资源管理功能，具体如向虚拟机或其它形式的虚拟容器增加相应的虚拟资源、搜集NFVI104在系统运行过程中的故障信息等。另外，VIM110可以和VNFM106进行通信，比如接收来自VNFM106的资源分配请求、向VNFM106反馈资源配置和状态信息等。
VNF108，可以运行于一个或多个虚拟机或其它形式的虚拟容器中，对应于一组原本由专用设备实现的网络功能。
设备管理系统(EMS，equipment management system)112，可以用于对VNF108进行配置和管理，以及向VNFM106发起新的VNF108的实例化等生命周期管理操作。可以理解，NFV系统100中可以包括一个或多个EMS112。
运营支持系统(OSS，operations support system)或者业务支持系统(BSS，business support system)114，可以支持各种端到端的电信业务。其中，OSS支持的管理功能可以包括网络配置、业务提供、故障管理等；BSS可以用于处理订单、付费、收入等相关业务，支持产品管理、订单管理、收益管理及客户管理等功能。需要说明的是，OSS/BSS114可以作为业务请求方请求NFVO实例化NS，OSS/BSS114或OSS/BSS114所依赖的计算设备通常可以对应称为业务请求方。
可以理解，如图1所示的NFV系统100中，前述各个功能实体可以各自部署在不同的计算设备中，也可能将部分功能实体集成到同一个计算设备中。
用于支持实例化NS所包含的VNF的VNFD通常位于VNF package中，该VNF package中包含VNF的节点类型的定义文件，节点类型的定义文件在VNF package中可能并没有固定的存储路径或文件名称。因此，NFVO102基于NS的NSD实例化NS的过程中，针对NSD中包含的每个VNF的节点类型，需要通过人工处理的方式，花费较多的时间对VNF package进行手动解析，才能确定出用于实例化该节点类型对应的VNF的VNFD的标识，实例化NS的效率较低。
有鉴于此，本申请实施例中至少提供了一种实例化NS的方法及NFVO，NFVO可以作为业务提供方，将VNF package info和NSD中包含的VNF的节点类型进行关联，并在VNF package info中存储VNFD的标识。当NFVO接收到来自业务请求方(比如如图1所示的OSS/BSS或部署OSS/BSS的计算设备)的实例化NS请求时，即可根据需要实例化的NS的NSD中包含的VNF的节点类型，获取与该节点类型相关联的VNF package info，然后从VNF package info中获取VNFD的标识。之后，NFVO即可根据VNFD的标识请求VNFM实例化VNF。
如此，在基于NS的NSD实例化NS的过程中，无需花费较多的时间对VNF package进行手动解析，即可快速确定用于支持实例化VNF的VNFD的标识，更为快速的完成对NS所包含的VNF的实例化，有利于提高实例化NS的效率。
可以理解，VNFM106是负责实例化VNF108的功能实体。VNFM106可以接收来自NFVO102的、携带VNFD的标识的VNF实例标识创建请求，并针对该VNFD的标识对应的创建/分配VNF实例标识。VNFM创建/分配的VNF实例标识被返回给NFVO之后，NFVO则可以进一步向VNFM发送携带该VNF实例标识的实例化VNF请求。VNFM在接收到来自NFVO的、携带VNF实例标识的实例化VNF请求之后，即可根据相应的VNFD的标识，获取相应的VNFD或包含该VNFD的VNF package；然后根据其获取的VNFD或包含该VNFD的VNF package向VIM110申请虚拟资源，并在申请到虚拟资源后，配置VNF108实例，完成VNF108的实例化。，进而完成NS的实例化。
接下来，针对实例化NS的各个步骤进行详细描述。
如图2所示，本申请实施例中提供了一种实例化NS的方法，所述方法应用于NFVO，至少可以包括如下步骤21～27。
首先，在步骤21，接收实例化NS请求。
这里，实例化NS请求来自业务请求方，业务请求方包括但不限于如图1所示的OSS或BSS，该实例化NS请求用于请求NFVO实例化相应的NS。
接着，在步骤23，根据所述实例化NS请求确定NSD，所述NSD中包含VNF的节点类型。
这里，确定的NSD为发送该实例化NS请求的业务请求方需要部署的NS的NSD。
可以理解，NFV可能采用多种规范中的任意一种来定义NS的NSD，以及定义用于支持实例化NS所包含的各个VNF的VNFD。无论是通过何种规范来定义的NSD，NSD中均应当包含业务请求方需要部署的NS所包含的各个VNF的节点类型。
在一些实施例中，NSD中还可以进一步包含实例化一个VNF时需要的一项或多项动态信息，具体如实例化级别(instantiation level)、最小实例化数量(min number of instances)、最大实例化数量(max number of instances)，这些动态信息和该VNF的节点类型可以在NSD中组成该VNF的节点信息(或者称为该VNF的节点定义)。
接着，在步骤25，获取与所述节点类型相关联的VNF package info，从所述VNF package info中获取VNFD的标识。
这里，对于业务请求方需要部署的NS所包含的各个VNF，各个VNF的节点类型包含于该NS的NSD中。对于NSD中包含的每个节点类型，在NFVO已经将该节点类型和相应的VNF package info进行关联的前提下，NFVO则可从与该节点类型相关联的VNF package info中，快速获取用于支持实例化该节点类型对应的VNF的VNFD的标识。
之后，在步骤27，根据所述VNFD的标识请求VNFM实例化VNF。
如前所述，VNFM在接收到携带VNFD的标识之后，可进行相应的处理以完成VNF的实例化，进而完成NS的实例化。
如图2所示的实施例，NFVO基于NS的NSD实例化NS的过程中，无需花费较 多的时间对VNF package进行手动解析，即可快速确定用于支持实例化VNF的VNFD的标识，更为快速的完成对NS所包含的VNF的实例化，有利于提高实例化NS的效率。
可以理解，对于业务请求方需要部署的NS所包含的各个VNF，各个VNF可以分别对应一个VNF package。对于需要部署的NS所包含的单个VNF而言，用于支持实例化该VNF的VNFD包含于该VNF对应的VNF package中，并且该VNF package中还应当包含该VNF的节点类型和该VNFD的标识。
相应的，在一种可能的实施方式中，NFVO可以在接收到来自业务请求方的实例化NS请求之前，针对业务请求方需要部署的NS所包含的每个VNF：在NFVO中创建VNF package info，从该VNF对应的VNF package中获取该VNF的节点类型，并将节点类型和该VNF package info进行关联；然后从该VNF对应的VNF package中获取该VNF package包含的VNFD的标识，并将该VNFD的标识存储于该VNF package info中。
在一个更为具体的示例中，NFVO可以为其创建的VNF package info，分配该VNF package info的标识，将该VNF package info的标识与相应的VNF的节点类型进行关联，从而将相应的VNF的节点类型和VNF package info进行关联。
如前所述，NFV可能采用多种规范中的任意一种来定义NS的NSD，以及定义用于支持实例化该NS所包含的各个VNF的VNFD。为了方便描述，本申请各个实施例中主要以NFV采用云应用的拓扑和编排规范(TOSCA，topology and orchestration specification for cloud applications)来定义NSD和VNFD为例，对本申请实施例的技术方案进行示例性描述。
采用TOSCA来定义VNFD时，VNFD通常位于一个zip格式的VNF package中，该VNF package也同样遵守TOSCA定义的打包格式。示例性的，采用TOSCA来定义VNFD时，包含VNFD的VNF package可以具有如图3所示的文件结构。
如图3所示，VNF package中可以包含一个顶级文件“TOSCA-Metadata”，“TOSCA-Metadata”中包含元文件“TOSCA-Meta”，“TOSCA-Meta”中描述了VNF package的基本信息。示例性的，元文件“TOSCA-Meta”中至少可以描述VNF package的如下信息：
TOSCA-Meta-File-Version:1.1#“TOSCA-Meta”遵循的文件格式的版本号，比如在TOSCA-simple-profile-yaml-v1.2标准中，版本号则为1.1
CSAR-Version:1.1#VNF package遵循的打包格式的版本号，比如在TOSCA-simple-profile-yaml-v1.2标准中，版本号则为1.1
Created-By:OASIS TOSCA TC#VNF package的设计者，比如设计者可以为OASIS TOSCA TC
Entry-Definitions:definitions/Example_VNF1.yaml#该VNF package的入口文件在该VNF package中的地址，比如文件“Example_VNF1.yaml”为VNF package中除了顶级文件以外需要被首先处理的TOSCA文件，该文件可以放在VNF package下的“definitions”文件夹中；需要说明的是，入口文件应当是一个符合TOSCA语法的“yaml”格式文件.
在如图3所示VNF package的文件结构中，“example_VNF1_Type.yaml”可以为该VNF package对应的VNF的节点类型的定义文件。
可以理解，对于VNF package对应的VNF的节点类型而言，该节点类型的定义文件在不同的VNF package中可能具有不同的名称、位于VNF package中的不同位置。
可以理解，VNF的节点类型的定义文件中可以包含VNF的节点类型，还可以包含该节点类型的属性(properties)、描述符标识(descriptor_id)及描述符标识的类型、喜好标识(flavour_id)及喜好标识的类型等。
相应的，为了方便NFVO从VNF package中快速获取该VNF package对应的VNF的节点类型，在一个较为具体的示例中，VNF package的元文件中包含声明关键字，声明关键字的取值为该VNF package对应的VNF的节点类型。
比如，声明关键字为“Declaration”，“example_VNF1_Type.yaml”中包含的节点类型为“tosca.nodes.nfv.example_VNF1”，可将“example_VNF1_Type.yaml”作为“Declaration”的取值存放于元文件“TOSCA-Meta”中。示例性的，VNF package包含的元文件“TOSCA-Meta”中可以包含VNF package的如下信息：
TOSCA-Meta-File-Version:1.1
CSAR-Version:1.1
Created-By:OASIS TOSCA TC
Entry-Definitions:definitions/Example_VNF1.yaml
Declaration:tosca.nodes.nfv.example_VNF1#本申请实施例在VNFpackage的“TOSCA-Meta”中新增的信息.
相应的，NFVO则可以从VNF package包含的元文件中查询声明关键字，从声明关键字获取VNF package对应的VNF的节点类型。比如，在VNF package包含的“TOSCA-Meta”中查询“Declaration”，获取“Declaration”的取值“tosca.nodes.nfv.example_VNF1”。
为了方便NFVO从VNF package中快速获取该VNF package对应的VNF的节点类型，在另一个较为具体的示例中，VNF package的元文件中包含声明关键字，该声明关键字的取值为，该VNF package对应的VNF的节点类型的定义文件在该VNF package中的存储路径。
比如，声明关键字为“Declaration”，“example_VNF1_Type.yaml”中包含的节点类型为“tosca.nodes.nfv.example_VNF1”，“example_VNF1_Type.yaml”在VNF package中的存储路径为“definitions/example_VNF1_Type.yaml”，则可将“definitions/example_VNF1_Type.yaml”作为“Declaration”的取值存放于元文件“TOSCA-Meta”中。示例性的，VNF package包含的元文件“TOSCA-Meta”中可以包含VNF package包的如下信息：
TOSCA-Meta-File-Version:1.1
CSAR-Version:1.1
Created-By:OASIS TOSCA TC
Entry-Definitions:definitions/Example_VNF1.yaml
Declaration:definitions/example_VNF1_Type.yaml##本申请实施例在VNF  package的“TOSCA-Meta”中新增的信息.
相应的，NFVO则可以从VNF package包含的元文件中查询声明关键字，从声明关键字中获取该VNF package对应的VNF的节点类型的定义文件在该VNF package中的存储路径，然后根据获取的存储路径从节点类型的定义文件中获取该VNF package对应的VNF的节点类型。比如，在VNF package包含的“TOSCA-Meta”中查询“Declaration”，并获取“Declaration”的取值“definitions/example_VNF1_Type.yaml”，然后根据“definitions/example_VNF1_Type.yaml”查询节点类型的定义文件“example_VNF1_Type.yaml”，从“example_VNF1_Type.yaml”中获取节点类型“tosca.nodes.nfv.example_VNF1”。
可以理解的，VNF package包含的VNFD通常由多个服务模块(或者称为服务文件)构成，多个服务模块具体可以被划分为一个顶级服务模块(top level service template)和至少一个低级服务模块(low level service template)；其中，顶级服务模块通常会在VNF package包含的元文件中被定义为入口文件。如图3所示，VNF package包含的VNFD可以包含顶级服务模块Example_VNF1.yaml和低级服务模块VNF_DF1.yaml、VNF_DF2.yaml，Example_VNF1.yaml在VNF package中的位置可存放于VNF package的元文件TOSCA-Meta中。
VNF package中包含的顶级服务模块主要用于描述该VNF package对应的VNF的静态信息。比如，描述VNF的节点类型、属性(properties)、要求(requirement)等信息。
VNF package中包含的每个低级服务模块分别表示一种VNF的部署喜好(VNF deployment flavour)。在实例化VNF的时候，可以根据实例化VNF请求或者需要实例化的NS的NSD中携带的喜好标识，决定选择包含该喜好标识的低级服务模块部署VNF。可以理解，基于不同的部署喜好对应部署VNF时，对虚拟资源的需求可能各不相同；也就是说，不同的低级服务模块的构成可能各不相同。
示例性的，VNF_DF2.yaml描述的部署喜好可以是针对大用户量接入的场景，此时需要VDU_1和VDU_2两种虚拟部署单元(VDU，virtualization deployment unit)资源共同提供服务；VNF_DF1.yaml描述的是小用户量接入的场景，此时只需要部署一个VDU_1提供服务即可。
在同一个VNF package中，其包含的每个低级服务模块都可以和顶级服务模块相关联。具体地，低级服务模块可以通过替换映射(substitution mapping)中定义的节点类型(node type)、属性(properties)中定义的喜好标识(flavour_id)同顶级服务模块关联。
示例性的，通过如下方法来描述VNF package中包含的顶级服务模块Example_VNF1.yaml：
Figure PCTCN2020107121-appb-000001
Figure PCTCN2020107121-appb-000002
其中，节点类型“tosca.nodes.nfv.example_VNF1”可以唯一标识该顶级服务模块所属的VNFD；描述符标识(descriptor_id)的取值“12345-xyz”为该顶级服务模块所属的VNFD的标识。
示例性的，实例化VNF请求中指示的喜好标识是flavour1，在Example_VNF1.yaml中的flavour_id通过get_input(flavour)获取该实例化VNF请求中flavour的取值，比如为flavour1。此时，如果VNF_DF1.yaml中包含的喜好标识flavour1，VNF_DF1.yaml中包含的喜好标识为flavour2，且VNF_DF1.yaml和VNF_DF2.yaml中均包含所属VNFpackage对应的VNF的节点类型tosca.nodes.nfv.example_VNF1。Example_VNF1.yaml即可通过tosca.nodes.nfv.example_VNF1和flavour1关联到两个低级服务模块中的VNF_DF1.yaml,以便VNFM通过VNF_DF1.yaml部署VNF，具体包括部署VNF_DF1.yaml中包含的VDU、虚拟连接(VL，virtual link)和连接点(CP，connection point)。
相应的，由于VNF package中包含的VNFD的顶级服务模块包含了该VNFD的标识，在一种可能的实施方式中，NFVO可以从VNF package包含的VNFD的顶级服务模块中获取VNFD的标识。
为了更为快速的获取VNF package包含的VNFD的标识，在另一种可能的实施方式中，VNF package中还可以包含清单文件，VNFD的标识包含于清单文件中。
清单文件在DOSCA中为可选项文件，在VNF package中包含清单文件的情况下，清单文件通常用于存储VNF package的认证及安全相关的信息、VNF package的自身的基本信息，比如存放VNF package的名称、发布日期、版本号等，清单文件中存储的信息量相对较小。
该实施方式中，将VNFD的标识存放于VNF package包含的清单文件中，NFVO无需花费较多的时间对VNF package包含的VNFD进行全面解析，即可从包含少量信息的清单文件中快速获取VNF package包含的VNFD的标识。
示例性的，可以在清单文件中增加用于描述VNFD的标识的字段/主键(比如为 vnfd_id),将VNFD的标识作为该字段/主键的取值存储于清单文件中。
在图3中，“manifest.mf”可以为VNF package中包含的清单文件。
需要说明的是，VNF package的标识和VNFD的标识可以相同。
可以理解，在VNF package中，还可能包含除上述示例性说明的各个文件以外的其它文件，比如部署一个VNF所需的镜像(Mirroring)文件、脚本文件等。仍然参考图3，VNF package中还可以包括文件“files”，“files”下还可以包含用于存放日志信息的文件“ChangeLog.txt”、用于存放实例化VNF所需的图片的文件“image(s)”、用于存放测试数据的文件“tests”等。
如前所述，NS的NSD中通常可以包含该NS所包含的各个VNF的节点信息，各个VNF的节点类型对应的包含于节点信息中，节点类型的定义文件包含于VNF package中。为了确保NFVO能够有效的触发NVFM实例化VNF，NFVO可以在获取到业务请求方需要部署的NS的NSD之后，基于该NS所包含的各个VNF的节点类型的定义文件，对NSD进行解析及校验。
相应的，为了使NFVO能够更为快速的完成对NSD的解析及校验，在一种可能的实施方式中，NFVO可以在接收到来自业务请求方的实例化NS请求之前，根据VNF package的存储位置、该VNF package包含的VNF的节点类型的定义文件在VNF package中的存储路径，确定该节点类型的定义文件的地址信息；然后，向业务请求方发送该节点类型和地址信息，以便业务请求方生成包含该节点类型和该地址信息的NSD。
示例性的，VNF的节点类型为tosca.nodes.nfv.example_VNF1，该节点类型的定义文件example_VNF1_Type.yaml在VNF package中的存储路径为definitions/Example_VNF1.yaml，该VNF package在NFVO或者NFVO可以访问的计算/存储设备上的存储位置为NFVO/VNF package_1。此时，即可确定该节点类型的定义文件Example_VNF1.yaml的地址信息为：NFVO/VNF package_1/definitions/Example_VNF1.yaml。
相应的，在一种可能的实施方式中，NFVO可以在接收到来自业务请求方的实例化NS请求之前，获取业务请求方生成的NSD，然后根据NSD中包含的地址信息，从NFVO或NFVO可以访问的计算/存储设备上存储的VNF package中，获取节点类型的定义文件，并根据节点类型的定义文件对NSD进行校验。
下面结合前述各个实施例，对NFVO与OSS/BSS、VNFM进行信息交互，完成实例化NS的过程进行示例性描述。如图4所示，实例化NS的过程具体可以包括如下步骤401-416。
步骤401，OSS/BSS向NFVO发送VNF package info创建请求。
可以理解，OSS/BSS可以针对其需要部署的NS所包含的每个VNF，分别向NFVO发送VNF package info创建请求。
步骤402，NFVO向OSS/BSS发送VNF package info的标识。
其中，VNF package info由NFVO在接收到来自OSS/BSS的VNF package info创建请求的情况下对应的创建，该VNF package info的标识由NFVO进行分配，且该VNF package info的标识能够用于在NFVO中对VNF package info进行唯一标识。
步骤403，OSS/BSS向NFVO发送VNF package和该VNF package info的标识。
或者，OSS/BSS也可以向NFVO发送该VNF package的地址信息和该VNF package info的标识，以便NFVO根据VNF package的地址信息获取该VNF package。
步骤404，NFVO在VNF package的元文件中查询声明关键字，从该声明关键字获取存储路径，并根据该存储路径从VNF package包含的节点类型的定义文件中获取VNF的节点类型。
这里，该声明关键字的取值为，该VNF package对应的VNF的节点类型的定义文件在该VNF package中的存储路径。
或者，该声明关键字的取值也可以为VNF package对应的VNF的节点类型。
步骤405，NFVO从VNF package包含的清单文件中获取VNF package包含的VNFD的标识。
步骤406，NFVO将VNF的节点类型和VNF package info进行关联，并将该VNFD的标识存储至VNF package info中。
这里，NFVO可以将该VNF package对应的VNF的节点类型和VNF package info的标识进行关联，从而实现将VNF的节点类型和该VNF package info进行关联。
步骤407，NFVO向OSS/BSS发送地址信息和VNF的节点类型。
这里，地址信息是指VNF的节点类型的定义文件的地址信息，可以由NFVO根据该节点类型的定义文件在该VNF package中的存储路径、该VNF package在NFVO或NFVO可以访问的计算/存储设备上的存储位置进行确定。
这里，在OSS/BSS需要部署的NS中包含多个VNF的情况下，可以针对需要部署的NS中包含的每个VNF分别执行上述步骤401～407。
相应的，OSS/BSS可以基于其接收的各个VNF的节点类型、各个VNF的节点类型的定义文件的地址信息，生成其需要部署的NS的NSD。
对于各个VNF的节点类型的定义文件的地址信息，可以在生成NSD时，作为指定关键字(比如，imports)的取值存放于NSD中。
步骤408，OSS/BSS向NFVO发送NSD info创建请求。
步骤409，NFVO向OSS/BSS发送NSD info的标识。
其中，NSD info由NFVO在接收到来自OSS/BSS的NSD info创建请求的情况下创建，该NSD info的标识由NFVO进行分配，且该NSD info的标识应当能够用于在NFVO中对该NSD info进行唯一标识。
步骤410，OSS/BSS向NFVO发送其生成的NSD和该NSD info的标识。
或者，OSS/BSS可以向NFVO发送其生成的NSD的地址信息和该NSD info的标识，以便NFVO根据NSD的地址信息获取OSS/BSS生成的NSD。
步骤411，NFVO对NSD进行校验。
如前所述，NSD中可以包含需要部署的NS所包含的各个VNF的节点信息，各个VNF的节点信息对应的包含其节点类型和动态信息；NSD中还包含各个VNF的节点类型的定义文件在NFVO中的地址信息。
相应的，NFVO可以针对NSD中包含的每个节点信息，根据该节点信息所包含的节点类型的定义文件的地址信息，从相应的VNF package中获取该节点类型的定义文 件，从而利用该定义文件对该节点信息中包含的动态信息进行解析及校验。
需要说明的是，如果NSD通过校验，NFVO还可以根据NSD包含的各个节点信息中的节点类型，将节点信息中的动态信息对应的导入VNF package包含的VNFD中。
在一种可能的实施方式中，如果NSD通过校验，NFVO还可以根据NSD中包含的每个节点类型，获取与该节点类型关联的VNF package info的标识，并将该VNF package info的标识存储到NSD info中。
可以理解的，NFVO可以向OSS/BSS返回校验结果。
步骤412，OSS/BSS向NFVO发送NS实例标识创建请求。
可以理解，NS实例标识创建请求用于请求NFVO创建与该NSD info相关的NS实例标识。
步骤413，NFVO向OSS/BSS发送NS实例标识。
步骤414，OSS/BSS向NFVO发送携带该NS实例标识的实例化NS请求。
步骤415，NFVO针对NSD中包含的每个节点类型，获取与该节点类型相关联的VNF package info，从该VNF package info中获取VNFD的标识。
这里，OSS/BSS向NFVO发送NSD或NSD的地址信息时同时发送了NSD info的标识，也就是说NSD info的标识和NSD存在关联。因此，如果NFVO中包含多个NSD，NFVO则可根据NS实例标识确定出OSS/BSS需要部署的NS的NSD，从而针对确定的NSD执行步骤415及其它处理流程。
在一种可能的实施方式中，在NFVO已经将NSD所包含的各个节点类型分别关联的VNF package info的标识存储到NSD info的情况下，NFVO可以针对NSD info中包含的每个VNF package info的标识，从该VNF package info的标识指示的VNF package info中获取VNFD的标识。
416，NFVO根据VNFD的标识请求VNFM实例化VNF。
具体地，对于步骤416，NFVO可以针对步骤415获取的每个NVFD的标识，首先向VNFM发送携带该VNFD的标识的VNF实例标识创建请求，以便VNFM针对该VNFD的标识分配VNF实例标识；NFVO可以在接收到VNFM针对该VNFD的标识分配的VNF实例标识之后，进一步向VNFM发送携带该VNF实例标识的实例化VNF请求，以便VNFM获取相应的VNFD或者包含该VNFD的VNF package，并利用该VNFD或包含该VNFD的VNF package实例化VNF，即根据该VNFD或包含该VNFD的VNF package与VIM进行相应的信息交互，完成创建VNF。
与前述各个实施例基于相同的构思，如图5所示，本申请实施例中还提供了一种NFVO102，所述NFVO102包括：
收发单元1021，用于接收实例化网络服务NS请求；
处理单元1023，用于根据所述实例化NS请求确定NSD，所述NSD中包含VNF的节点类型；获取与所述节点类型相关联的VNFPI，从所述VNFPI中获取VNFD的标识；根据所述VNFD的标识请求VNFM实例化VNF。
在一种可能的实施方式中，所述处理单元1023，还用于从VNFP中获取所述节点类型，将所述节点类型和所述VNFPI进行关联；从所述VNFP中获取所述VNFD的标识，将所述VNFD的标识存储到所述VNFPI中。
在一种可能的实施方式中，所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型；
所述处理单元1023，具体用于在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型。
在一种可能的实施方式中，所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型的定义文件在所述VNFP中的存储路径；
所述处理单元1023，具体用于在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型的定义文件在所述VNFP中的存储路径；根据所述存储路径从所述节点类型的定义文件中获取所述节点类型。
在一种可能的实施方式总，
所述处理单元1023，还用于根据所述存储路径和所述VNFP的存储位置，确定所述节点类型的定义文件的地址信息；
所述收发单元1021，还用于向业务请求方发送所述节点类型和所述地址信息，以便所述业务请求方生成所述NSD，所述NSD中包含所述节点类型和所述地址信息。
在一种可能的实施方式中，所述处理单元1023，具体用于确定所述VNFPI的标识，将所述节点类型和所述VNFPI的标识进行关联；以及具体用于获取与所述节点类型相关联的所述VNFPI的标识，并根据所述VNFPI的标识获取所述VNFPI。
在一种可能的实施方式中，所述VNFP中包含清单文件，所述清单文件中包含所述VNFD的标识；
所述处理单元1023，具体用于从所述VNFP包含的所述清单文件中获取所述VNFD的标识。
本申请实施例中还提供了一种计算机可读存储介质，用于存储指令，当所述指令被计算设备的处理器执行时，使得所述计算设备实现本申请任意一个实施例中提供的实例化NS的方法。
本申请实施例中提供了一种计算机程序产品，所述计算机程序产品包括计算机程序代码，当所述计算机程序代码在计算设备上运行时，使得所述计算设备执行本申请任意一个实施例中提供的实例化NS的方法。
本申请实施例中提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现本申请任意一个实施例中提供的实例化NS的方法。
本申请实施例中还提供了一种芯片系统，该芯片系统包括处理器，用于实现本申请任意一个实施例中所述的NFVO的功能，例如，接收或处理本申请任意一个实施例中所述的实例化NS的方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存程序指令和/或数据。该芯片系统可以由芯片构成，也可以包括芯片和其他分立器件。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实 现不应认为超出本申请实施例的范围。
应当理解的是，在本申请实施例的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述网络设备的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
可以理解，以上所描述的装置实施例是示意性的，例如，所述模块/单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
以上仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请实施例的保护范围之内
最后需要说明的是，以上实施例仅用以说明本申请的技术方案，而未对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解，依然可以对前述各个实施例中所提供的技术方案进行修改，或者对其中部分技术特征进行等同替换，而这些修改或替换，并不使相应技术方案的本质脱离本申请各个实施例中所提供技术方案的精神和范围。

Claims (16)

  1. 一种实例化网络服务NS的方法，其特征在于，所述方法应用于网络功能虚拟化编排器NFVO，所述方法包括：
    接收实例化NS请求；
    根据所述实例化NS请求确定网络服务描述信息NSD，所述NSD中包含虚拟化网络功能VNF的节点类型；
    获取与所述节点类型相关联的虚拟化网络功能包信息VNFPI，从所述VNFPI中获取虚拟化网络功能描述信息VNFD的标识；
    根据所述VNFD的标识请求虚拟化网络功能管理器VNFM实例化VNF。
  2. 根据权利要求1所述的方法，其特征在于，
    在所述接收实例化NS请求之前，所述方法还包括：
    从虚拟化网络功能包VNFP中获取所述节点类型，将所述节点类型和所述VNFPI进行关联；
    从所述VNFP中获取所述VNFD的标识，将所述VNFD的标识存储到所述VNFPI中。
  3. 根据权利要求2所述的方法，其特征在于，
    所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型；
    所述从VNFP中获取所述节点类型，包括：在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型。
  4. 根据权利要求2所述的方法，其特征在于，
    所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型的定义文件在所述VNFP中的存储路径；
    所述从VNFP中获取所述节点类型，包括：
    在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字获取所述节点类型的定义文件在所述VNFP中的存储路径；
    根据所述存储路径从所述节点类型的定义文件中获取所述节点类型。
  5. 根据权利要求4所述的方法，其特征在于，
    在所述接收实例化NS请求之前，所述方法还包括：
    根据所述存储路径和所述VNFP的存储位置，确定所述节点类型的定义文件的地址信息；
    向业务请求方发送所述节点类型和所述地址信息，以便所述业务请求方生成所述NSD，所述NSD中包含所述节点类型和所述地址信息。
  6. 根据权利要求2所述的方法，其特征在于，
    所述将所述节点类型和所述VNFPI进行关联，包括：确定所述VNFPI的标识，将所述节点类型和所述VNFPI的标识进行关联；
    所述获取与所述节点类型相关联的VNFPI，包括：获取与所述节点类型相关联的所述VNFPI的标识，并根据所述VNFPI的标识获取所述VNFPI。
  7. 根据权利要求2至6中任一项所述的方法，其特征在于，
    所述VNFP中包含清单文件，所述清单文件中包含所述VNFD的标识；
    所述从所述VNFP中获取所述VNFD的标识，包括：从所述VNFP包含的所述清单文件中获取所述VNFD的标识。
  8. 一种网络功能虚拟化编排器NFVO，其特征在于，所述NFVO包括：
    收发单元，用于接收实例化网络服务NS请求；
    处理单元，用于根据所述实例化NS请求确定网络服务描述信息NSD，所述NSD中包含虚拟化网络功能VNF的节点类型；获取与所述节点类型相关联的虚拟化网络功能包信息VNFPI，从所述VNFPI中获取虚拟化网络功能描述信息VNFD的标识；根据所述VNFD的标识请求虚拟化网络功能管理器VNFM实例化VNF。
  9. 根据权利要求8所述的NFVO，其特征在于，
    所述处理单元，还用于从虚拟化网络功能包VNFP中获取所述节点类型，将所述节点类型和所述VNFPI进行关联；从所述VNFP中获取所述VNFD的标识，将所述VNFD的标识存储到所述VNFPI中。
  10. 根据权利要求9所述的NFVO，其特征在于，
    所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型；
    所述处理单元，具体用于在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型。
  11. 根据权利要求9所述的NFVO，其特征在于，
    所述VNFP中包含元文件，所述元文件中包含声明关键字，所述声明关键字的取值为所述节点类型的定义文件在所述VNFP中的存储路径；
    所述处理单元，具体用于在所述VNFP包含的所述元文件中查询所述声明关键字，并从所述声明关键字中获取所述节点类型的定义文件在所述VNFP中的存储路径；根据所述存储路径从所述节点类型的定义文件中获取所述节点类型。
  12. 根据权利要求11所述的NFVO，其特征在于，
    所述处理单元，还用于根据所述存储路径和所述VNFP的存储位置，确定所述节点类型的定义文件的地址信息；
    所述收发单元，还用于向业务请求方发送所述节点类型和所述地址信息，以便所述业务请求方生成所述NSD，所述NSD中包含所述节点类型和所述地址信息。
  13. 根据权利要求9所述的NFVO，其特征在于，
    所述处理单元，具体用于确定所述VNFPI的标识，将所述节点类型和所述VNFPI的标识进行关联；以及具体用于获取与所述节点类型相关联的所述VNFPI的标识，并根据所述VNFPI的标识获取所述VNFPI。
  14. 根据权利要求9至13中任一项所述的NFVO，其特征在于，
    所述VNFP中包含清单文件，所述清单文件中包含所述VNFD的标识；
    所述处理单元，具体用于从所述VNFP包含的所述清单文件中获取所述VNFD的标识。
  15. 一种计算机可读存储介质，用于存储指令，当所述指令被计算设备的处理器执行时，使得所述计算设备实现权利要求1至7中任一项所述的方法。
  16. 一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1至7中任一项所述的方法。
PCT/CN2020/107121 2019-11-05 2020-08-05 实例化ns的方法及nfvo WO2021088444A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20885666.6A EP4040292A4 (en) 2019-11-05 2020-08-05 METHOD OF INSTANCIATION OF NS AND NFVO
US17/731,714 US11929879B2 (en) 2019-11-05 2022-04-28 NS instantiation method and NFVO

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911072099.5A CN112764873B (zh) 2019-11-05 2019-11-05 实例化ns的方法及nfvo
CN201911072099.5 2019-11-05

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/731,714 Continuation US11929879B2 (en) 2019-11-05 2022-04-28 NS instantiation method and NFVO

Publications (1)

Publication Number Publication Date
WO2021088444A1 true WO2021088444A1 (zh) 2021-05-14

Family

ID=75692541

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/107121 WO2021088444A1 (zh) 2019-11-05 2020-08-05 实例化ns的方法及nfvo

Country Status (4)

Country Link
US (1) US11929879B2 (zh)
EP (1) EP4040292A4 (zh)
CN (1) CN112764873B (zh)
WO (1) WO2021088444A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2583903B (en) * 2019-04-23 2022-11-02 Metaswitch Networks Ltd Testing virtualised network functions
US11838221B2 (en) * 2022-01-13 2023-12-05 Verizon Patent And Licensing Inc. Systems and methods for multi-cloud virtualized instance deployment and execution
CN117891447A (zh) * 2024-03-14 2024-04-16 蒲惠智造科技股份有限公司 一种企业管理软件开发方法、装置、设备及介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016121802A1 (ja) * 2015-01-28 2016-08-04 日本電気株式会社 仮想化管理・オーケストレーション装置、仮想化管理・オーケストレーション方法、および、プログラム
CN105873234A (zh) * 2015-01-20 2016-08-17 中兴通讯股份有限公司 虚拟化网络功能与网元管理系统建立连接的方法和装置
CN106161049A (zh) * 2015-03-27 2016-11-23 中兴通讯股份有限公司 一种实现网络服务部署规格配置的方法及装置
CN106982131A (zh) * 2016-01-18 2017-07-25 中兴通讯股份有限公司 发起vnf实例化的方法、装置及系统
CN107210957A (zh) * 2015-01-23 2017-09-26 日本电气株式会社 网络功能虚拟化管理和编排方法、设备和程序
CN107332750A (zh) * 2016-04-29 2017-11-07 华为技术有限公司 一种业务部署方法、装置以及网元

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070157078A1 (en) * 2005-12-30 2007-07-05 Discovery Productions, Inc. Method for combining input data with run-time parameters into xml output using xsl/xslt
FI124000B (fi) * 2007-12-11 2014-01-31 Documill Oy Menetelmä ja järjestely tiedonhakutulosten käsittelemiseksi
US20100004944A1 (en) * 2008-07-07 2010-01-07 Murugan Palaniappan Book Creation In An Online Collaborative Environment
US8185558B1 (en) * 2010-04-19 2012-05-22 Facebook, Inc. Automatically generating nodes and edges in an integrated social graph
EP3133794B1 (en) * 2014-05-15 2019-04-03 Huawei Technologies Co., Ltd. Network function virtualization network system
US9703859B2 (en) * 2014-08-27 2017-07-11 Facebook, Inc. Keyword search queries on online social networks
US9582514B2 (en) * 2014-12-27 2017-02-28 Ascava, Inc. Performing multidimensional search and content-associative retrieval on data that has been losslessly reduced using a prime data sieve
US10097354B2 (en) * 2015-08-21 2018-10-09 International Business Machines Corporation Privacy control using unique identifiers associated with sensitive data elements of a group
CN107689882B (zh) * 2016-08-05 2020-04-21 华为技术有限公司 一种虚拟化网络中业务部署的方法和装置
US10701418B2 (en) * 2017-02-14 2020-06-30 Level 3 Communications, Llc Systems and methods for resolving manifest file discontinuities
EP3596886A1 (en) * 2017-03-14 2020-01-22 Intel IP Corporation Instantiation of a virtual network function (vnf) as part of a gnodeb (gnb)
US10594621B2 (en) * 2017-07-10 2020-03-17 Hewlett Packard Enterprise Development Lp Managing virtualized network service bundles
US20190188285A1 (en) * 2017-12-19 2019-06-20 Facebook, Inc. Image Search with Embedding-based Models on Online Social Networks
KR102486236B1 (ko) * 2017-12-26 2023-01-09 삼성전자주식회사 무선 통신 시스템에서 네트워크 기능 가상화를 위한 장치 및 방법
US10965522B2 (en) * 2018-03-12 2021-03-30 Apple Inc. Management services for 5G networks and network functions
CN109347716B (zh) * 2018-09-25 2021-05-11 中国联合网络通信集团有限公司 消费者vnf的实例化方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105873234A (zh) * 2015-01-20 2016-08-17 中兴通讯股份有限公司 虚拟化网络功能与网元管理系统建立连接的方法和装置
CN107210957A (zh) * 2015-01-23 2017-09-26 日本电气株式会社 网络功能虚拟化管理和编排方法、设备和程序
WO2016121802A1 (ja) * 2015-01-28 2016-08-04 日本電気株式会社 仮想化管理・オーケストレーション装置、仮想化管理・オーケストレーション方法、および、プログラム
CN106161049A (zh) * 2015-03-27 2016-11-23 中兴通讯股份有限公司 一种实现网络服务部署规格配置的方法及装置
CN106982131A (zh) * 2016-01-18 2017-07-25 中兴通讯股份有限公司 发起vnf实例化的方法、装置及系统
CN107332750A (zh) * 2016-04-29 2017-11-07 华为技术有限公司 一种业务部署方法、装置以及网元

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4040292A4

Also Published As

Publication number Publication date
CN112764873B (zh) 2023-07-14
CN112764873A (zh) 2021-05-07
EP4040292A1 (en) 2022-08-10
US11929879B2 (en) 2024-03-12
US20220255803A1 (en) 2022-08-11
EP4040292A4 (en) 2022-11-16

Similar Documents

Publication Publication Date Title
US10700928B2 (en) Method and apparatus for deploying service in virtualized network
US10701139B2 (en) Life cycle management method and apparatus
US10432460B2 (en) Network service scaling method and apparatus
WO2021088444A1 (zh) 实例化ns的方法及nfvo
WO2017113201A1 (zh) 一种网络服务的生命周期管理方法及设备
WO2020108443A1 (zh) 一种虚拟化管理方法及装置
WO2017185251A1 (zh) Vnfm的确定方法和网络功能虚拟化编排器
WO2021185083A1 (zh) Vnf实例化方法及装置
WO2020103925A1 (zh) 一种容器化虚拟网络功能的部署方法和装置
WO2020211652A1 (zh) 多租户场景下的租户资源管理方法和装置
US11301284B2 (en) Method for managing VNF instantiation and device
EP4185949A1 (en) A method of container cluster management and system thereof
US20210326306A1 (en) Method and apparatus for deploying virtualised network function
WO2023046026A1 (zh) 一种容器化vnf的部署方法及装置
WO2021232860A1 (zh) 通信方法、装置及系统
WO2020249080A1 (zh) 一种虚拟网络功能vnf部署方法及装置
WO2021129868A1 (zh) 网络服务实例化的方法及网络功能虚拟化编排器
WO2023179580A1 (zh) 一种部署vnf的方法、装置及设备
US20240028346A1 (en) Linking kubernetes resources with underlying cloud infrastructure
WO2022183796A1 (zh) 一种创建网络服务ns的方法及相关装置
WO2023066208A1 (zh) 一种部署虚拟化网络功能的方法及装置
WO2023030218A1 (zh) 网络业务部署方法、nfvo以及nfv系统
US20230105269A1 (en) Virtualized network service deployment method and apparatus
WO2021083061A1 (zh) 虚拟网络功能的软件镜像的处理方法和装置
WO2019034084A1 (zh) 公共服务资源申请方法、相关设备及系统

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: 20885666

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020885666

Country of ref document: EP

Effective date: 20220506

NENP Non-entry into the national phase

Ref country code: DE