KR20170099702A - NFV system and method for managing VNFM - Google Patents

Abstract

An NFV system according to an embodiment of the present invention includes: a VNFM node including a plurality of VNFMs and a VNFM manager for managing the plurality of VNFMs; and a control node including an orchestrator and a virtual infrastructure management unit. Accordingly, the present invention can configure a VNFM arrangement satisfying a framework of an ETSI NFV structure in an NFV system construction.

Description

[0002] NFV system and method for managing VNFM [

The present invention relates to an NFV system and a VNFM management method, and more particularly, to a method for dynamically installing a plurality of VNFMs in an NFV environment conforming to an NFV reference structure defined by an ETSI NFV ISG and controlling VNFs over independent networks .

Network Function Virtualization (NFV) technology separates hardware and software, which is a traditional communication device, by dynamically configuring and operating the network functions implemented in software in a general-purpose cloud infrastructure environment as needed, It is the technology that realizes the infrastructure realization.

Carriers who are burdened with massive investment and maintenance of network infrastructure are expected to provide flexible services to users through NFVs, to avoid dependence on specific network equipment manufacturers, to invest in expensive network equipment (CAPEX: Capital Expenditure) and operating expense (OPEX: Operating Expenditure).

ETSI NFV ISG has developed the requirements specification, framework structure, use case and conceptual verification for NFV. It has been established by the European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group (ISG) And so on.

1 is a view for explaining an NFV reference structure provided in the ETSI standard.

Referring to FIG. 1, the NFV environment includes a network functional virtualization infrastructure (NFVI infrastructure 100, management and orchestration (MANO) 110, a network function 120, an operation support system (OSS) Operation Support System) and a Business Support System (BSS, hereinafter referred to as OSS / BSS) 130.

NFVI 100 refers to a general-purpose cloud infrastructure environment and provides virtual resources for which network functions 120 may be executed. The virtual resources include virtual computing 105, virtual storage 106, and virtual network 107. In addition, the NFVI 100 includes a virtualization layer 104 for virtualizing hardware resources. The hardware resources include the computing hardware 101, the storage hardware 102, and the network hardware 103.

The MANO 110 comprehensively controls and manages the NFV infrastructure environment, the network functions 120 and the network services, and manages a virtualized infrastructure manager (VIM) 111, a plurality of VNFMs 112 and an orchestrator 113). The VIM 111 is responsible for the management and orchestration of the lifecycle of physical and virtual resources. Hereinafter, the VIM 111 is referred to as a virtual infrastructure management unit 111. The plurality of VNFMs 112 manage full-cycle management of the VNFs 121, 123, and 125 that are executed on virtual resources. The orchestrator 113 manages and manages the entire cycle of the service from the viewpoint of the network service.

The network function 120 includes a virtual network function (hereinafter referred to as VNF 121, 123, or 125) implemented and operated in software on the virtual resources 105, 106 and 107 and an element manager Element Manager, hereinafter EM, 122, 124, 126). Therefore, although the VNFs 121, 123, and 125 correspond to the current network equipment, they can be provided as pure software without any dependency on specific hardware because they are executed on the NFVI 100. [

In order to smoothly integrate the existing NFV frameworks (NFVI 100, MANO 110, and network function 120) with existing network infrastructure management areas (non-virtualized dedicated network equipment infrastructure), existing network infrastructure Interworking with an external system such as the OSS / BSS 130 that manages the service may also be considered.

However, the ETSI NFV reference architecture does not show how to arrange and configure each component and network in order to be realized in an actual cloud environment.

2 is a diagram for explaining a technique for separating and configuring a data network and a management network in an open stack-based cloud computing environment.

Referring to FIG. 2, FIG. 2 shows a cloud infrastructure system and network configuration diagram based on OpenStack, which is a cloud management platform based on open software.

The open stack based cloud infrastructure system largely includes compute nodes 211, 212 and 213, a network node 220 and a control node 230.

The compute nodes 211, 212, and 213 are servers in which a plurality of virtual machines 215 through 219 are created and operated through a virtualization solution such as a hypervisor. At this time, the virtual machine 215 is connected to another virtual machine 216 in the same compute node 211, another virtual machine 217, 218, 219 in another compute node 212, 250) to communicate with the data network (262). Also, each of the compute nodes 211, 212, and 213 can share a network interface of the compute node between virtual machines created in the same computer node using a software switch or a bridge. A terminal 250 outside the data center can be used by a user or administrator outside the data center.

The network node 220 provides various network services including a DHCP service, an L3 routing service, a firewall service, a load balancing service, a virtual private network service, and the like, and connects the data network 262 and the external network 261 in the cloud And serves as a gateway. Thus, the network node 220 includes a software switch 221 for connecting the compute nodes 211, 212, 213 and the data network 262. Here, a bridge can be used in place of the switch, and the same applies to the following. The virtual machines 215 to 219 are connected to the virtual routers 222 and 223 that provide the L3 routing service through the switch 221. [ When data traffic sent from the virtual machine 215 is directed outwardly, the data traffic passes through the switch 221 of the network node 220 through the virtual machine 215 to other software switches connected to the virtual routers 222 and 223 And is transmitted to the external network 261 through the network 224. Thus, the virtual machine 215 can communicate with the terminal 250 outside the data center through the gateway 240 of the data center.

The control node 230 is a server in which an open stack cloud management platform is installed and operated. The control node 230 receives the REST message for control / management from the terminal 250 outside the data center through the external network 261 and transmits the REST message to the compute nodes 211, 212 and 213 and the network node 220 Management command via a separate management network 263 connected to the control network.

In order to build an open stack-based NFV platform, it is necessary to deploy the VNFM and configure the management network with the VNF without changing the configuration of the existing cloud infrastructure system and network.

Accordingly, it is an object of the present invention to provide a method for effectively managing VNFM and VNFM and VNFM management networks in an NFV system conforming to the ETSI NFV reference structure.

The NFV system according to an embodiment of the present invention includes a plurality of VNFMs, a VNFM managing the plurality of VNFMs, a VNFM management network, and a VNFM for additionally installing a VNFM for managing the VNFs, And a VNFM node including an administrator.

The VNFM manager configures a VNF management network. If the VNFM to manage the VNF is not installed, the VNFM manager further installs the VNFM to manage the VNF.

The VNF management network may be configured for each VNFM or each VNF.

The VNFM node is connected to the orchestrator through an external network.

A network for connecting the plurality of VNFMs to the virtual infrastructure management unit, a network for connecting the VNF to the external terminal, and a network for managing each VNF are independently configured.

A method of managing a VNFM according to an exemplary embodiment of the present invention includes receiving a request for registration of a new VNF package; Confirming whether a VNFM for managing the VNF package is installed; Storing information of the VNFM in the VNF package information if the VNFM is installed; And installing a new VNFM if it is not installed.

The VNFM management method includes: receiving a request for creating a network service instance; The orchestrator requesting the VNFM to create a VNF instance; Determining expansion or contraction of the VNFM according to the policy of the VNFM manager; If the VNFM needs to be extended, installing additional VNFM; Returning the information of the installed VNFM to the orchestrator and re-requesting the installed VNFM to create the VNF instance; And allocating virtual resources for the VNF.

Querying the VNF management network information if it is not necessary to extend the VNFM; And allocating a virtual resource for the VNF including the VNF management network information.

Further comprising, before the orchestrator requests the VNFM to create the VNF instance, the orchestrator queries the VNFM manager if the VNFM extension is required.

Further comprising the step of the orchestrator requesting the VNFM to create the VNF instance, wherein the orchestrator confirms the existence and possibility of creation of the same VNF through the VNFM.

The orchestrator further includes a step of preferentially generating a virtual machine in which the VNF can be executed by inquiring VNF generation information.

Forwarding command information for the VNF to the VNFM when the orchestrator controls the VNF; And the VNFM verifying the command information and then controlling the VNF via the VNF management network.

According to the present invention, a VNFM arrangement satisfying a framework of an ETSI NFV structure can be configured when an NFV system is constructed in an existing open-stack based cloud environment.

Accordingly, a management network with a VNF with independence can be configured.

Specifically, the VNFM can not directly connect and manage the VNF using the management network with the orchestrator and the VIM. If a public IP address is assigned to each VNF, the VNFM can manage the VNF through the data network. However, in this case, the finite nature of the public IP address and the security of the network sharing the VNF data traffic exist.

Therefore, according to the present invention, it is possible to configure an independent VNF management network separated from the data network without addition of a network interface device for configuring the VNF management network to a server where a resource is wasted such as additional public IP address assignment or a virtual machine is created And it is possible to effectively operate heterogeneous plural VNFMs simultaneously in one NFV system.

1 is a view for explaining an NFV reference structure provided in the ETSI standard.
2 is a diagram for explaining a technique for separating and configuring a data network and a management network in an open stack-based cloud computing environment.
3 is a diagram illustrating a VNFM manager according to an embodiment of the present invention.
4A and 4B are views for explaining an NFV system and a network configuration diagram according to an embodiment of the present invention.
5A and 5B are diagrams illustrating an example of a network configuration diagram according to an embodiment of the present invention.
6 is a view for explaining a method of installing a VNFM according to an embodiment of the present invention.
7A and 7B are views illustrating a method of configuring a VNF management network and a method of controlling a VNFM extension according to an embodiment of the present invention.
8 is a view for explaining a method of generating a VNF through a VNF management network according to an embodiment of the present invention.
9 is a view for explaining a VNF control method through a VNF management network according to an embodiment of the present invention.

While the present invention has been described in connection with certain exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and similarities. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

In addition, the singular phrases used in the present specification and claims should be interpreted generally to mean "one or more " unless otherwise stated.

The VNFM, which is responsible for full-cycle management, status monitoring, fault management, software installation and configuration management of VNF running on virtual resources, must ensure network reachability with VNF for control / management. In addition, a data network for communication with any node located outside the other VNF or NFVI in the VNF and a management network for controlling / managing the VNF must be separated from each other in terms of security.

In addition, according to the conventional NFV reference structure, when one VIM manages a virtual infrastructure for a plurality of locally distributed NFVIs and only one center orchestrator is responsible for the entire service orchestration, It is also unclear as to whether to locate each VIM or only one with a central orchestrator.

Therefore, effective VNFM deployment and VNF management network configuration method that can provide isolated VNF management network in NFV system construction and operation, and how to effectively install and operate VNFM need to be presented.

As shown in FIG. 2, the data center can not be directly connected to the external network, but can only access the data network through the network node or access the management network through the control node. Also, the control node can not directly access the inside of the virtual machine through the management network unless a separate configuration is provided. Unless the virtual machine also provides a separate configuration, it can not access the management area of the network node or control node through the data network.

Also, when the control node accesses the inside of the virtual machine, a public IP address (called Floating IP in the open stack) is given to the virtual machine to be accessed, and the virtual machine is accessed using the IP address as the destination address. At this time, the path that the IP packet accesses is not in the management network but in the order of the external network, the network node, the data network, and the virtual machine.

Therefore, the problem of security and stability of messages for control / management commands caused by data traffic passing through an external network and a network node must be resolved. Since a public IP address must be assigned to a virtual machine, The limitations of scalability also need to be addressed.

In other words, in order to build the NFV platform on the open stack VIM, a method of arranging the VNFM without changing the existing open stack cloud network configuration and configuring the management network with the VNF corresponding to the virtual machine needs to be proposed . Therefore, one embodiment of the present invention for solving the problem will be described in detail with reference to FIG. 3 to FIG.

3 is a diagram illustrating a VNFM manager according to an embodiment of the present invention.

According to the ETSI NFV structure framework, multiple VNFs can be generated and operated in an NFV system. At this time, each VNF is managed by one VNFM, and the VNFM can manage a plurality of VNFs at the same time. Therefore, a plurality of heterogeneous VNFMs are efficiently managed, and a VNFM manager must be configured and managed to effectively manage VNFMs.

3, the VNFM manager 300 includes a VNFM package management unit 301, a VNFM installation / configuration management unit 302, and a VNFM failure management unit 303.

The VNFM package management unit 301 registers, stores, searches, extracts, updates, and deletes the VNFM software used in the NFV system. Accordingly, all the VNFM software installed and used in the NFV system is managed by the VNFM package management unit 301. [

The VNFM installation / configuration management unit 302 uses the VNFM software to install the VNFM on a server that requires installation and operation of an actual VNFM. The VNFM installation / configuration management unit 302 configures and manages a VNF management network for controlling / managing the VNFs to be managed. In addition, the VNFM installation / configuration management unit 302 delivers the VNF management network configuration and connection information that the VNF can access. When the number of VNFs managed by the VNFM exceeds a predetermined value or the performance of the VNFM deteriorates, the VNFM installation / configuration management unit 302 performs an extension control (scale-in / out) for additionally installing the VNFM. Accordingly, the VNFM installation / configuration management unit 302 can distribute the load to the same VNFM.

The VNFM failure management unit 303 detects the occurrence of a failure of the VNFM software. When a failure occurs, the VNFM failure management unit 303 notifies the orchestrator 113 or the manager of the failure occurrence information, and performs a failure recovery function to reinstall the VNFM.

The VNFM manager 300 may be provided as part of the functions of the orchestrator 113. The VNFM manager 300 may be installed on the same server as the orchestrator 113 or the VNFM, or may be installed and operated on a separate server. In addition, each detailed function of the VNFM manager 300 can be distributed over a plurality of servers. Of course, the functions are not necessarily limited to being installed in a specific physical server, but are intended to effectively describe the configuration of the system and the network. The same applies to the remaining drawings.

4A and 4B are views for explaining an NFV system and a network configuration diagram according to an embodiment of the present invention.

4A and 4B illustrate a system and a network configuration diagram for installing and configuring the VNFM when the NFVI and the VIM are constructed using the system and network diagram in the open-stack-based cloud computing environment of FIG. 2 . Therefore, the description overlapping with FIG. 2 will be omitted and differences will be mainly described.

4A illustrates a case where the NFV MANO is located in a single data center. That is, NFVI and MANO are located in one domain.

The NFV system includes compute nodes 211, 212 and 213, a network node 220, a control node 230 and a VNFM node 400.

The control node 230 includes a virtual infrastructure management unit 111 and an orchestrator 113.

The VNFM node 400 includes a VNFM manager 300 and a plurality of VNFMs 401, 402, and 403. The VNFM node 400 may be a server independent of the compute nodes 211, 212 and 213, the network node 220 and the control node 230.

The plurality of VNFMs 401, 402, and 403 may be implemented in a virtual machine, a container type, or a Linux namespace, thereby constituting an isolated environment.

The VNFM node 400 is connected to the data network 262 and the management network 263. Here, the data network 262 is used as a management network for the VNFMs 401, 402, and 403 to control the VNFs. However, the management network for controlling the VNF should be separated from the data network for virtual machine communication through network virtualization. Therefore, unlike a general open stack cloud environment, a virtual machine 424 for controlling the VNFM as well as a virtual interface 426 for a data network of a virtual machine must be independently generated in a virtual machine in the NFV system. In the following, the virtual interface 426 for the data network of the virtual machine is used as the VNF data network 426, and the virtual interface 424 for control with the VNFM is used as the VNF management network 424.

For example, the data network 262 for data communication of a virtual machine is defined as a tenant network to which the virtual machine belongs. On the other hand, the management network 424 with the VNFM is defined as an independent management tenant. Thus, the network interface of two different tenants can be connected to the virtual machine, and a different network environment can be logically separated although it is physically one network environment.

The VNF management network 424 and the VNF data network 426 are created in the VNF created in the virtual machine or the virtual machine. Thus, the L3 gateway of the VNF management network 424 is each VNFM 401, 402, 403 generated in the VNFM node 400 while the L3 gateway of the VNF data network 426 is in the network node 220 And become virtual routers 222 and 223 to be generated. Accordingly, the VNF data network 426 and the VNF management network 424 can not be routed or connected with each other.

Similarly, a switch 410 for transmitting / receiving a control / management message from the orchestrator 113 and the virtual infrastructure management unit 111, a switch 420 for controlling the network 412 and the VNF, The network 422 must be configured separately. At this time, the VNFM manager 300 configures a plurality of VNFMs 401, 402, and 403 through the networks 410 and 412, and can manage the update or failure of the VNFM software.

4B is a view for explaining a case where the orchestrator 113 is outside the data center, as compared with FIG. 4A.

Data centers can be geographically distributed. In this case, the virtual infrastructure management unit 111 and the VNFM may be located in each data center, and the orchestrator 113 may manage the wide area and collectively manage the plurality of data centers. 4A, the VNFM node 400 must be connected to the external network 261 for the interface between the orchestrator 113 and the VNFM.

In addition, in order to ensure the validity and security of the control / management message, the VNFM manager 300 additionally has to perform validity, authentication, and authority checking on all received messages. In order to ensure the validity and security of the control / Or deliver it to the plurality of VNFMs 401, 402, 403.

Accordingly, the plurality of VNFMs 401, 402, and 403 includes a network 261, 430, and 432 for communicating with the orchestrator 113, a management network 263 for communicating control / management messages with the virtual infrastructure management unit 111 410, and 412), and interfaces defined in the ETSI NFV structure framework through the management networks 262, 420, 422, and 424 for controlling the respective VNFs operating on the virtual machine.

In FIGS. 5A and 5B, a detailed description of how the virtual network is configured in the virtual machine and the VNFM in which the VNF is operated will be described in detail by allocating an IP address to each port.

5A and 5B are diagrams illustrating an example of a network configuration diagram according to an embodiment of the present invention.

5A and 5B illustrate the allocation of IPs according to the NFV system and the network configuration of FIG. 4A, as shown in Table 1. FIG.

[Table 1]

5A, assuming that there are three data networks 262 and 426 for data communication in the virtual machine (10.10.0.0/24, 10.20.0.0/24, 20.0.0.0/24), each gateway port 10.10.0.1 and 10.20.0.1 are located in the first virtual router 222 and 20.0.0.1 is located in the second virtual router 223. [

At this time, the VNF management networks 262, 422, and 424 of the VNFM for controlling the VNFs are created for each of the VNFMs 401, 402, and 403. Each of which is a network of 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 for each of the VNFMs 401, 402 and 403 and a VNFM (401, 402, 403) The IPs assigned to the IP addresses are 192.168.1.1, 192.168.2.1, and 192.168.3.1, respectively. As described above, the VNFMs 401, 402, and 403 can manage the virtual machines 215 to 219 by assigning IPs to the respective networks.

5B is a view for explaining an example of configuring a VNF management network by VNF, unlike FIG. 5A. 5A illustrates a VNF management network for each VNFM, while FIG. 5B illustrates a VNF management network for each VNF.

The VNF management networks 262, 422 and 424 may be created for each VNF or for each VNFM. If all the virtual machines and the VNF are owned by the same user or there is no security problem, ) Is convenient for each VNFM.

However, a plurality of VNFs managed by the same VNFM can be generated and operated at the request of another user, respectively. Because security between users is important in a multi-tenancy or NFV environment, such as a typical cloud environment, VNF must be strictly blocked from direct access through a virtual network. Therefore, access through the VNF management network should also be strictly isolated.

5A, a problem that the security between users may become weak will be described.

For example, it is assumed that virtual machine A 215 and virtual machine E 219 are VNFs created and operated by different user groups. In this case, the data networks 10.10.0.0/24 and 20.0.0.0/24 are isolated from each other, but the VNF management network 192.168.1.0/24 is shared. Therefore, there is a possibility that a malicious user can access another virtual machine through the VNF management network. Therefore, when high security is required, it is necessary to block the malicious user in advance.

Accordingly, in this case, as shown in FIG. 5B, one VNF management network per VNF may be configured instead of one VNF management network per VNFM so that access between the virtual machines via the VNF management network may be strictly blocked.

Although not shown in FIG. 5A, even if one VNF management network is configured per VNFM in FIG. 5A, a filtering rule (for example, iptables in Linux) blocking all packets other than packets transmitted from the VNFM to the network interface of the VNF The security can be enhanced.

6 is a view for explaining a method of installing a VNFM according to an embodiment of the present invention.

Referring to FIG. 6, a new VNF package on-boarding is requested in step S600.

In step S610, the orchestrator checks whether a VNFM to manage the VNF package to be registered is installed.

If the VNFM is not installed, the VNFM manager installs the VNFM through the VNFM installation / configuration management unit in step S620. At this time, the VNFM installation / configuration management unit receives the VNFM software including the VNFM installation program through the VNFM package management unit. However, the VNFM installation program must be registered in the VNFM package management section in advance. In addition, the VNFM installation / configuration management unit transmits information about the installed VNFM to the orchestrator so that the information of the VNFM installed in the orchestrator can be managed.

In step S630, if the VNFM is installed, the VNFM information (VNFM ID, Endpoint URL (IP address, port number) for accessing VNFM from NFVO, etc.) is stored in the VNF package information to be registered.

7A And FIG. 7B are views illustrating a method of configuring a VNF management network and a method of controlling a VNFM extension according to an exemplary embodiment of the present invention. 7A and 7B illustrate a scale-in / out example for additionally generating / deleting a VNFM process or a virtual machine in which a VNFM is operated in the VNFM extension control. In addition, a virtual- Scale-up / down for adding / removing virtual resources allocated to a machine may also be considered in the present invention.

Specifically, FIGS. 7A and 7B are diagrams for explaining a method of controlling VNFM extension when generating a VNF, and a case of generating a network service instance will be described as an example. 7A and 7B illustrate a VNFM extension control and a VNF management network configuration method through the VNFM manager according to an implementation method. It should be appreciated that in the case of modification and deletion as well as creation of the network service instance, it can be fully understood through Figs. 7A and 7B.

7A illustrates a case where an extended control request of the VNFM occurs in the VNF management network information inquiry step.

In step S700, the orchestrator 113 is requested to create a network service instance.

In step S701, the orchestrator 113 confirms the information of each VNF constituting the network service, and then requests the VNFM 112 to create the VNF instance. At this time, the VNFM is determined according to the VNFM information per VNF determined at the time of registering the VNF package. In addition, the VNFM 112 can inquire the VNFM manager 300 about various information for generating a VNF such as VNF management network information that should be generated together with the VNF when generating the VNF.

In step S702, the VNFM manager 300 determines whether to extend the VNFM 112. [ Specifically, the VNFM manager 300 can determine whether to expand / reduce the VNFM 112 based on the number of instances of the VNF managed by the VNFM 112 or the performance index according to the monitoring result of the VNFM based on the policy information.

If the extension control for the VNFM is unnecessary, in step S703, the VNFM manager 300 newly creates the VNF management network or inquires the created network information and transmits it to the VNFM 112. [

If the VNFM is to be additionally generated and operated, in step S704, the VNFM installation / configuration management unit further installs the VNFM 112. [ Thereafter, step S701 may be performed again. At this time, the VNFM manager returns the information (VNFM ID, VNFM Endpoint URL, etc.) of the newly added VNFM 112 to the orchestrator 113. Thus, the orchestrator 113 can re-request the VNF instance creation with the new VNFM 112. In addition, a load balancer for distributing the load of the VNFM 112 may be provided to the VNFM 112 determined to be expanded. At this time, the VNFM connection information (Endpoint URL) may be a virtual IP of the load balancing system. In this case, the extension control procedure can be terminated by the load balancing system registering the new VNFM 112 as a member without a procedure for re-requesting the orchestrator 113 to create a new VNFM 112 with the new VNFM 112.

In step S705, the VNFM requests the orchestrator 112 to allocate a virtual resource for the VNF including the VNF management network information.

In step S706, the orchestrator requests the virtual infrastructure management unit to create the virtual infrastructure with respect to the requested virtual resource, and the result is returned.

When the creation of the virtual infrastructure is completed, in step S707, the orchestrator informs the VNFM that the resource is allocated to the VNF, and provides the IP address or the like allocated to the VNF.

In addition, the VNFM can perform additional tasks such as installing additional software, configuring the service or setting the service to provide the service to the VNF through the VNF management network. The VNFM may then notify the orchestrator of the results of the further work.

If the orchestrator confirms the generation of the VNF, the orchestrator may proceed to set up a network forwarding path and finish the network service instance creation request procedure in step S708.

In one embodiment, if the VNFM is delegated authority to control virtual resources in the VIM directly from the orchestrator, or if the system environment is configured to do so, the VNFM requests creation via the virtual infrastructure manager directly without the intervention of the orchestrator And return the results.

FIG. 7B illustrates a case where an extension control request of the VNFM proceeds through the VNFM manager before the VNF instance creation request. The same parts as those of FIG. 7A are omitted and the differences are mainly described.

In step S710, the orchestrator is requested to create a network service instance.

In step S711, the orchestrator inquires of the VNFM installation / configuration management unit of the VNFM manager whether expansion control of the VNFM is necessary. 7A, since the orchestrator knows the information of the VNF managed by the VNFM, it is more efficient than the method of FIG. 7A. In particular, it is more efficient when the VNFM manager is developed as part of an orchestrator.

If the VNFM extension control is required, the extension control for the VNFM proceeds in step S712. The VNFM manager passes the connection information (VNFM ID, Endpoint URL, etc.) to the extended VNFM to the orchestrator.

When the VNFM access information for each VNF is confirmed, in step S713, the orchestrator requests to create a VNF instance for each VNFM. At this time, the VNFM is determined according to the VNFM information per VNF determined at the time of registering the VNF package. In step S714, the VNFM can inquire the VFNM manager about various information for generating VNFs such as VNF management network information that should be generated at the time of VNF creation. Hereinafter, the description of the steps S715 to 718 is omitted since it is the same as the step S705 to the step S708 in Fig. 7A.

8 is a view for explaining a method of generating a VNF through a VNF management network according to an embodiment of the present invention.

Referring to FIG. 8, upon receipt of a request for VNF generation, the orchestrator confirms existence of the same VNF, possibility of generation, and the like through the VNFM in step S800.

In step S810, the orchestrator transmits the VNF generation information to the virtual infrastructure management section to preferentially create a virtual machine in which the VNF can be executed. Here, the VNF generation information is received from the VNFM or is directly inquired by the orchestrator in the database or the like. In addition, the VNF generation information may include specification information of the virtual machine (e.g., the number of CPUs, memory size, disk size, and other virtual resource requirements), virtual network information to be connected to the virtual machine (E.g., network information, subnet information, CIDR, IP address information, or DHCP), and VNF management network information (e.g., VNF management network interface information, management network information, subnet information, etc.).

When a virtual machine to be operated by the VNF is created through the virtual infrastructure management unit, the virtual infrastructure management unit delivers information related to the virtual machine creation to the VNFM in step S820. At this time, the virtual infrastructure management unit can transmit information related to the virtual machine creation to the VNFM via the orchestrator. At this time, the information related to the creation of the virtual machine may include an identifier (ID) for managing the VNF, creation information of the network interface created in the virtual machine (IP address such as a network endpoint URL for VNF management), and the like.

In step S830, the VNFM having received the information related to the virtual machine creation can store information of the received VNF in the database in order to manage the VNF itself. The database can be located inside the virtual machine for VNFM, and managed by the VNFM in the VNFM node or as a public database.

In step S840, the VNFM may connect to the VNF endpoint URL via the VNF management network to install additional required VNF-related software in the virtual machine, or perform subsequent tasks such as environment setting.

9 is a view for explaining a VNF control method through a VNF management network according to an embodiment of the present invention.

Referring to FIG. 9, in step S900, the orchestrator transmits a control / management command for the VNF to the VNFM. Specifically, the orchestrator is configured to perform control / management commands such as full-cycle management, scale-in / out, state management, performance and fault management for a particular VNF or network service to which a particular VNF belongs, Including the VNF identifier information and the executed control / management command information, to the VNF.

In step S910, the VNFM verifies the validity, authentication and authority information of the message for the received control / management command, and inquires the VNF management information corresponding to the VNF identifier from the database only for valid commands.

In step S920, the VNFM transmits or executes a control / management command to the VNF through the VNF management network using the VNF endpoint URL information, which is one of the VNF management information.

In the case of a message transmitted from the VNF to the VNFM, such as a failure notification, the process proceeds in the reverse order. When a failure notification event occurs in the VNF, the VNF delivers the corresponding event information to the VNFM. Then, the VNFM inquires the identifier of the VNF based on the transmitting side IP address information, processes the event according to the policy stored in the VNF management information, or transmits the VNF identifier and the event occurrence information to the orchestrator. Therefore, the installation, setting, and control commands of the VNF can be efficiently processed.

The embodiments of the present invention have been described above. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

111: Orchestrator
113: Virtual Infrastructure Management Section
300: VNFM Manager

Claims (1)

A plurality of VNFMs and a VNFM manager including a VNFM manager for managing the plurality of VNFMs and constituting a VNF management network and installing a VNFM for managing the VNFs if the VNFMs for managing the VNFs are not installed,
≪ / RTI >

Images