Scaling method and apparatus

Abstract

The embodiments of the present invention disclose a scaling method, apparatus, and system, which are related to the field of NFV. The method includes: a VNFM receives a VNF scale-out request from an NFVO, the request including VNF instance information and indication information indicating a scale aspect and step; the VNFM determines information about a VDU and corresponding subnet that needs to be generated based on the VNF scale-out request; the VNFM requests the generation of a VDU and corresponding subnet from a VIM. According to the embodiments of the present invention, the address request of a newly generated VDU or VNF can be dynamically fulfilled to avoid the shortage of IP addresses allocated when a VNF or NS is scaled out in the prior art, and avoid the waste of resources caused by directly defining a large IP address resource pool in the prior art.

Description

[Technical field]

[0001] The present application relates to the field of Network Function Virtualization (NFV), and in particular to a Virtualized Network Function (VNF) or Network Service (NS) Scaling method and apparatus. [Background technology]

[0002] Network Function Virtualization (NFV) is a technology that allows telecommunication network operators to implement software and hardware separation for some telecommunication network functions (such as core network functions) on common servers, switches, and storage devices by using virtualization technology in the information technology (IT) field to implement rapid and efficient deployment and operation of network services (NS) and to reduce network investment expenditures CAPEX and operational expenditures OPEX. Based on NFV technology, telecommunication network functions can be implemented in the form of software and run on common server hardware, and can be moved, instantiated, and deployed to different physical locations in the network as needed without the need to install new equipment.

[0003] Figure 1 shows a VNF Descriptor or Description Template (VNF Descriptor, VNFD) design instance provided in the existing ETSI NFV standard. The VNFD includes two Virtualization Deployment Units (VDUs), namely VDU_1 and VDU_2. Each VDU is associated with one Connection Point Descriptor (CPD), which is used to describe or define CP_1 and CP_2, and one Virtual Link Descriptor (VLD), which is used to describe or define a Virtual Link (VL), which is used to connect VDU_1 and VDU_2.

[0004] The information contained in CP_1 may be as follows: address_data: address_type: ip_address l3_address_data: ip_address_assignment:True floating_ip_activated: True ip_address_type:ipv4 number_of_ip_address:6

[0005] The preceding information describes information about the IP address requirements of CP_1, where the ip_address_type parameter indicates that the IP address type required by the CP is ipv4, and the number_of_ip_address parameter indicates that the minimum number of IP addresses required by the CP is 6.

[0006] Similar information is included in CP_2, which may be as follows: address_data: address_type:ip_address l3_address_data: ip_address_assignment:True floating_ip_activated: True ip_address_type:ipv4 number_of_ip_address:10

[0007] The preceding information describes information about the IP address requirements of CP_2, where the ip_address_type parameter indicates that the IP address type required by the CP is ipv4, and the number_of_ip_address parameter indicates that the minimum number of IP addresses required by the CP is 10.

[0008] The information contained in the VLD may be as follows: vl_profile: virtual_link_protocol_data: -associated_layer_protocol:Ethernet l2_protocol_data: network_type:vlan -associated_layer_protocol:ipv4 l3_protocol_data: ip_version:ipv4 ip_allocation_pools: - start_ip_address:192.168.1.1 - end_ip_address:192.168.1.100

[0009] The above information describes the requirement information of the network connection between VDUs, and the requirement information includes layer 2 network information l2_protocol_data and layer 3 network information l3_protocol_data. The l3_protocol_data indicates that the layer 3 network connection is based on ipv4, and the ip_allocation_pools defines information about the IP address resource pool of the layer 3 network, and to know that the IP address resource pool contains 100 IP addresses, the starting IP address is 192.168.1.1 and the final IP address is 192.168.1.100.

[0010] The VNFD further includes scaling information. For example, two scaling levels may be defined as follows: 1. Three instances of VDU_1 and four instances of VDU_2, 2. 6 instances of VDU_1, and 8 instances of VDU_2.

[0011] At level 1, the amount of IP addresses required for three VDU_1s can be calculated as 3×6=18, and the amount of IP addresses required for four VDU_2s can be calculated as 4×10=40. Hence, the total amount of IP addresses required is 18+40=58. These VDU instances are all connected to a VL that is created using a VLD. The IP address pool contained in the VL contains a total of 100 IP addresses, so the IP address allocation requirement can be met.

[0012] At level 2, the amount of IP addresses required for six VDU_1s can be calculated as 6×6=24, and the amount of IP addresses required for eight VDU_2s can be calculated as 8×10=80. Hence, the total amount of IP addresses required is 24+80=104. These VDU instances are all connected to a VL that is created using a VLD. The IP address pool contained in the VL contains a total of 100 IP addresses. Clearly, in this case, the VL cannot meet the IP address allocation requirements.

[0013] For VNFD or Network Service Descriptor or Network Service Description Template (NSD) defined in the current standard, especially for scaling scenarios, only the increase in the amount of VDU or VNF is considered, and for VL, only the connection bandwidth is adjusted, and other factors such as the amount of IP addresses that can be assigned are not considered. VNFD or NSD is designed in the early stage of VNF deployment or NS deployment. It is difficult to directly plan a large IP address resource pool for VL, because it may cause waste (IP address resource pool is used only when scaling out to a certain level) and because IP addresses may be insufficient when scaling, even if the planned IP address resource pool is large. Summary of the Invention

[0014] The embodiments of the present invention provide a scaling method and apparatus to avoid the shortage of assigned IP addresses in the scaling process of VNFs or NSs in the prior art.

[0015] In order to achieve the aforementioned objectives, the following technical solutions are used in the embodiments of this application.

[0016] According to a first aspect, an embodiment of the present application provides a scaling method, including: a VNFM receives a VNF scale-out request from an NFVO, the request including VNF instance information and indication information indicating a scale aspect and step, the VNFM determines information regarding a VDU and a corresponding subnet that needs to be generated based on the VNF scale-out request, and the VNFM requests generation of the VDU and the corresponding subnet from the VIM.

[0017] In a possible implementation, the VNFM determines information about the VDUs and corresponding subnets that need to be generated based on the VNF scale-out request includes: the VNFM finds a corresponding VNFD based on the VNF instance information, and queries the VNFD based on the indication information to determine information about the VDUs and corresponding subnets that need to be generated. The VNFD includes scale aspect parameter information and scale step parameter information, and the scale step parameter information includes subnet information.

[0018] In a possible implementation, the subnet information includes one or more of the following: the amount of subnets, and the type and range of IP addresses that may be assigned to each subnet. The scale step parameter information further includes a parameter indicating whether the generated VDU is connected to a subnet.

[0019] According to a second aspect, an embodiment of the present application provides a scaling method, including: an NFVO receives an NS scale-out request, the request including NS instance information and indication information indicating a scale manner and step; the NFVO determines information regarding VNFs and corresponding subnets that need to be generated based on the NS scale-out request; and the NFVO requests generation of the VNFs and corresponding subnets from the VIM via the VNFM.

[0020] In a possible implementation, the NFVO determines information about the VNFs and corresponding subnets that need to be generated based on the NS scale-out request includes: the VNFM finds a corresponding NSD based on the NS instance information, and queries the NSD based on the indication information to determine information about the VNFs and corresponding subnets that need to be generated. The NSD includes scale aspect parameter information and scale step parameter information, and the scale step parameter information includes subnet information.

[0021] According to a third aspect, an embodiment of the present application provides a communication device for implementing the method according to the first aspect or any one of the possible implementations of the first aspect. The device includes corresponding units or components configured to perform the aforementioned method. The units included in the device may be implemented by software and / or hardware. The device may be, for example, a terminal, or a chip, a chip system, or a processor capable of supporting a terminal in implementing the aforementioned method.

[0022] According to a fourth aspect, an embodiment of the present application provides a communication device for implementing the method according to the second aspect or any one of the possible implementations of the second aspect. The device includes corresponding units or components configured to perform the aforementioned method. The units included in the device may be implemented by software and / or hardware. The device may be, for example, a network device, or a chip, a chip system, or a processor capable of supporting the network device in implementing the aforementioned method.

[0023] According to a fifth aspect, an embodiment of the present application provides a computer readable medium. The computer readable medium stores a computer program or instructions. When the computer program or instructions are executed, the computer is enabled to perform a method according to the first aspect or any one of the possible implementations of the first aspect.

[0024] According to a sixth aspect, an embodiment of the present application provides a computer readable medium. The computer readable medium stores a computer program or instructions. When the computer program or instructions are executed, the computer is enabled to perform a method according to the second aspect or any one of the possible implementations of the second aspect.

[0025] According to a seventh aspect, an embodiment of the present application provides a scaling system, comprising an NFVO, a VNFM and a VIM, each configured to implement steps performed by the NFVO, the VNFM and the VIM in any possible manner of the first aspect or the second aspect.

[0026] Any communication device, chip, computer readable medium, computer program product, communication system, etc. provided above may be understood to be configured to implement the corresponding method presented above. Thus, a beneficial effect that can be achieved by the communication device, chip, computer readable medium, computer program product, communication system, etc. is to avoid a shortage of assigned IP addresses when a VNF or NS is scaled out in the prior art, and to avoid resource waste caused by directly defining a large IP address resource pool in the prior art. [Brief description of the drawings]

[0027] [Figure 1] FIG. 1 is a schematic diagram of a prior art VNFD design instance. [Diagram 2] FIG. 1 is a schematic diagram of an architecture of an NFV network system according to an embodiment of the present application. [Diagram 3] FIG. 2 is a schematic diagram of a hardware structure of a communication device of each NFV network element according to an embodiment of the present application. [Figure 4] 1 is a schematic flowchart of a scaling (scaling out) method according to Embodiment 1 of the present application; [Diagram 5] 4 is a schematic flowchart of a scaling (scaling out) method according to Embodiment 2 of the present application; [Figure 6] 1 is a schematic flowchart of a scaling (scaling-in) method according to Embodiment 3 of the present application; [Figure 7] FIG. 13 is a schematic diagram of an NSD design instance according to embodiment 4 of the present application. [Figure 8] 1 is a schematic flowchart of a scaling (scaling out) method according to Embodiment 4 of the present application; [Figure 9] 11 is a schematic flowchart of a scaling (scaling-in) method according to embodiment 5 of the present application; [Figure 10] 1 is a schematic diagram illustrating a structure of a communication device according to an embodiment of the present application; [Figure 11] 1 is a schematic configuration diagram of a communication system according to an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0028] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, implementations of the embodiments of the present application will be described in detail with reference to the accompanying drawings.

[0029] 2 is a schematic diagram of an architecture of an NFV system 20 according to an embodiment of the present application. The NFV system 20 may be used in various networks, for example, implemented as a data center (data center 201 or data center 206 shown in FIG. 2), an operator network, or a local area network. The NFV system 20 includes an NFV management and orchestration system (NFV MANO) 201, an NFV infrastructure (NFVI) 202, multiple VNFs 203, multiple element management (EM) 204, and an operation support system / business support system (OSS / BSS) 205.

[0030] The NFV MANO 201 may be configured to monitor and manage the NFVI 202 and the VNFs 203. The NFV MANO 201 may include an NFV orchestrator (NFVO) 2011, one or more VNF managers (VNFMs) 2012, and a VIM 2013. The NFVO 2011 may be configured to manage the lifecycle of virtualized services, allocate and schedule virtual resources within the NFVI 202, etc. Furthermore, the NFVO 2011 may communicate with one or more VNFMs 2012 to perform resource related requests. The NFVO 2011 may further send configuration information to the VNFM 2012 to collect status information of the VNFs 203. Additionally, the NFVO 2011 may further communicate with the VIM 2013 to perform resource allocation and / or reservation and exchange configuration and status information of virtualized hardware resources. The VNFM 2012 may be configured to manage the lifecycle of one or more VNFs, for example, to instantiate, update, query, scale, and terminate the VNFs 203. Additionally, the VNFM 2012 may communicate with the VNFs 203 to complete the VNF lifecycle management and exchange configuration and status information. Multiple VNFMs may be included in an NFV system. Different VNFMs may manage the lifecycle of different types of VNFs. The VIM 2013 may control and manage interactions between the VNFs 203 and the computing hardware 2024, storage hardware 2025, network hardware 2026, virtual computing 2021, virtual storage 2022, and virtual network 2023.For example, the VIM 2013 may perform resource management functions, including managing infrastructure resources and allocating (e.g., adding resources to virtual containers) and executing functions (e.g., collecting NFVI fault information). The VNFM 2012 and the VIM 2013 may communicate with each other to request resource allocation, exchange configuration and status information for virtualized hardware resources, etc.

[0031] The NFVI 202 in FIG. 2 includes a hardware resource layer, a virtualization layer, and a virtual resource layer. The deployment of the virtualization environment is completed based on the hardware resources, software resources, or a combination of hardware and software resources included in the NFVI 202. In other words, the hardware resource layer and the virtualization layer are used to provide virtualization resources (e.g., another form of virtual machine and virtual container) to be used for the VNF 203. The hardware resource layer includes computing hardware 2024, storage hardware 2025, and network hardware 2026. The computing hardware 2024 may be a commercially available existing hardware and / or a user customized hardware, and is configured to provide processing and computing resources. The storage hardware 2025 may be a storage capacity provided by a network, or a storage capacity of the storage hardware 2025 (local memory in a server). In an implementation solution, the resources of the computing hardware 2024 and the storage hardware 2025 may be centralized. The network hardware 2026 may be a switch, a router, and / or any other network device configured to have switching capabilities. The network hardware 2026 may span multiple domains and include multiple networks interconnected by one or more transport networks. The virtualization layer in the NFVI 202 may abstract the hardware resources from the physical layer, decoupling the VNFs 203 and providing virtualized resources to the VNFs 203. The virtual resource layer includes virtual compute 2021, virtual storage 2022, and virtual network 2023. The virtual compute 2021 and virtual storage 2022 may be provided to the VNFs 203 in the form of a virtual machine and / or another virtual container.For example, one or more VNFs 203 may be deployed on a virtual machine (VM). The virtualization layer abstracts the network hardware 2026 to form a virtual network 2023, which may include a virtual switch, which is configured to connect the virtual machines.

[0032] With respect to hardware, the computing hardware 2024, storage hardware 2025, and network hardware 2026 may include multiple subracks, multiple racks, or even multiple equipment rooms. With respect to software, there may be one VIM 2013, or there may be multiple VIMs, managing different hardware resources separately.

[0033] EM 204 is a system for network element configuration and management in traditional telecommunication systems. In an NFV system, EM 204 may also be configured to configure and manage VNFs and initiate lifecycle management operations such as instantiating new VNFs to a VNFM.

[0034] The OSS / BSS 205 supports various end-to-end telecommunications services. Management functions supported by the OSS include network configuration, service provisioning, fault management, etc. The BSS may be configured to process orders, payments, revenue, etc. and supports product management, order management, revenue management, and customer management.

[0035] The NFV system 20 shown in Fig. 2 is used merely as an example and does not limit the technical solution of the present application. Those skilled in the art should understand that in a specific implementation process, the NFV system 20 may further include another network element, and the amount of the network element may be determined based on a specific requirement. This is not limited.

[0036] 2 in this embodiment of the present application, for example, the NFVO 2011, the VIM 2013, or the OSS / BSS 205, may be a function module in an apparatus. It may be understood that the function module may be an element in a hardware device, a software function module running on the hardware, or a virtualization function instantiated on a platform (e.g., a cloud platform).

[0037] For example, each network element in FIG. 2 may be implemented by a communication device 30 in FIG. 3. FIG. 3 is a schematic diagram of a hardware structure of a communication device that may be used in an embodiment of the present application. The communication device 30 includes at least one processor 301 and at least one communication interface 304, and is configured to implement the method provided in the embodiment of the present application. The communication device 30 may further include a communication line 302 and a memory 303.

[0038] The processor 301 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to control program execution of the solutions of the present application.

[0039] The communication lines 302 may include a path, such as a bus, for transferring information between the aforementioned components.

[0040] The communication interface 304 is configured to communicate with other devices or communication networks. The communication interface 304 may be any device, such as a transceiver, for example, an Ethernet interface, a radio access network (RAN) interface, a wireless local area network (WLAN) interface, a transceiver, a pin, a bus, or a transceiver circuit.

[0041] The memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, or a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or may be, but is not limited to, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other compact disc storage medium, an optical disc storage medium (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), and a magnetic disc storage medium or other magnetic storage device, or any other medium that can be configured to hold or store the expected program code in the form of instructions or data structures and that is accessible by a computer. The memory may exist independently or be coupled to the processor 301 via communication line 302. The memory 303 may alternatively be integrated with the processor 301. The memory provided in this embodiment of the present application may generally be non-volatile. The memory 303 is configured to store computer-executable instructions for implementing the solutions provided in the embodiments of the present application, and the processor 301 controls the execution of the computer-executable instructions. The processor 301 is configured to execute the computer-executable instructions stored in the memory 303 to implement the methods provided in the embodiments of the present application.

[0042] The computer-executable instructions in the embodiments of the present application may also be referred to as application program code, which is not particularly limited in the embodiments of the present application.

[0043] A coupling in this embodiment of the present application may be an indirect coupling or communication connection between devices, units or modules in electrical, mechanical or other form, used for information exchange between the devices, units or modules.

[0044] In an embodiment, the processor 301 may include one or more CPUs, for example, CPU 0 and CPU 1 of FIG.

[0045] In an embodiment, the communication device 30 may include multiple processors, such as processor 301 and processor 305 of FIG. 3. Each of the processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor herein may be one or more devices, circuits, and / or processing cores configured to process data (e.g., computer program instructions).

[0046] The communication device 30 may be a general-purpose device or a dedicated device. In a specific implementation, the communication device 30 may be a desktop computer, a network server, or a device having a structure similar to that of FIG. 3. In the embodiment of the present application, the type of the communication device 30 is not limited.

[0047] With reference to FIG. 4 to FIG. 9, the following describes in detail the scaling method provided in the embodiment of the present application.

[0048] It should be noted that the names of messages between network elements, the names of parameters in messages, etc. in the following embodiments of the present application are merely examples, and there may be other names in a specific implementation, which are not particularly limited in the embodiments of the present application.

[0049] It should be noted that in the embodiments of the present application, " / " may represent an "or" relationship between related objects. For example, A / B may represent A or B. "And / or" may be used to represent the existence of three relationships between related objects. For example, A and / or B may represent the following three cases: only A is present, both A and B are present, and only B is present. A and B may be singular or plural.

[0050] In order to facilitate the description of technical solutions in the embodiments of the present application, in the embodiments of the present invention, terms such as "first" and "second" may be used to distinguish technical features with the same or similar functions. Terms such as "first" and "second" do not limit the quantity and execution order, and terms such as "first" and "second" do not indicate clear differences. In the embodiments of the present application, terms such as "exemplary" or "for example" are used to represent an example, explanation, or description. Any embodiment or design manner described with "exemplary" or "for example" is not described as being preferred or having many advantages over another embodiment or design manner. The use of terms such as "exemplary" or "for example" is intended to present related concepts in a particular manner for easy understanding.

[0051] In the embodiments of the present application, for technical features, terms such as "first", "second", "third", "A", "B", "C", and "D" are used to distinguish technical features with respect to technical features, and it should be noted that there is no chronological or size order between the technical features described by "first", "second", "third", "A", "B", "C", and "D".

[0052] It may be understood that identical steps or steps or technical features having the same function in the embodiments of the present application may be cross-referenced in different embodiments.

[0053] In the embodiments of the present application, it may be understood that the NFVO, the VIM, and / or the VNFM may perform some or all of the steps in the embodiments of the present application. These steps are merely examples. In the embodiments of the present application, other steps or variations of various steps may be further performed. In addition, the steps may be performed in a different order than the order presented in the embodiments of the present application, and not all steps in the embodiments of the present application need to be performed.

[0054] In the embodiment of the present application, the specific configuration of the execution body of the method for establishing a network connection is not particularly limited in the embodiment of the present application, as long as the method provided in the embodiment of the present application can be implemented. For example, the method for establishing a network connection provided in the embodiment of the present application may be implemented by the NFVO or by a component, such as a chip, used in the NFVO. This is not limited in the present application. Alternatively, the method for establishing a network connection provided in the embodiment of the present application may be implemented by the VIM or by a component, such as a chip, used in the VIM. This is not limited in the present application. Alternatively, the method for establishing a network connection provided in the embodiment of the present application may be implemented by the VNFM or by a component, such as a chip, used in the VNFM. This is not limited in the present application. In the following embodiment, an example in which the method for establishing a network connection is separately implemented by the NFVO, the VIM, and the VNFM is used for explanation.

[0055] 4 is a flowchart of embodiment 1 of the present invention. Both embodiment 1 and embodiment 2 describe a Scale Out process in VNF scaling (also called "scaling"). The main difference is whether a newly created VDU needs to be connected or associated with a newly created subnet. In embodiment 1, connection or association is required, and in embodiment 2, connection or association is not required.

[0056] Specific implementation steps of the first embodiment will be described below.

[0057] 401. The NFVO sends a VNF-specific scaling request (abbreviated as "VNF Scaling Request") to the VNFM. In this embodiment, the request is specifically a Scale Out request, which includes VNF instance information (e.g., a VNF instance ID) and indication information indicating a scale aspect or scale range and a scale step.

[0058] For specific meanings of the above-mentioned terminology or names (such as aspects and steps), please refer to relevant descriptions in existing NFV standards (such as IFA011 v4.1.1). The indication information indicating a scale aspect mainly includes an AspectId, where the ID corresponds to a scale aspect defined in the VNFD, and the scale aspect of the VNFD includes specific and related information such as the names, quantities and / or characteristics of VDUs and VLs. The indication information indicating a step mainly includes a scaling step of the aspect, for example, step 1 or step 2.

[0059] 402. The VNFM receives a VNF scale-out request, finds a corresponding VNFD based on the VNF instance information in the request, and queries the VNFD based on the indication information to determine information about the VDUs that need to be generated and the corresponding subnets.

[0060] The aspects defined in the VNFD in the prior art include the scaling detail parameter ScalingDelta, as shown in the table below.

[0061] [Table 1]

[0062] It mainly includes parameters such as vduDelta and virtualLinkBitRateDelta. The vduDelta parameter represents a VDU scaling detailed parameter, which is mainly the amount of related VDU instances. The virtualLinkBitRateDelta parameter represents a virtual link scaling detailed parameter, which is mainly the bit rate of related virtual links.

[0063] In this embodiment of the present invention, the virtualLinkBitRateDeltaAspect parameter in ScalingDelta included in the existing VNFD is modified and extended as follows.

[0064] [Table 2]

[0065] The name of virtualLinkBitRateDelta in the existing VNFD may be changed to virtualLinkDelta (or the name may not be changed), and the specific parameters included are as follows:

[0066] [Table 3]

[0067] The above NumberofSubnet, SubnetInfo, and DedicatedOrNot are parameters newly added in this embodiment of the present invention.

[0068] Different steps are defined in the VNFD based on the above extensions. For example, the following two steps may be defined: Step 1: A total of 3 instances of VDU_1, a total of 4 instances of VDU_2, and a VL bitrate of 4Gbps. Step 2: A total of 6 instances of VDU_1, a total of 8 instances of VDU_2, and a VL bitrate of 8Gbps.

[0069] In addition, in step 2, newly added parameters are included or associated, namely NumberofSubnet:N (N is an integer equal to or greater than 1), SubnetInfo (containing the content L3ProtocolData), and DedicatedOrNot:True / False. DedicatedOrNot:True / False is optional. When N is 1, it indicates that one subnet needs to be generated. The aforementioned parameter L3ProtocolData defines the information required to generate a subnet, including IP address type and range, as follows: L3_Protocol_Data: IP_version:L3ProtocolData ip_allocation_pools - start_ip_address:192.168.10.1 - end_ip_address:192.168.10.100

[0070] If N is greater than 1, the amount of SubnetInfo parameters is also N. Since the NumberofSubnet parameter is optional, if the NumberofSubnet parameter is absent, the amount of subnets to be added is equal to the amount of SubnetInfo parameters, and one subnet is added per SubnetInfo parameter accordingly.

[0071] DedicatedOrNot: true / false indicates whether the newly created subnet needs to be connected or associated with the above newly created VDU. True indicates that the newly created subnet needs to be connected or associated with the newly created VDU. False indicates that the newly created VDU instance does not need to be associated with a new subnet instance. The newly created VDU instance may first be associated with an existing subnet instance in the VL, and if no subnet instance is available, it may be associated with new subnet information. In embodiment 1, the value of DedicatedOrNot is true.

[0072] After receiving a VNF scale-out request, the VNFM first finds a corresponding VNFD based on the VNF instance information in the request, e.g., the VNF instance ID. This VNFD is an extended VNFD. Then, the VNFM queries the VNFD based on the indication information. Specifically, the VNFM searches the VNFD based on the aspect ID included in the indication information to determine the scale aspect or scale range. Then, the VNFM searches the VNFD based on the step information in the indication information to determine the required scale step and associated content. For example, if the aspect ID in the VNF scale-out request is ID XXX, the VNFM searches the VNFD to determine that the aspect corresponding to ID XXX in the VNFD includes VDU_1, VDU_2, and VL. In addition, if the step indication information in the VNF scale out request is step 2, the VNFM searches the VNFD to determine that in step 2 of the above example, 6 VDU_1 instances and 8 VDU_2 instances need to be generated, the VL bitrate is 8Gbps, and one new subnet needs to be generated. Specific instantiation parameters are included in the L3ProtocolData, and the newly generated VDUs need to be associated with a subnet. The amount of newly generated VDUs is the amount of VDUs in the corresponding step minus the amount of VDUs included in the unscaled VNF. In this example, a total of 6 VDU_1 instances and 8 VDU_2 instances need to be generated in step 2. The amount of newly generated VDU_1 instances and VDU_2 instances is respectively the amount of VDU_1 instances, which is 6, minus the amount of VDU_1 instances in the unscaled VNF (e.g., 3), and the amount of VDU_2 instances, which is 8, minus the amount of VDU_2 instances in the existing VNF (e.g., 6). In this case, the quantities of the newly created VDU_1 and VDU_2 instances are 3 and 2, respectively. The method of determining the quantity of subnets to be created is different from that of the VDUs to be created described above.NumberofSubnet: 1 indicates that one new subnet needs to be created, and the amount of existing subnets in the virtual link VL of the existing VNF is not taken into account.

[0073] 403. The VNFM sends a resource grant request, in other words a request to the NFVO to allow the creation of resources that need to be created and that are determined in step 402, including new VDU instance resources and new subnet resources. For subnet resources, the request includes: AddResource: Type:Subnet ResourceTemplateId: VLD (ID of the VLD in the VNFD) L3ProtocolData

[0074] 404. The NFVO returns an authorization approval message to the VNFM, which carries the VIM access information, etc.

[0075] 405. The VNFM is applied to the VIM based on the information about the subnet determined in step 402 for the generation of a new subnet instance, which includes information about the new IP address range or resource pool, which may be, for example, as follows: - start_ip_address:192.168.10.1 - end_ip_address:192.168.10.100

[0076] 406. After the subnet is created, the VIM returns a subnet instance creation completion notification message and instance information to the VNFM.

[0077] 407. After receiving the subnet creation completion notification message, the VNFM initiates an authorization request to the NFVO for the creation of a link port. The request carries the following information: AddResource: Type: Link Port Subnet instance information

[0078] This indicates that the link ports that need to be created are associated with the newly created subnet instance.

[0079] 408. The NFVO sends an authorization acknowledgement message to the VNFM.

[0080] 409. The VNFM initiates the link port creation to the VIM, which holds the information about the subnet instance that needs to be associated.

[0081] 410. The VNFM is applied to the VIM for the creation of a new VDU instance, and the VDU type and VDU quantity determined in step 402 are retained, and information about the newly created link port is retained.

[0082] 411. After the VDU instance is created, the VIM associates the VDU instance with the newly created subnet via a link port, and the newly created subnet assigns an IP address to the VDU instance.

[0083] In this embodiment of the present invention, parameters such as NumberofSubnet and SubnetInfo are added to the newly defined VNFD. Thus, during scaling out, a corresponding amount of IP addresses can be allocated based on the scale-out size (corresponding to different steps) to dynamically meet the address requirements of the newly created VDUs. This can avoid the shortage of IP addresses allocated when a VNF is scaled out in the prior art, and avoid the resource waste caused by directly defining a large IP address resource pool in the prior art.

[0084] 5 is a flowchart of the embodiment 2. The difference between the embodiment 2 and the embodiment 1 is that the newly created VDU does not need to be connected or associated with the newly created subnetwork.

[0085] Specific implementation steps of the second embodiment will be described below.

[0086] 501. This step is the same as step 401 in embodiment 1.

[0087] 502. The difference from step 402 in embodiment 1 is that the value of DedicatedOrNot included in step 2 defined in the VNFD is false, indicating that the newly added VDU instance does not need to be associated with the newly created subnet instance.

[0088] 503 to 506. The steps are the same as steps 403 to 406 in embodiment 1.

[0089] 507. The value of DedicatedOrNot in step 2 of the VNFD is false. Therefore, the new VDU instance does not need to be associated with the new subnet instance. Therefore, the link port authorization request initiated by the VNFM to the NFVO carries only link port information and does not carry subnet information. For example, the following can be shown: AddResource: Type: Link Port

[0090] 508. This step is the same as step 1 of embodiment 1. 408 is the same as:

[0091] 509. The VNFM is applied to the VIM for the creation of a link port. If the VNFM determines that the IP address can be assigned to the subnet of the original VL network, the newly created link port is associated with the existing subnet information. If not, the newly created link port is associated with the new subnet information.

[0092] 510. This step is the same as step 410 in embodiment 1.

[0093] 511. After the VDU instance is created, the VIM associates the VDU instance with an existing subnet via a link port (in this case, the IP address can also be assigned to the subnet of the original VL network). The existing subnet assigns an IP address to the VDU instance, or associates the VDU instance with a newly created subnet, which assigns an IP address to the VDU instance.

[0094] 6 is a flowchart of embodiment 3 of the present invention. Embodiment 3 shows steps following embodiment 1 or 2, and describes a VNF Scale In process.

[0095] Specific implementation steps of the third embodiment will be described below.

[0096] 601. The NFVO sends a VNF-specific scaling request to the VNFM. In this embodiment, the request is specifically a Scale In request, which includes VNF instance information (e.g., a VNF instance ID) and indication information indicating a scale aspect and step.

[0097] For example, if the current VNF ​​is at step 2 and step 1 is indicated in the indication information, the VNF is scaled in from step 2 to step 1.

[0098] 602. The VNFM receives a VNF scale-in request, finds a corresponding VNFD based on the VNF instance information in the request, and queries the VNFD based on the indication information to determine information about the VDUs and corresponding subnets that need to be deleted. In this embodiment, the VNFD that is the same as that in embodiment 1 is still used, and the VNFD still includes the following two steps: Step 1: A total of 3 instances of VDU_1, a total of 4 instances of VDU_2, and a VL bitrate of 4Gbps. Step 2: Total 6 instances of VDU_1, total 8 instances of VDU_2, VL bitrate of 8Gbps, NumberofSubnet:1, L3ProtocolData, and DedicatedOrNot:True.

[0099] In this case, when the VNF is scaled in from step 2 to step 1, 3 instances of VDU_1 need to be reduced, 4 instances of VDU_2 need to be reduced, and 1 subnet (similar to the newly generated subnet in embodiment 1) needs to be removed from the VL.

[0100] 603. The VNFM sends a Grant request to the NFVO. The RemoveResource parameter of the Grant request includes descriptive information about the subnet resources, computing resources (corresponding to the VDUs) and link port resources that need to be deleted.

[0101] 604. The VNFM receives an authorization approval message from the NFVO.

[0102] 605. The VNFM is applied to the VIM for deletion of the corresponding subnet resource, the virtual machine resource corresponding to the VUD, and the link port resource, etc.

[0103] 606. The VIM sends a resource deletion success message to the VNFM.

[0104] 607. The VNFM sends a scale-in complete message to the NFVO.

[0105] The embodiment of the present invention can be further extended to a Network Service (NS) scaling scenario. Figure 7 is a schematic diagram of an NS Descriptor (NSD) design instance. This instance mainly includes a VNFD describing a VNF, for example, corresponding VNFD 1 and VNFD 2 describing VNF_1 and VNF_2 in the figure, an NsVld describing a virtual link VL, and a Descriptor describing an External Connection Point (ExtCp) of the VNF. VnfExtCP_1 and VnfExtCP_2 in the figure are the external connection points of VNF_1 and VNF_2.

[0106] The above embodiment 1 to embodiment 3 describe the scenario where scaling is performed on VNF. When scaling is performed on NS, the IP address shortage problem also occurs in NsVld for correspondingly connecting VNF_1 and VNF_2. The above problem can also be solved by using NS scaling process in the following embodiment 4 and embodiment 5 of the present invention.

[0107] 8 is a flowchart of NS scaling according to embodiment 4 of the present invention, specifically a flowchart of scaling out. Specific steps of embodiment 4 are as follows:

[0108] 801. The NFVO receives an NS-specific scaling request (short for "NS scaling request") from the OSS / BSS. In this embodiment, the request is specifically a Scale Out request, which includes NS instance information (e.g., NS instance ID) and indication information indicating a scale aspect and step.

[0109] 802. The NFVO receives the scale-out request, finds a corresponding NSD based on the NS instance information in the request, and queries the NSD based on the indication information to determine information about the VNFs that need to be generated and the corresponding subnets.

[0110] For NSD content, in this embodiment, the virtualLinkToLevelMapping information of NsLevel (similar to the virtualLinkBitRateDelta of ScalingDelta of VNFD) is mainly extended.

[0111] The extended virtualLinkToLevelMapping contains the following information:

[0112] [Table 4]

[0113] Based on the new extension, the following two steps can be defined in NsLevel (the following specific numbers are used as examples): Step 1: A total of 3 instances of VNF_1, a total of 4 instances of VNF_2, and a VL bitrate of 4Gbps. Step 2: A total of 6 instances of VNF_1, a total of 8 instances of VNF_2, and a VL bitrate of 8Gbps.

[0114] In addition, in step 2, newly added parameters, namely NumberofSubnet:N (N is an integer equal to or greater than 1), SubnetInfo (containing the content L3ProtocolData), and DedicatedOrNot:True / False are included or associated. DedicatedOrNot:True / False is optional.

[0115] The meanings of the above newly added parameters are similar to those in embodiment 1 and embodiment 2, and the details are not described again in this specification. In this embodiment, the value of DedicatedOrNot is true.

[0116] After receiving the scale-out request, the NFVO first finds the corresponding NSD based on the NS instance information in the request, for example, the NS instance ID. This NSD is an extended NSD. Then, the NFVO queries the NSD based on the indication information. Specifically, the NFVO searches the NSD based on the aspect in the indication information to determine the scale object or aspect. Then, the NFVO searches the NSD based on the step in the indication information to determine the required scale step. For example, if the aspect in the VNF scale-out request includes VNF_1, VNF_2, and VL in step 2, the VNFM searches the NSD to determine that, in step 2 of the above example, six VNF_1 instances and eight VNF_2 instances need to be generated, the VL bit rate is 8Gbps, and one new subnet needs to be generated. Specific instantiation parameters are included in the L3ProtocolData, and the newly generated VNF needs to be associated with a subnet. The amount of newly generated VNFs is the amount of VNFs in the corresponding step minus the amount of VNFs included in the unscaled VNFs. In this example, a total of 6 VNF_1 instances and 8 VNF_2 instances need to be generated in step 2. The amount of newly generated VNF_1 instances and VNF_2 instances is the amount of VNF_1 instances, which is 6, minus the amount of VNF_1 instances of the unscaled VNF (e.g., 2), and the amount of VNF_2 instances, which is 8, minus the amount of VNF_2 instances of the existing VNFs (e.g., 5). In this case, the amount of newly generated VNF_1 instances and VNF_2 instances is 4 and 3, respectively. The method of determining the amount of subnets to be generated is different from that of the VNFs to be generated described above. NumberofSubnet:1 indicates that one new subnet needs to be generated, and the amount of existing subnets in the virtual link VL of the existing VNF is not taken into account.

[0117] 803. The NFVO determines, based on the information about the VL (step 2 information), that one new subnet needs to be generated for the original VL instance and applies to the VIM for the generation of the subnet.

[0118] 804. The NFVO sends a VNF instantiation request to the VNFM based on the new VNF instance that needs to be created, which holds information about the VL instance to which the VNF needs to be connected (by using VnfExtCp_1). Since the value of DedicatedOrNot in step 2 defined in Nslevel of the NSD is true, the VL instance information further includes information about the newly created subnet instance in step 803.

[0119] 805. Optionally, if step 804 does not include link port information of the subnet to which the new VNF instance is connected, the VNFM sends a grant request to the NFVO to authorize the creation of the new link port and add association information with the same subnet instance in addResource.

[0120] 806. The NFVO sends an authorization approval message to the VNFM.

[0121] 807. The VNFM is applied to the VIM for the creation of link ports and includes information about the new subnet.

[0122] 808. For the new VNF instance that needs to be generated, the VNFM applies to the VIM for generation of the new VNF instance and connects it to the subnet using VnfExtCp_1 and the newly generated link port.

[0123] 809. The VIM creates a VDU to create a VNF instance and associates the VNF instance with the newly created subnet via a link port.

[0124] The fifth embodiment of the present invention is a scale-in process in NS scaling, which is similar to the scale-in process of VNF. As shown in FIG. 9, the specific steps are as follows:

[0125] 901. The NFVO receives an NS-specific Scale request from the OSS / BSS. In this embodiment, the request is specifically a Scale In request, which includes NS instance information (e.g., an NS instance ID) and indication information indicating a scale aspect and step.

[0126] For example, if the current VNF ​​is in step 2 and step 1 is indicated in the indication information, the NS is scaled in from step 2 to step 1.

[0127] 902. After receiving the NS scale-in request, the NFVO finds the corresponding NSD based on the NS instance ID information in the request, and queries the NSD based on the indication information to determine information about the VNFs and corresponding subnets that need to be deleted. In this embodiment, the same NSD as that in embodiment 4 is still used, and two steps can be defined in NsLevel as follows (the following specific values ​​are used as examples): Step 1: A total of 3 instances of VNF_1, a total of 4 instances of VNF_2, and a VL bitrate of 4Gbps. Step 2: A total of 6 instances of VNF_1, a total of 8 instances of VNF_2, and a VL bitrate of 8Gbps.

[0128] In addition, new parameters, namely NumberofSubnet: 1, SubnetInfo (with content L3ProtocolData), and DedicatedOrNot: true / false, are added in step 2. DedicatedOrNot: true / false is optional.

[0129] In this case, when NS is scaled in from step 2 to step 1, 3 instances of VNF_1 need to be reduced, 4 instances of VNF_2 need to be reduced, and 1 subnet needs to be removed from the VL.

[0130] 903. The NFVO applies to the VIM for deletion of corresponding subnet resources, virtual machine resources corresponding to different VDUs contained in the VNF, link port resources, etc.

[0131] 904. The VIM deletes the resource and sends a resource deletion success message to the NFVO.

[0132] The actions of the NFVO, the VNFM, or the VIM of the method steps in the above embodiments may be implemented by the processor 401 in the communication device 40 shown in FIG. 4 by calling application program codes stored in the memory 403. This is not limited in the embodiments.

[0133] The above mainly describes the solutions provided in the embodiments of the present application from the perspective of interactions between network elements. To implement the aforementioned functions, the NFVO, VNFM, VIM, etc. may be understood to include corresponding hardware structures and / or software modules for implementing the functions. Those skilled in the art should easily recognize that the present application can be implemented by hardware, or a combination of hardware and computer software, in combination with the example units and algorithm operations described in the embodiments disclosed herein. Whether the functions are implemented by hardware or by hardware driven by computer software depends on the design constraints of the specific application and technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but the implementation should not be considered to go beyond the scope of the present application.

[0134] In the embodiment of the present application, functional module division may be implemented for the NFVO, the VNFM, the VIM, etc. based on the above-mentioned method example. For example, each functional module may be obtained by division based on each corresponding function, or two or more functions may be integrated into one processing module. The integrated module may be implemented in the form of hardware or in the form of a software function module. It should be noted that in the embodiment of the present application, the module division is an example and is merely a logical function division. In actual implementation, another division method may be used.

[0135] For example, in the case where each functional module is obtained by division in an integrated manner, FIG. 10 is a schematic diagram of the structure of a communication device 100. The communication device 100 includes a transceiver module 1001 and a processing module 1002.

[0136] For example, the communication device 100 is configured to implement the functionality of a VNFM. For example, the communication device 100 is a VNFM in the embodiment illustrated in FIG. 4, the embodiment illustrated in FIG. 5, or the embodiment illustrated in FIG. 6.

[0137] In this embodiment of the present application, the communication device 100 may be a VNFM, may be a chip used for VNFM, or may be other composite devices, components, etc. having the functionality of VNFM. If the communication device 100 is a VNFM, the transceiver module 1001 may be a transceiver. The transceiver may include an antenna, a radio frequency circuit, etc. The processing module 1002 may be a processor (or processing circuit), for example a baseband processor, which may include one or more CPUs. If the communication device 100 is a component having the functionality of VNFM, the transceiver module 1001 may be a radio frequency unit, and the processing module 1002 may be a processor (or processing circuit), for example a baseband processor. If the communication device 100 is a chip system, the transceiver module 1001 may be an input / output interface of a chip (for example, a baseband chip), and the processing module 1002 may be a processor (or processing circuit) of the chip system, which may include one or more central processing units. It should be understood that the transceiver module 1001 in this embodiment of the present application may be implemented by a transceiver or a transceiver-related circuit component, and the processing module 1002 may be implemented by a processor or a processor-related circuit component (also referred to as a processing circuit).

[0138] For example, the transceiver module 1001 may be configured to perform all transmit and receive operations, e.g., S401 and S403, performed by the VNFM of the embodiment shown in Figure 4, and / or may be configured to support other processing of the techniques described herein. The processing module 1002 may be configured to perform all operations, e.g., S402, except for the transmit and receive operations, performed by the VNFM of the embodiment shown in Figure 4, and / or may be configured to support other processing of the techniques described herein.

[0139] In another example, the transceiver module 1001 may be configured to perform all transmit and receive operations, e.g., S601 and S603, performed by the VNFM of the embodiment shown in Figure 6, and / or may be configured to support other processing of the techniques described herein. The processing module 1002 may be configured to perform all operations, e.g., S602, except for the transmit and receive operations, performed by the VNFM of the embodiment shown in Figure 6, and / or may be configured to support other processing of the techniques described herein.

[0140] When the communication device 100 is configured to implement the functions of the VNFM, for other functions that can be implemented by the communication device 100, please refer to the relevant descriptions of the embodiments shown in Figures 4 to 6, 8 and 9. Details will not be described again.

[0141] Similarly, for example, the communication device 100 may be configured to implement the function of an NFVO. For example, the communication device 100 may be the NFVO of the embodiment shown in Figure 8 or the embodiment shown in Figure 9, or the NFVO of the embodiment shown in Figures 4 to 6. Details will not be described again.

[0142] In this embodiment of the present application, the communication device 100 may be a VIM, a chip used for a VIM, or other composite device, component, etc. having the function of a VIM. If the communication device 100 is a VIM, the transceiver module 1001 may be a transceiver. The transceiver may include an antenna, a radio frequency circuit, etc. The processing module 1002 may be a processor (or processing circuit), e.g., a baseband processor, which may include one or more CPUs. If the communication device 100 is a component having the function of a VIM, the transceiver module 1001 may be a radio frequency unit, and the processing module 1002 may be a processor (or processing circuit), e.g., a baseband processor. If the communication device 100 is a chip system, the transceiver module 1001 may be an input / output interface of a chip (e.g., a baseband chip), and the processing module 1002 may be a processor (or processing circuit) of the chip system, which may include one or more central processing units. It should be understood that the transceiver module 1001 in this embodiment of the present application may be implemented by a transceiver or a transceiver-related circuit component, and the processing module 1002 may be implemented by a processor or a processor-related circuit component (also referred to as a processing circuit).

[0143] For example, the transceiver module 1001 may be configured to perform all of the transmit and receive operations performed by the VIM of the embodiments shown in Figures 4 to 6, 8, and 9, and the processing module 1002 may be configured to perform all of the operations performed by the VIM of the embodiments shown in Figures 4 to 6, 8, and 9 except for the transmit and receive operations, and / or may be configured to support other processing of the techniques described herein.

[0144] Figure 11 is a schematic configuration diagram of a communication system. As shown in Figure 11, the communication system 110 may include an NFVO 1101, a VNFM 1102, and a VIM 1103. Please note that Figure 11 is merely an exemplary diagram. The network elements and the amount of network elements included in the communication system 110 shown in Figure 11 are not limited in the embodiment of the present application.

[0145] The VNFM 1102 is configured to implement the functions of the VNFM in the aforementioned embodiment. For example, the VNFM 1102 may be configured to receive scaling request information from the NFVO 1101, query a VNFD based on the request information, determine information about a VDU and corresponding subnet that needs to be generated, and apply to the VIM 1103 for generation of the VDU and the corresponding subnet.

[0146] The NFVO 1101 is configured to implement the function of the NFVO in the above-mentioned method embodiment, and the VIM 1103 is configured to implement the function of the VIM in the above-mentioned method embodiment. Details will not be described again.

[0147] It should be noted that all relevant contents of the steps in the foregoing method embodiments may be referred to the functional descriptions of the corresponding network elements of the communication system 110, and will not be described again in detail herein.

[0148] The above description of the implementation allows those skilled in the art to clearly understand that the above division of functional modules is used as an example for explanation, for the purpose of convenient and concise description. In actual application, the above functions can be allocated to different modules and implemented as desired, that is, the internal structure of the device is divided into different functional modules to implement all or part of the above functions.

[0149] In some embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the described apparatus embodiments are merely examples. For example, the module or unit division is merely a logical division of functions, and may be divided in other ways in actual implementation. For example, multiple units or components may be combined or integrated to become another apparatus, or some functions may be ignored or not implemented. In addition, the shown or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. Indirect couplings or communication connections between apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0150] The units described as separate parts may or may not be physically separated, and the parts shown as units may be one or more physical units, located in one location, or distributed in different locations. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

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

[0152] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiment of the present application may be implemented in the form of a software product, or the part that contributes to the prior art, or all or part of the technical solution. The software product is stored in a storage medium and includes some instructions for instructing a device (which may be a single-chip microcomputer, a chip, etc.) or a processor to perform all or part of the steps of the method described in the embodiment of the present application. The aforementioned storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0153] The above description is merely a specific implementation of the present application, but does not limit the protection scope of the present application. Any variation or replacement within the technical scope disclosed in the present application shall fall within the protection scope of the present application. Therefore, the protection scope of the present application shall be determined by the protection scope of the claims.

Claims

1. A virtualized network function (VNF) scaling method, the method comprising: receiving, by a VNFM, a VNF scale-out request from a NFVO, the request including VNF instance information and indication information indicating a scale aspect and step; determining information about VDUs and corresponding subnets that need to be generated based on the VNF scale-out request by the VNFM; requesting, by said VNFM, a VIM to generate said VDU and said corresponding subnet; A virtualized network function (VNF) scaling method comprising:

2. The step of determining information about VDUs and corresponding subnets that need to be generated based on the VNF scale-out request by the VNFM includes: Finding, by the VNFM, a corresponding VNFD based on the VNF instance information, and querying the VNFD based on the indication information to determine the information regarding the VDU and the corresponding subnet that needs to be created; The method of claim 1 , wherein the VNFD includes scale aspect parameter information and scale step parameter information, the scale step parameter information including subnet information.

3. 3. The method of claim 2, wherein the subnet information includes one or more of the following: quantity of subnets, and type and range of IP addresses that can be assigned to each subnet.

4. The method of claim 2 , wherein the scale step parameter information further comprises a parameter indicating whether the generated VDU is connected to the subnetwork.

5. The method of claim 4, further comprising the step of requesting, by the VNFM, the VIM to generate a linkport, the VDU being connected to the subnetwork via the linkport.

6. The method comprises: receiving, by the VNFM, a VNF scale-in request from a NFVO, the request including VNF instance information and indication information indicating a scale manner and step; determining, by the VNFM, information about VDUs and corresponding subnets that need to be deleted based on the VNF scale-in request; requesting, by the VNFM, the VIM to delete the VDU and the corresponding subnet; The method of claim 1 further comprising:

7. The step of determining information about VDUs and corresponding subnets that need to be deleted based on the VNF scale-in request by the VNFM includes: Finding, by the VNFM, a corresponding VNFD based on the VNF instance information, and querying the VNFD based on the indication information to determine the information regarding the VDU and the corresponding subnet that need to be deleted; The method of claim 6 , wherein the VNFD includes scale aspect parameter information and scale step parameter information, the scale step parameter information including subnet information.

8. 8. The method of claim 7, wherein the subnet information includes one or more of the following: quantity of subnets, and type and range of IP addresses that may be assigned to each subnet.

9. A network service NS scaling method, the method comprising: receiving an NS scale-out request by an NFVO, the request including NS instance information and indication information indicating a scale manner and step; determining information about VNFs and corresponding subnets that need to be created based on the NS scale-out request by the NFVO; requesting, by said NFVO, via a VNFM, creation of said VNF and said corresponding subnet from a VIM; A network service NS scaling method comprising:

10. The step of determining information about VNFs and corresponding subnets that need to be generated based on the NS scale-out request by the NFVO includes: Finding, by the VNFM, a corresponding NSD based on the NS instance information, and querying the NSD based on the indication information to determine the information regarding the VNF and the corresponding subnet that needs to be created; The method of claim 9 , wherein the NSD includes scale aspect parameter information and scale step parameter information, the scale step parameter information including subnet information.

11. 11. The method of claim 10, wherein the subnet information includes one or more of the following: quantity of subnets, and type and range of IP addresses that may be assigned to each subnet.

12. The method of claim 10 , wherein the scale step parameter information further comprises a parameter indicating whether the created VNF is connected to the subnet.

13. The method of claim 12, further comprising the step of requesting, by the VNFM, the VIM to create a linkport, the VNF being connected to the subnetwork via the linkport.

14. The method includes the steps of receiving, by the NFVO, an NS scale-in request, the request including NS instance information and indication information indicating a scale manner and step; determining information about VNFs and corresponding subnets that need to be deleted based on the NS scale-in request by the NFVO; requesting, by the NFVO, the VIM to delete the VNF and the corresponding subnet via the VNFM; The method of claim 9 further comprising:

15. The step of determining information about VNFs and corresponding subnets that need to be deleted based on an NS scale-in request by the NFVO includes: Finding, by the VNFM, a corresponding NSD based on the NS instance information, and querying the NSD based on the indication information to determine the information regarding the VNF and the corresponding subnet that needs to be deleted; The method of claim 9 , wherein the NSD includes scale aspect parameter information and scale step parameter information, the scale step parameter information including subnet information.

16. 16. The method of claim 15, wherein the subnet information includes one or more of the following: quantity of subnets, and type and range of IP addresses that may be assigned to each subnet.

17. A scaling device comprising a module adapted to implement the method according to any one of claims 1 to 8.

18. A scaling apparatus comprising a processor, the processor coupled to a memory, the memory storing a computer program, the processor configured to call the computer program in the memory to enable the apparatus to perform the method of any one of claims 1 to 8.

19. A scaling device comprising a module adapted to implement the method according to any one of claims 9 to 16.

20. A scaling apparatus comprising a processor, the processor coupled to a memory, the memory storing a computer program, the processor configured to call the computer program in the memory to enable the apparatus to perform the method of any one of claims 9 to 16.

21. A scaling system comprising a NFVO, a VNFM, and a VIM, wherein the VNFM is configured to perform a method according to any one of claims 1 to 8.

22. A scaling system comprising a NFVO, a VNFM, and a VIM, wherein the NFVO is configured to perform a method according to any one of claims 9 to 16.

23. 17. A computer readable storage medium, the storage medium storing a computer program which, when executed, performs the method according to any one of claims 1 to 8 or claims 9 to 16.

Images