A method and device for elastic expansion and contraction

Abstract

Embodiments of the present invention disclose a method, apparatus, and system for elastic scaling, relating to the field of NFV. These methods include: a VNFM receiving a VNF scale-out request from an NFVO, the request including VNF instance information and information indicating the aspect and step of the scale; the VNFM determining the VDU to be created and the corresponding subnet information based on the VNF scale request; and the VNFM requesting the VIM to create the VDU and the corresponding subnet. These embodiments of the present invention can dynamically meet the address requirements of newly created VDUs or VNFs, avoiding the existing situation of insufficient IP address allocation during VNF or NS expansion, and avoiding the existing situation of directly defining a large IP address resource pool, which ultimately results in waste.

Description

Technical Field

[0001] The present application relates to the field of Network Function Virtualization (NFV), and in particular to a method and apparatus for elastic scaling of virtualized network functions (VNF) or network services (NS). Background Art

[0002] Network Function Virtualization (NFV) refers to telecom network operators leveraging virtualization technology from the information technology (IT) field to decouple the implementation of certain telecom network functions (such as core network functions) from software and hardware within general-purpose servers, switches, and storage. This enables rapid and efficient deployment and operation of network services (NS), while also reducing network investment costs (CAPEX) and operating costs (OPEX). By applying NFV technology, telecom network functions are implemented in software and can run on general-purpose server hardware. They can be migrated, instantiated, and deployed at different physical locations on the network as needed, without the need to install new equipment.

[0003] Figure 1 This is a VNF descriptor or description template (VNFD) design example given in the existing ETSI NFV standard. The VNFD contains two virtual deployment units (VDUs), VDU_1 and VDU_2. Each VDU is associated with a connection point descriptor or description template (CPD), which is used to describe or define CP_1 and CP_2, and a virtual link descriptor or description template (VLD), which is used to describe or define the virtual link (VL) used to connect VDU_1 and VDU_2.

[0004] The information contained in CP_1 can include:

[0005] address_data:

[0006] address_type:ip_address

[0007] l3_address_data:

[0008] ip_address_assignment:true

[0009] floating_ip_activated:true

[0010] ip_address_type:ipv4

[0011] number_of_ip_address:6

[0012] The above information describes the IP address requirements of CP_1. 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.

[0013] The information contained in CP_2 is similar and can include:

[0014] address_data:

[0015] address_type:ip_address

[0016] l3_address_data:

[0017] ip_address_assignment:true

[0018] floating_ip_activated:true

[0019] ip_address_type:ipv4

[0020] number_of_ip_address:10

[0021] The above information describes the IP address requirements of CP_2. 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.

[0022] The information that VLD can contain is:

[0023] vl_profile:

[0024] virtual_link_protocol_data:

[0025] -associated_layer_protocol:ethernet

[0026] l2_protocol_data:

[0027] network_type:vlan

[0028] -associated_layer_protocol:ipv4

[0029] l3_protocol_data:

[0030] ip_version:ipv4

[0031] ip_allocation_pools:

[0032] -start_ip_address:192.168.1.1

[0033] -end_ip_address:192.168.1.100

[0034] The above information describes the network connection requirements between VDUs, including Layer 2 network information l2_protocol_data and Layer 3 network information l3_protocol_data. l3_protocol_data indicates that the Layer 3 network connection is based on IPv4. ip_allocation_pools defines the IP allocation resource pool information of the Layer 3 network. The starting IP address is 192.168.1.1 and the last IP address is 192.168.1.100, so we know that the IP address resource pool contains 100 IP addresses.

[0035] VNFD also contains information for elastic scaling. For example, two scaling levels can be defined:

[0036] 1. VDU_1 3 instances, VDU_2 4 instances

[0037] 2. VDU_1 6 instances, VDU_2 8 instances

[0038] For level 1, we can calculate that the IP addresses required for three VDU_1 instances are 3 * 6 = 18, and the IP addresses required for four VDU_2 instances are 4 * 10 = 40, for a total of 18 + 40 = 58 IP addresses. These VDU instances are connected to a VL created through VLD. The VL contains a total IP address pool of 100 IP addresses, which can meet the IP address allocation requirements.

[0039] For level 2, we can calculate that the IP addresses required for the six VDU_1 instances are 6*6=24, and the IP addresses required for the eight VDU_2 instances are 8*10=80, for a total of 24+80=104 IP addresses. These VDU instances are all connected to a VL created through VLD. This VL contains a total IP address pool of 100 IP addresses. Clearly, this VL can no longer meet the IP address allocation requirements.

[0040] The VNFD or Network Service Descriptor (NSD) model currently defined in the standard, particularly for elastic scaling (also known as capacity expansion and contraction), only considers increasing the number of VDUs or VNFs. For VLs, this only adjusts connection bandwidth, without considering other factors, such as the number of allocable IP addresses. When designing a VNFD or NSD, it's during the initial stages of VNF or NS deployment. It's difficult for VLs to directly plan a large IP address resource pool because, firstly, it could result in waste (it's only needed when capacity is expanded to a certain level), and, secondly, even if a large pool is planned, there's a chance of running out of IP addresses during elastic scaling. Summary of the Invention

[0041] The embodiments of the present invention provide a method and apparatus for elastic scaling, which can avoid the situation in the prior art where insufficient IP addresses are allocated to VNFs or NSs during elastic scaling.

[0042] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0043] In a first aspect, an embodiment of the present application provides an elastic scaling method, comprising: a VNFM receiving a VNF capacity expansion Scale Out request from an NFVO, wherein the request includes VNF instance information and indication information for indicating the Scale dimension Aspect and the Step level; the VNFM determining the VDU to be created and the corresponding subnet Subnet information based on the VNF Scale request; and the VNFM requesting the VIM to create the VDU and the corresponding Subnet.

[0044] In a possible implementation, the VNFM determines the VDU to be created and the corresponding subnet information according to the VNF Scale Out request, including: the VNFM finds the corresponding VNFD according to the VNF instance information, and queries the VNFD according to the indication information to determine the VDU to be created and the corresponding subnet information; wherein the VNFD includes Scale Aspect and Step parameter information, and the Scale Step parameter information includes Subnet information.

[0045] In a possible implementation, the Subnet information includes one or more of the following: the number of subnets, the type and range of IP addresses available for allocation in each subnet; and the Scale Step parameter information further includes a parameter for indicating whether the created VDU is connected to the Subnet.

[0046] In a second aspect, an embodiment of the present application provides an elastic scaling method, including NFVO receiving a NS capacity expansion ScaleOut request, the request including NS instance information and indication information for indicating the dimension Aspect and level Step of Scale; NFVO determining the VNF to be created and the corresponding subnet Subnet information based on the NS Scale request; NFVO requesting VIM to create the VNF and the corresponding Subnet through VNFM.

[0047] In one possible implementation, the NFVO determines the VNF to be created and the corresponding subnet information according to the NS Scale Out request, including: the VNFM finds the corresponding NSD according to the NS instance information, and queries the NSD according to the indication information to determine the VNF to be created and the corresponding subnet information; wherein the NSD includes ScaleAspect and Step parameter information, and the Scale Step parameter information includes Subnet information.

[0048] In a third aspect, embodiments of the present application provide a communications device that can implement the method of the first aspect, or any possible implementation of the first aspect. The device includes corresponding units or components for executing the above-mentioned method. The units included in the device can be implemented in software and / or hardware. The device can be, for example, a terminal, or a chip, chip system, or processor that can support the terminal to implement the above-mentioned method.

[0049] In a fourth aspect, embodiments of the present application provide a communications device that can implement the method of the second aspect, or any possible implementation of the second aspect. The device includes corresponding units or components for executing the above-mentioned method. The units included in the device can be implemented in software and / or hardware. The device can be, for example, a network device, or a chip, chip system, or processor that can support the network device to implement the above-mentioned method.

[0050] In a fifth aspect, an embodiment of the present application provides a computer-readable medium having a computer program or instructions stored thereon, which, when executed, enables the computer to execute the method described in the first aspect or any possible implementation of the first aspect.

[0051] In a sixth aspect, an embodiment of the present application provides a computer-readable medium having a computer program or instructions stored thereon, which, when executed, enables the computer to execute the method described in the second aspect or any possible implementation of the second aspect.

[0052] In a seventh aspect, embodiments of the present application provide an elastic scaling system. The system includes an NFVO, a VNFM, and a VIM, each configured to implement the steps performed by the NFVO, the VNFM, and the VIM, respectively, in any possible method of the first or second aspect.

[0053] It can be understood that any of the communication devices, chips, computer-readable media, computer program products or communication systems provided above are used to execute the corresponding methods provided above. Therefore, the beneficial effect that can be achieved is that it can avoid the situation of insufficient IP address allocation when the VNF or NS of the prior art is expanded, or it can also avoid the situation where the prior art directly defines a large IP address resource pool, which ultimately causes waste. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A schematic diagram of a VNFD design example provided by the prior art;

[0055] Figure 2 A schematic diagram of the architecture of an NFV network system provided in an embodiment of the present application;

[0056] Figure 3 Schematic diagram of the hardware structure of the communication device of each NFV network element provided in the embodiment of the present application;

[0057] Figure 4 This is a flowchart of the elastic scaling (capacity expansion) method provided in Example 1 of the present application;

[0058] Figure 5 This is a flowchart of the elastic scaling (capacity expansion) method provided in Example 2 of the present application;

[0059] Figure 6 This is a schematic diagram of the process of the elastic expansion (contraction) method provided in Example 3 of the present application;

[0060] Figure 7 A schematic diagram of an NSD design example provided in Example 4 of this application;

[0061] Figure 8 A schematic diagram of a flow chart of the elastic scaling (capacity expansion) method provided in Example 4 of the present application;

[0062] Figure 9 A schematic flow chart of the elastic expansion (contraction) method provided in Example 5 of the present application;

[0063] Figure 10 A schematic diagram of the structure of a communication device provided in an embodiment of the present application;

[0064] Figure 11 A schematic diagram of the composition of a communication system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] The implementation of the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0066] Please refer to Figure 2 , Figure 2 The NFV system 20 is a schematic diagram of the architecture of an embodiment of the present application. The NFV system 20 can be used in various networks, such as in a data center ( Figure 2 The NFV system 20 is implemented in a data center 201 or data center 206 as shown, a carrier 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 operations support system and business support system (OSS / BSS) 205.

[0067] NFV MANO 201 can monitor and manage NFVI 202 and VNF 203. NFV MANO 201 can include an NFV orchestrator (NFVO) 2011, one or more VNF managers (VNFMs) 2012, and a VIM 2013. NFVO 2011 can manage the lifecycle of virtualized services and allocate and schedule virtual resources within NFVI 202. Furthermore, NFVO 2011 can communicate with one or more VNFMs 2012 to execute resource-related requests. NFVO 2011 can also send configuration information to VNFMs 2012 to collect VNF ​​203 status information. NFVO 2011 can also communicate with VIMs 2013 to allocate and / or reserve resources and exchange virtualized hardware resource configuration and status information. VNFM 2012 can be used to manage the lifecycle of one or more VNFs, for example, instantiating VNF 203, updating VNF 203, querying VNF 203, scaling VNF 203, terminating VNF 203, etc. Furthermore, VNFM 2012 can communicate with VNF 203 to complete VNF lifecycle management and exchange configuration and status information. In an NFV system, there can be multiple VNFMs. Different VNFMs can manage the lifecycles of different types of VNFs. VIM 2013 can control and manage the interaction between VNF 203 and computing hardware 2024, storage hardware 2025, network hardware 2026, virtual computing 2021, virtual storage 2022, and virtual network 2023. For example, VIM 2013 can perform resource management functions, including managing infrastructure resources, allocation (e.g., adding resources to virtual containers), and operational functions (e.g., collecting NFVI fault information). VNFM 2012 and VIM 2013 can communicate with each other to request resource allocation and exchange virtualized hardware resource configuration and status information.

[0068] Figure 2The NFVI 202 in FIG. 1 includes a hardware resource layer, a virtualization layer, and a virtual resource layer. The hardware resources, software resources, or a combination of the two included in NFVI 202 complete the deployment of a virtualized environment. In other words, the hardware resources and the virtualization layer are used to provide virtualized resources, such as virtual machines and other forms of virtual containers, for VNF 203. The hardware resource layer includes computing hardware 2024, storage hardware 2025, and network hardware 2026. The computing hardware 2024 can be off-the-shelf hardware and / or user-customized hardware to provide processing and computing resources. The storage hardware 2025 can be storage capacity provided within the network or storage capacity residing in the storage hardware 2025 itself (local memory within the server). In one implementation, the resources of the computing hardware 2024 and the storage hardware 2025 can be centralized. The network hardware 2026 can be a switch, a router, and / or any other network device configured with switching capabilities. Network hardware 2026 can span multiple domains and include multiple networks interconnected by one or more transport networks. The virtualization layer in NFVI 202 can abstract hardware resources from the physical layer and decouple VNFs 203 to provide virtualized resources to VNFs 203. The virtual resource layer includes virtual computing 2021, virtual storage 2022, and virtual networks 2023. Virtual computing 2021 and virtual storage 2022 can be provided to VNFs 203 in the form of virtual machines and / or other virtual containers. For example, one or more VNFs 203 can be deployed on a virtual machine (VM). The virtualization layer abstracts network hardware 2026 to form virtual networks 2023, which can include virtual switches that provide connections between virtual machines.

[0069] In terms of hardware, computing hardware 2024, storage hardware 2025, and network hardware 2026 may include multiple chassis, multiple racks, or even multiple computer rooms. In terms of software, there may be one VIM 2013 or multiple VIMs, each managing different hardware resources.

[0070] EM 204 is a system used to configure and manage network elements in traditional telecommunications systems. In NFV systems, EM 204 can also be used to configure and manage VNFs, as well as initiate lifecycle management operations such as instantiating new VNFs to the VNFM.

[0071] OSS / BSS 205 supports a variety of end-to-end telecommunications services. OSS management functions include network configuration, service provisioning, and fault management. BSS can be used to process orders, payments, and revenue, supporting product management, order management, revenue management, and customer management.

[0072] Figure 2 The NFV system 20 shown is for example purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art will appreciate that, in a specific implementation, the NFV system 20 may further include other network elements, and the number of network elements may be determined based on specific needs without limitation.

[0073] Optionally, the embodiment of the present application Figure 2 Each network element in the present invention, such as NFVO 2011, VIM 2013, or OSS / BSS 205, can be a functional module within a device. It is understood that the functional module can be a component in a hardware device, a software functional module running on the hardware, or a virtualized function instantiated on a platform (e.g., a cloud platform).

[0074] For example, Figure 2 Each network element in the Figure 3 It is implemented by the communication device 30 in. Figure 3 The figure shows a hardware structure diagram of a communication device applicable to an embodiment of the present application. The communication device 30 includes at least one processor 301 and at least one communication interface 304 for implementing the method provided in the embodiment of the present application. The communication device 30 may also include a communication circuit 302 and a memory 303.

[0075] 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 for controlling the execution of the program of the present application.

[0076] The communication link 302 may include a path for transmitting information between the above components, such as a bus.

[0077] Communication interface 304 is used to communicate with other devices or communication networks. Communication interface 304 can be any transceiver-like device, such as 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.

[0078] The memory 303 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited to this. The memory can be independent and coupled to the processor 301 via a communication line 302. The memory 303 can also be integrated with the processor 301. The memory provided in the embodiment of the present application can generally be non-volatile. Among them, the memory 303 is used to store the computer execution instructions involved in executing the solution provided in the embodiment of the present application, and is controlled by the processor 301 to execute. The processor 301 is used to execute the computer-executable instructions stored in the memory 303, thereby implementing the method provided in the embodiment of the present application.

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

[0080] The coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.

[0081] As an embodiment, the processor 301 may include one or more CPUs, such as Figure 3 CPU0 and CPU1 in.

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

[0083] The communication device 30 can be a general purpose device or a dedicated device. Figure 3 The embodiment of the present application does not limit the type of the communication device 30.

[0084] The following combination Figures 4 to 9 A method for elastic expansion and contraction provided in an embodiment of the present application is specifically described.

[0085] It should be noted that the message names between network elements or the names of parameters in the messages in the following embodiments of the present application are only examples, and other names may be used in specific implementations. The embodiments of the present application do not specifically limit this.

[0086] It should be noted that in the embodiments of the present application, " / " can indicate that the objects associated with each other are in an "or" relationship, for example, A / B can indicate A or B; "and / or" can be used to describe that there are three relationships between associated objects, for example, A and / or B can indicate: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural.

[0087] In order to facilitate the description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" can be used to distinguish technical features with the same or similar functions. The words such as "first" and "second" do not limit the quantity and execution order, and the words such as "first" and "second" do not necessarily limit them to be different. In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" should not be interpreted as being more preferred or more advantageous than other embodiments or design. The use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0088] It should be noted that in the embodiments of the present application, for a technical feature, the technical features in the technical feature are distinguished by "first", "second", "third", "A", "B", "C" and "D", and there is no order of precedence or size between the technical features described by "first", "second", "third", "A", "B", "C" and "D".

[0089] It can be understood that the same step or steps or technical features with the same functions in the embodiments of the present application can be referenced and borrowed from each other in different embodiments.

[0090] It is understood that in the embodiments of the present application, the NFVO, and / or VIM, and / or VNFM may perform some or all of the steps in the embodiments of the present application. These steps are merely examples, and the embodiments of the present application may also perform other steps or variations of various steps. Furthermore, the steps may be performed in a different order than those presented in the embodiments of the present application, and it is not necessary to perform all of the steps in the embodiments of the present application.

[0091] In the embodiments of the present application, the specific structure of the execution subject of the method for establishing a network connection is not particularly limited in the embodiments of the present application, as long as the method provided in the embodiments of the present application can be implemented. For example, the execution subject of the method for establishing a network connection provided in the embodiments of the present application may be NFVO, or a component applied in NFVO, such as a chip, and this application does not limit this. Alternatively, the execution subject of the method for establishing a network connection provided in the embodiments of the present application may be VIM, or a component applied in VIM, such as a chip, and this application does not limit this. Alternatively, the execution subject of the method for establishing a network connection provided in the embodiments of the present application may be VNFM, or a component applied in VNFM, such as a chip, and this application does not limit this. The following embodiments are described by taking the execution subjects of the method for establishing a network connection as NFVO, VIM, and VNFM as examples.

[0092] refer to Figure 4 , Figure 4 This is a flowchart of Example 1 of the present invention. Both Examples 1 and 2 describe the scale-out process in VNF elastic scaling (also known as "scaling"). The main difference lies in whether the newly created VDU must be connected or associated with the newly created subnet. In Example 1, this connection or association is required, while in Example 2, it is not required.

[0093] The specific implementation steps of Example 1 are described below:

[0094] 401. NFVO sends a VNF elastic scaling request (referred to as "VNF elastic scaling request") for the VNF to the VNFM. In this embodiment, it is a scale-out request. The request includes VNF instance information (such as VNF instance ID) and indication information for indicating the dimension or range (Aspect) and level (Step) of scale.

[0095] The specific meanings of the aforementioned professional terms or names (such as Aspect and Step) can be found in the relevant descriptions of existing NFV standards (such as IFA011 v4.1.1). The information indicating the scale dimension (Aspect) primarily includes AspectId, which corresponds to a Scale Aspect defined in the VNFD. The Scale Aspect in the VNFD includes specific information such as the VDU and VL names, quantities, and / or characteristics. The information indicating Step primarily includes the level of elastic scaling within the Aspect, such as Step 1 or Step 2.

[0096] 402. The VNFM receives the VNF Scale request, finds the corresponding VNFD according to the VNF instance information in the request, and queries the VNFD according to the instruction information to determine the VDU and corresponding subnet information to be created.

[0097] The Aspect defined by the existing VNFD includes the ScalingDelta parameter for elastic scaling, as shown in the following table:

[0098]

[0099] It mainly includes parameters vduDelta and virtualLinkBitRateDelta. The parameter vduDelta describes the VDU elasticity detail parameters, mainly the number of related VDU instances; the parameter virtualLinkBitRateDelta describes the virtuallink elasticity detail parameters, mainly the bit rate of the related virtual link.

[0100] The embodiment of the present invention makes the following changes and extensions to the virtualLinkBitRateDeltaAspect parameter in the ScalingDelta included in the existing VNFD:

[0101]

[0102] The name of the virtualLinkBitRateDelta in the existing VNFD can be changed to virtualLinkDelta (or the name can remain unchanged). The specific parameters include:

[0103]

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

[0105] Based on the above extensions, different steps are defined in VNFD. For example, the following two levels of steps can be defined:

[0106] Step 1: VDU_1 has 3 instances, VDU_2 has 4 instances, and the VL bit rate is 4 Gbps.

[0107] In Step 2, VDU_1 has 6 instances, VDU_2 has 8 instances, and the VL bit rate is 8 Gbps.

[0108] The above-mentioned newly added parameters NumberofSubnet: N (N is an integer greater than or equal to 1), SubnetInfo (including the content L3ProtocolData), and DedicatedOrNot: true / false are included or associated in Step 2. DedicatedOrNot: true / false is optional. If N is 1, it indicates that a new subnet needs to be created. The above-mentioned L3ProtocolData parameters define the information required to create the said subnet, including the IP address type and range, as shown below:

[0109] l3_protocol_data:

[0110] ip_version:ipv4

[0111] ip_allocation_pools:

[0112] -start_ip_address:192.168.10.1

[0113] -end_ip_address:192.168.10.100

[0114] If N is multiple, the number of the SubnetInfo parameter is also N. Since the NumberofSubnet parameter is optional, if the NumberofSubnet parameter is not present, the number of Subnets added is equal to the number of SubnetInfo parameters, with one Subnet added for each SubnetInfo parameter.

[0115] DedicatedOrNot: true / false indicates whether the newly created Subnet must be created with the above

[0116] DedicatedOrNot is set to true in Example 1. This indicates that the newly created subnet must be connected or associated with the newly created VDU. This indicates that the newly created VDU instance does not necessarily need to be associated with a new subnet instance. It can first be associated with an existing subnet instance in the VL. If no suitable subnet instance exists, the new subnet information is associated. In Example 1, the value of DedicatedOrNot is true.

[0117] After receiving the VNF Scale request, the VNFM first locates the corresponding VNFD based on the VNF instance information in the request, such as the VNF instance ID. This VNFD is the expanded VNFD. The VNFM then searches for the VNFD based on the instruction information. Specifically, it searches for and determines the dimension or range of elastic scaling in the VNFD using the Aspect ID included in the instruction information. The VNFM then searches for the VNFD based on the Step information in the instruction information and determines the required scale level and related content. For example, if the Aspect ID in the VNFScale request is ID XXX, the VNFM determines by searching the VNFD that the Aspect corresponding to ID XXX in the VNFD includes VDU_1, VDU_2, and VL. Furthermore, if the Step indication in the VNFScale request is level 2, the VNFM determines by searching the VNFD that level 2 in the example above requires the creation of 6 VDU_1 instances, 8 VDU_2 instances, a VL bit rate of 8 Gbps, and a new Subnet. The specific instantiation parameters are contained in the L3ProtocolData, and the newly created VDU must be associated with the above Subnet. The number of newly created VDUs is the number of VDUs in the corresponding level minus the number of VDUs included in the VNF before scaling. In this example, a total of 6 VDU_1 instances and 8 VDU_2 instances need to be created at level 2. The number of newly created VDU_1 and VDU_2 instances is 6 VDU_1 instances minus the number of VDU_1 instances in the VNF before scaling (for example, 3), and 8 VDU_2 instances minus the number of VDU_2 instances in the existing VNF (for example, 6). The total number of newly created VDU_1 and VDU_2 instances is 3 and 2, respectively. The number of created subnets is determined differently from the VDU creation described above. Number of Subnets: 1 indicates that a new subnet is to be created, regardless of the number of subnets already in the virtual link (VL) of the existing VNF.

[0118] 403. The VNFM sends a Resource Grant request to the NFVO, requesting authorization to create resources, including the VDU instance resource and Subnet resource that need to be created as determined in step 402. For the Subnet resource, the request includes:

[0119] AddResource:

[0120] Type:Subnet

[0121] ResourceTemplateId: VLD (VLD identifier in VNFD)

[0122] L3ProtocolData

[0123] 404. NFVO returns an authorization permission message to VNFM, which carries VIM access information, etc.

[0124] 405. The VNFM applies to the VIM for creating a new subnet instance based on the subnet information determined in step 402. The subnet includes new IP address range or resource pool information. For example, it can be:

[0125] -start_ip_address:192.168.10.1

[0126] -end_ip_address:192.168.10.100

[0127] 406. After the VIM completes the creation of the Subnet, it returns a Subnet instance creation completion notification message and instance information to the VNFM.

[0128] 407. After receiving the Subnet creation completion notification message, the VNFM initiates an authorization request to the NFVO to create a Linkport. The request carries the following information:

[0129] AddResource:

[0130] Type:Linkport

[0131] Subnet instance information

[0132] It indicates that the Linkport to be created is associated with the newly created Subnet instance.

[0133] 408. NFVO sends an authorization permission message to VNFM.

[0134] 409. VNFM initiates the creation of Linkport to VIM, which carries the Subnet instance information that needs to be associated.

[0135] 410. The VNFM applies to the VIM for creating a new VDU instance, carrying the type and quantity of the VDU determined in step 402 above, and the newly created Linkport information.

[0136] 411. After VIM creates the VDU instance, it associates it with the newly created Subnet through the Linkport and the newly created Subnet assigns it an IP address.

[0137] Since parameters such as NumberofSubnet and SubnetInfo are added to the newly defined VNFD in the embodiment of the present invention, a corresponding number of IP addresses can be allocated according to the expansion size (corresponding to different Steps) during expansion, dynamically meeting the address requirements of the newly created VDU. This can avoid the situation in which insufficient IP addresses are allocated when the VNF is expanded in the prior art; it can also avoid the situation in which the prior art directly defines a large IP address resource pool, which ultimately causes waste.

[0138] refer to Figure 5 , Figure 5 This is a flow chart of Example 2. The difference between Example 2 and Example 1 is that the newly created VDU is not necessarily connected or associated with the newly created Subnet.

[0139] The specific implementation steps of Example 2 are described below:

[0140] 501. Same as step 401 in Example 1.

[0141] 502. The difference from step 402 in Example 1 is that in Step 2 defined in VNFD, the value of DedicatedOrNot is false, indicating that the newly added VDU instance does not necessarily have to be associated with the newly created Subnet instance.

[0142] 503-506. Same as steps 403-406 of Example 1.

[0143] 507. Since the value of DedicatedOrNot in Step 2 of the VNFD is false, the new VDU instance does not have to be associated with a new Subnet instance. Therefore, the Linkport authorization request initiated by the VNFM to the NFVO only carries the Linkport information but not the Subnet information. For example, it can be as follows:

[0144] AddResource:

[0145] Type:Linkport

[0146] 508. Same as step 508 in Example 1.

[0147] 509. VNFM applies to VIM for creating a Linkport. If VNFM determines that IP addresses can still be allocated in the Subnet in the original VL network, the newly created Linkport is associated with the existing Subnet information; otherwise, it is associated with the new Subnet information.

[0148] 510. Same as step 410 in Example 1.

[0149] 511. After VIM creates the VDU instance, it is associated with the existing Subnet through Linkport (the Subnet in the original VL network can also be assigned an IP address), and the existing Subnet assigns it an IP address, or it is associated with the newly created Subnet, and the newly created Subnet assigns it an IP address.

[0150] refer to Figure 6 , Figure 6 This is a flowchart of Example 3 of the present invention. Example 3 is the subsequent step of the above-mentioned Example 1 or 2, and describes the process of VNF scaling (Scale In).

[0151] The specific implementation steps of Example 3 are described below:

[0152] 601. NFVO sends a scaling request for the VNF to the VNFM. In this embodiment, it is a scale-in request. The request includes VNF instance information (such as VNF instance ID) and indication information for indicating the range (Aspect) and level (Step) of the scale.

[0153] For example, if the Step of the current VNF ​​is 2, and the Step indication in the indication information is 1, the VNF is scaled down from level 2 to level 1.

[0154] 602. The VNFM receives the VNF Scale request, finds the corresponding VNFD based on the VNF instance information in the request, and queries the VNFD based on the instruction information to determine the VDU and corresponding subnet information to be deleted. In this embodiment, the same VNFD as in Example 1 is used, which still includes the following two levels:

[0155] Step 1: VDU_1 has 3 instances, VDU_2 has 4 instances, and the VL bit rate is 4 Gbps.

[0156] Step 2, VDU_1 has 6 instances, VDU_2 has 8 instances, VL bit rate 8Gbps, NumberofSubnet: 1, L3ProtocolData, DedicatedOrNot: true

[0157] Then, to scale down from level 2 to level 1, VDU_1 needs to reduce 3 instances, VDU_2 needs to reduce 4 instances, and VL needs to delete a subnet (similar to the newly created subnet in Example 1).

[0158] 603. VNFM sends a Grant request to NFVO. The RemoveResource parameter in the Grant request contains the description information of the Subnet resource, Compute resource (corresponding to VDU), and Linkport resource to be deleted.

[0159] 604. The VNFM receives the authorization permission message from the NFVO.

[0160] 605. VNFM applies to VIM to delete the corresponding Subnet resources, the virtual machine resources corresponding to VUD, and the Linkport resources.

[0161] 606. VIM sends a resource deletion success message to VNFM.

[0162] 607. VNFM sends a Scale-In completion message to NFVO.

[0163] The embodiment of the present invention can also be extended to the expansion and contraction scenario of network service (NS). Figure 7 , Figure 7 This is a design example diagram of an NS descriptor (NSD), which mainly includes VNFDs describing VNFs, such as VNFD 1 and VNFD 2 corresponding to VNF_1 and VNF_2 in the figure, NsVld describing the virtual link VL, and descriptors describing the external connection points (ExtCp) of VNFs. VnfExtCP_1 and VnfExtCP_2 in the figure are the external connection points of VNF_1 and VNF_2.

[0164] Examples 1 to 3 above describe scenarios for scaling VNFs. When scaling the NS, the corresponding NSVlds connecting VNF_1 and VNF_2 may also experience insufficient IP addresses. The NS elastic scaling processes described in Examples 4 and 5 below can also address this issue.

[0165] Figure 8 This is a flowchart of NS elastic scaling (Scale) according to Example 4 of the present invention, specifically a Scale Out flowchart. The specific steps of Example 4 are as follows:

[0166] 801. NFVO receives an elastic scaling request for NS (referred to as "NS elastic scaling request") from OSS / BSS. In this embodiment, it is a scale-out request. The request includes NS instance information (such as NS instance ID) and indication information for indicating the scale range (Aspect) and level (Step).

[0167] 802. The NVFO receives the Scale Out request, finds the corresponding NSD based on the NS instance information in the request, and queries the NSD based on the instruction information to determine the VNF to be created and the corresponding subnet information.

[0168] Regarding the content of NSD, this embodiment mainly expands the virtualLinkToLevelMapping information in NsLevel (similar to the virtualLinkBitRateDelta in ScalingDelta of VNFD).

[0169] The expanded virtualLinkToLevelMapping contains the following information:

[0170]

[0171] According to the new extension, NsLevel can define two levels of Step (the following specific numbers are examples):

[0172] Step 1: VNF_1 has 3 instances, VNF_2 has 4 instances, and the VL bit rate is 4 Gbps.

[0173] In Step 2, VNF_1 has 6 instances, VNF_2 has 8 instances, and the VL bit rate is 8 Gbps.

[0174] The above Step 2 also includes or is associated with the newly added parameters NumberofSubnet: N (N is an integer greater than or equal to 1), SubnetInfo (including the content L3ProtocolData), and DedicatedOrNot: true / false. DedicatedOrNot: true / false is optional.

[0175] The meaning of the above-mentioned newly added parameters is the same as that of Examples 1 and 2, and will not be repeated here. In this embodiment, the value of DedicatedOrNot is true.

[0176] After receiving the scale-out request, the NFVO first locates the corresponding NSD based on the NS instance information in the request, such as the NS instance ID. This NSD is the expanded NSD. It then searches the NSD based on the instruction information. Specifically, it searches and determines the scale object or scope in the NSD using the aspect in the instruction information. It then searches the NSD based on the step in the instruction information and determines the required scale level. For example, if the aspect in the VNF scale request includes VNF_1, VNF_2, and VL, and the step is level 2, the VNFM searches the NSD and determines that level 2 in the example above requires the creation of six VNF_1 instances, eight VNF_2 instances, and a VL bit rate of 8 Gbps. It also requires the creation of one new subnet, whose specific instantiation parameters are contained in the L3ProtocolData. The newly created VNF must be associated with the subnet. The number of newly created VNFs is the number of VNFs in the corresponding level minus the number of VNFs included in the VNFs before scaling. In this example, a total of 6 VNF_1 instances and 8 VNF_2 instances need to be created at level 2. The number of newly created VNF_1s and VNF_2s is 6 VNF_1 instances minus the number of VNF_1 instances in the pre-scaling VNF (e.g., 2), and 8 VNF_2 instances minus the number of VNF_2 instances in the existing VNF (e.g., 5). The number of newly created VNF_1s and VNF_2s is 4 and 3, respectively. The number of subnets to be created is determined differently from the above VNF creation. Number of Subnets: 1 indicates that one new subnet is to be created, regardless of the number of subnets already in the virtual link (VL) of the existing VNF.

[0177] 803. Based on the VL information (level 2 information), the NFVO determines that a new subnet needs to be created on the original VL instance, and then applies to the VIM for creating the subnet.

[0178] 804. NFVO sends a VNF instantiation request to VNFM based on the newly created VNF instance, and carries the VL instance information that the VNF needs to connect to (via VnfExtCp_1). Since the value of DedicatedOrNot in the second level of Nslevel definition in NSD is true, the VL instance information also contains the Subnet instance information newly created in step 803.

[0179] 805. Optionally, if step 804 does not contain the Linkport information for the new VNF instance to connect to the Subnet, the VNFM sends a Grant request to the NFVO to authorize the creation of a new Linkport and adds the association information with the Subnet instance in addResource.

[0180] 806. NFVO sends an authorization permission message to VNFM.

[0181] 807.VNFM applies to VIM for creating a Linkport, which contains new Subnet information.

[0182] 808. VNFM applies to VIM for creating a new VNF instance for the VNF instance that needs to be created, and connects it to the Subnet through VnfExtCp_1 and the newly created Linkport.

[0183] 809.VIM completes VNF instance creation by creating a VDU and associates it with the newly created Subnet through Linkport.

[0184] Embodiment 5 of the present invention is the scale-in process in NS elastic scaling, which is similar to the scale-in process of VNF. Figure 9 The specific steps are as follows:

[0185] 901. NFVO receives a scale request for the NS from the OSS / BSS, specifically a scale-in request in this embodiment. The request includes NS instance information (such as the NS instance ID) and indication information for indicating the scale range (Aspect) and level (Step).

[0186] For example, if the Step of the current VNF ​​is 2, and the Step indication in the indication information is 1, the NS is scaled down from level 2 to level 1.

[0187] 902. After receiving the NS Scale In request, the NFVO finds the corresponding NSD based on the NS instance ID in the request and queries the NSD based on the instruction information to determine the VNF to be deleted and the corresponding subnet information. In this embodiment, the same NSD as in Example 4 is used. Its NsLevel can define two levels (steps) (the following specific numbers are examples):

[0188] Step 1: VNF_1 has 3 instances, VNF_2 has 4 instances, and the VL bit rate is 4 Gbps.

[0189] In Step 2, VNF_1 has 6 instances, VNF_2 has 8 instances, and the VL bit rate is 8 Gbps.

[0190] In Step 2 above, the following parameters are added: NumberofSubnet: 1, SubnetInfo (including content L3ProtocolData), and DedicatedOrNot: true / false. DedicatedOrNot: true / false is optional.

[0191] To scale down from level 2 to level 1, VNF_1 needs to reduce 3 instances, VNF_2 needs to reduce 4 instances, and VL needs to delete one subnet.

[0192] 903.NVFO requests VIM to delete the corresponding Subnet resources, the virtual machine resources corresponding to different VDUs included in the VNF, and the Linkport resources.

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

[0194] The actions of NFVO, VNFM or VIM in the above-mentioned method steps can be Figure 4 The processor 401 in the communication device 40 shown calls the application code stored in the memory 403 for execution, and this embodiment does not impose any limitation on this.

[0195] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the interaction between various network elements. It can be understood that in order to realize the above functions, the above NFVO, VNFM or VIM, etc. include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm operations of the various examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0196] In the embodiments of the present application, NFVO, VNFM, or VIM can be divided into functional modules according to the above-mentioned method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into a single processing module. The above-mentioned integrated modules can be implemented in the form of hardware or software functional modules. It should be noted that the division of modules in the embodiments of the present application is illustrative and is only a logical functional division. In actual implementation, other division methods may be used.

[0197] For example, when the functional modules are divided in an integrated manner, Figure 10 FIG2 shows a schematic structural diagram of a communication device 100 , which includes a transceiver module 1001 and a processing module 1002 .

[0198] Exemplarily, the communication device 100 is used to implement the function of VNFM. Figure 4 The embodiment shown, Figure 5 The embodiment shown or Figure 6 The VNFM described in the illustrated embodiment.

[0199] In an embodiment of the present application, the communication device 100 may be a VNFM, or a chip applied to a VNFM, or other combined devices, components, etc. having the above-mentioned VNFM functions. When the communication device 100 is a VNFM, the transceiver module 1001 may be a transceiver, which may include an antenna and a radio frequency circuit, etc., and the processing module 1002 may be a processor (or a processing circuit), such as a baseband processor, which may include one or more CPUs. When the communication device 100 is a component having the above-mentioned VNFM functions, the transceiver module 1001 may be a radio frequency unit, and the processing module 1002 may be a processor (or a processing circuit), such as a baseband processor. When the communication device 100 is a chip system, the transceiver module 1001 may be an input and output interface of a chip (such as a baseband chip), and the processing module 1002 may be a processor (or a 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 the embodiment of the present application can be implemented by a transceiver or a transceiver-related circuit component, and the processing module 1002 can be implemented by a processor or a processor-related circuit component (or, referred to as a processing circuit).

[0200] For example, the transceiver module 1001 can be used to perform Figure 4 In the embodiment shown, all transceiver operations performed by the VNFM, such as S401 and S403, and / or other processes used to support the technology described herein. The processing module 1002 can be used to perform Figure 4In the illustrated embodiment, all operations except the transceiver operations are performed by the VNFM, such as S402 , and / or other processes for supporting the technology described herein.

[0201] For another example, the transceiver module 1001 can be used to execute Figure 6 In the embodiment shown, all transceiver operations performed by the VNFM, such as S601 and S603, and / or other processes used to support the technology described herein. The processing module 1002 can be used to perform Figure 6 In the illustrated embodiment, all operations except the transceiver operations are performed by the VNFM, such as S602 , and / or other processes for supporting the technology described herein.

[0202] When used to implement the VNFM function, for other functions that the communication device 100 can implement, please refer to Figures 4 to 6 , Figure 8 and Figure 9 The relevant introduction of the illustrated embodiment will not be repeated in detail.

[0203] Similarly, the communication device 100 can be used to implement the function of NFVO. Figure 8 The embodiment shown or Figure 9 The NFVO described in the embodiment shown can also be Figures 4 to 6 The NFVO of the illustrated embodiment will not be described in detail.

[0204] In an embodiment of the present application, the communication device 100 may be a VIM, or a chip applied to a VIM, or other combined devices, or components having the above-mentioned VIM functions. When the communication device 100 is a VIM, the transceiver module 1001 may be a transceiver, which may include an antenna and a radio frequency circuit, etc., and the processing module 1002 may be a processor (or a processing circuit), such as a baseband processor, which may include one or more CPUs. When the communication device 100 is a component having the above-mentioned VIM functions, the transceiver module 1001 may be a radio frequency unit, and the processing module 1002 may be a processor (or a processing circuit), such as a baseband processor. When the communication device 100 is a chip system, the transceiver module 1001 may be the input and output interface of the chip (such as a baseband chip), and the processing module 1002 may be the processor (or a 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 the embodiment of the present application can be implemented by a transceiver or a transceiver-related circuit component, and the processing module 1002 can be implemented by a processor or a processor-related circuit component (or, referred to as a processing circuit).

[0205] For example, the transceiver module 1001 can be used to perform Figures 4 to 6 , Figures 8 to 9 In the embodiment shown, all the sending and receiving operations performed by the VIM, the processing module 1002 can be used to perform Figures 4 to 6 , Figures 8 to 9 All operations except for the sending and receiving operations performed by the VIM in the illustrated embodiment, and / or other processes used to support the technology described herein.

[0206] Figure 11 A schematic diagram of the composition of a communication system is shown in FIG. Figure 11 As shown, the communication system 110 may include: NFVO 1101, VNFM 1102 and VIM 1103. It should be noted that, Figure 11 This is only an illustrative figure and the embodiments of this application are not limited to Figure 11 The communication system 110 shown includes network elements and the number of network elements.

[0207] The VNFM 1102 is configured to implement the VNFM functions described in the various embodiments above. For example, the VNFM 1102 may receive elastic scaling request information from the NFVO 1101, query the VNFD based on the request information, determine the VDU and corresponding subnet information to be created, and request the VIM 1103 to create the VDU and corresponding subnet.

[0208] The NFVO 1101 is used to implement the functions of the NFVO in the above-mentioned method embodiments, and the VIM 1103 is used to implement the functions of the VIM in the above-mentioned method embodiments, which will not be described in detail.

[0209] It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding network element of the communication system 110, and will not be repeated here.

[0210] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0212] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0214] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0215] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for elastically scaling a virtualized network function (VNF), characterized in that: The method comprises: The VNFM receives a VNF scale-out request from the NFVO. The request includes VNF instance information and indication information for indicating the aspect and step of the scale. The VNFM determines the VDU to be created and the corresponding subnet information according to the VNF scale-out request; VNFM requests VIM to create a VDU and the corresponding Subnet.

2. The method according to claim 1, characterized in that The VNFM determines the VDU to be created and the corresponding subnet information according to the VNF scale-out request, including: The VNFM finds the corresponding VNFD according to the VNF instance information, and queries the VNFD according to the instruction information to determine the VDU and corresponding subnet information to be created; The VNFD includes Scale Aspect and Step parameter information, and the Scale Step parameter information includes Subnet information.

3. The method according to claim 1 or 2, characterized in that The subnet information includes one or more of the following: the number of subnets, the type and range of IP addresses available for allocation in each subnet.

4. The method according to claim 2, characterized in that The Scale Step parameter information also includes a parameter for indicating whether the created VDU is connected to the Subnet.

5. The method according to claim 4, characterized in that The method further includes the VNFM requesting the VIM to create a link port Linkport, and the VDU is connected to the Subnet through the Linkport.

6. The method according to claim 1, characterized in that The method further comprises: The VNFM receives a VNF scale-in request from the NFVO, where the request includes VNF instance information and indication information for indicating the aspect and step of the scale. The VNFM determines the VDU to be deleted and the corresponding subnet information according to the VNF Scale In request; The VNFM requests the VIM to delete the VDU and the corresponding Subnet.

7. The method according to claim 6, characterized in that The VNFM determines the VDU to be deleted and the corresponding subnet information according to the VNF Scale In request, including: The VNFM finds the corresponding VNFD according to the VNF instance information, and queries the VNFD according to the instruction information to determine the VDU and corresponding subnet information that need to be deleted; The VNFD includes Scale Aspect and Step parameter information, and the Scale Step parameter information includes Subnet information.

8. A method for elastically scaling a network service NS, characterized in that: The method comprises: NFVO receives the NS scale-out request, which includes NS instance information and information indicating the aspect and step of the scale. NFVO determines the VNF to be created and the corresponding subnet information based on the NS scale-out request; NFVO requests VIM to create VNF and corresponding Subnet through VNFM.

9. The method according to claim 8, characterized in that The NFVO determines the VNF to be created and the corresponding subnet information based on the NS scale-out request, including: The VNFM finds the corresponding NSD according to the NS instance information, and queries the NSD according to the instruction information to determine the VNF to be created and the corresponding subnet information; The NSD includes Scale Aspect and Step parameter information, and the Scale Step parameter information includes Subnet information.

10. The method according to claim 8 or 9, characterized in that The subnet information includes one or more of the following: the number of subnets, the type and range of IP addresses available for allocation in each subnet.

11. The method according to claim 9, characterized in that The Scale Step parameter information also includes a parameter for indicating whether the created VNF is connected to the Subnet.

12. The method according to claim 11, characterized in that The method further includes the VNFM requesting the VIM to create a link port Linkport, and the VNF is connected to the Subnet through the Linkport.

13. The method according to claim 8, characterized in that The method further comprises: NFVO receives a NS scale-in request, which includes NS instance information and indication information for indicating the aspect and step of the scale. NFVO determines the VNF to be deleted and the corresponding subnet information based on the NS scale-in request; NFVO requests VIM to delete VNF and the corresponding Subnet through VNFM.

14. The method according to claim 13, characterized in that The NFVO determines the VNF to be deleted and the corresponding subnet information according to the NS scale-in request, including: The VNFM finds the corresponding NSD according to the NS instance information, and queries the NSD according to the instruction information to determine the VNF to be deleted and the corresponding subnet information; The NSD includes Scale Aspect and Step parameter information, and the Scale Step parameter information includes Subnet information.

15. An elastically retractable scale device, characterized in that: Comprising means for executing the method according to any one of claims 1 to 7.

16. An elastically retractable scale device, characterized in that: The device comprises a processor coupled to a memory, wherein a computer program is stored in the memory; the processor is configured to call the computer program in the memory so that the device executes the method according to any one of claims 1 to 7.

17. An elastically retractable scale device, characterized in that: Comprising means for performing the method as claimed in any one of claims 8 to 14.

18. An elastically retractable scale device, characterized in that: The device comprises a processor coupled to a memory, wherein a computer program is stored in the memory; the processor is configured to call the computer program in the memory so that the device executes the method according to any one of claims 8 to 14.

19. An elastic scaling system, characterized in that: The invention comprises an NFVO, a VNFM and a VIM, which are respectively used to implement the steps respectively performed by the NFVO, the VNFM and the VIM in the method of any one of claims 1 to 7 or 8 to 14.

20. A computer-readable storage medium, characterized in that The storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 7 or 8 to 14 is implemented.

Images