KR102623631B1 - Method for automatically configuring virtualized network function, and network function virtualization management and orchestration for the same - Google Patents

Abstract

A method of performing automatic configuration of a VNF on an NFV system and an NFV MANO structure for the same are disclosed. The method for automatically setting up a VNF includes: receiving, by an NFVO, a registration request for first automation information for setting up a first VNF managed by the first VNFM from a first VNFM; NFVO receiving a registration request for second automation information for setting up a second VNF managed by the second VNFM from the second VNFM; And the NFVO mediates between the first VNFM and the second VNFM the exchange of information necessary to set up the first VNF and the second VNF based on the first automation information and the second automation information, and the first automation Each of the information and the second automation information may be configured to define the internal government required for setting the first VNF and the second VNF, information to be received from the outside, and information to be provided to the outside.

Description

Method for automatically configuring VNFs in an NFV environment and NFV MANO{Method for automatically configuring virtualized network function, and network function virtualization management and orchestration for the same}

The present invention relates to Network Function Virtualization (NFV) technology, and more specifically, to a method of automatically setting up a virtualized network function (VNF) in an NFV environment and an NFV MANO (Management) method for this. and Orchestration) It is about the structure of components.

Interest in network function virtualization (NFV) technology, which virtualizes physical network equipment on a general server, is increasing. Meanwhile, unlike when using existing physical equipment, in an NFV environment, network functions are operated using cloud resources, so the ability to manage and control them is important.

MANO (Management and Orchestration) on the NFV architecture defined by ETSI operates the NFV Orchestrator (NFVO: NFV Orchestrator), multiple virtual network function managers (VNFM: VNF Manager) provided by each VNF manufacturer, and NFVI (NFV Infrastructure). It consists of a virtual infrastructure manager (VIM: Virtual Infrastructure Manager) that Here, VIM performs a similar function to that of Cloud OS (or cloud management platform) that manages and controls the cloud center.

However, when a network service is composed of multiple VNFs produced by different vendors, and these VNFs are managed by different VNFMs, changes to the settings of one VNF may affect the settings of other VNFs. It can be. However, there is no method or structure for automatically changing the settings of VNFs managed by different VNFMs.

The purpose of the present invention to solve the above problems is to provide a VNF automatic configuration method that enables automatic configuration of VNFs by automatically exchanging information between VNFs belonging to heterogeneous VNFMs in an NFV environment.

In addition, another purpose of the present invention to solve the above problems is to provide an NFV for automatic configuration of VNFs, which enables automatic configuration of VNFs by automatically exchanging information between VNFs belonging to heterogeneous VNFMs in an NFV environment. It provides the structure of MANO.

The present invention to achieve the above object is a method of automatically setting a virtualized network function (VNF) on a network function virtualization (NFV) system, using an NFV orchestrator (NFVO: NFV Orchestrator) Receiving a registration request for first automation information for setting a first VNF managed by the first VNFM from a first virtualization network function manager (VNFM); The NFVO receiving a registration request for second automation information for setting a second VNF managed by the second VNFM from a second VNFM; and the NFVO mediating the exchange of information necessary to set up the first VNF and the second VNF between the first VNFM and the second VNFM, based on the first automation information and the second automation information. Includes, wherein the first automation information and the second automation information each define the internal government required for setting the first VNF and the second VNF, information to be received from the outside, and information to be provided to the outside. Provides a method for automatically setting up a VNF in an NFV environment.

The present invention for achieving the above other object is a structure of an NFV MANO that performs automatic configuration of VNFs on an NFV system, and an NFVO that receives registration requests for automation information for configuration of VNFs managed by each VNFM from VNFMs. ; and VNFMs that transmit to the NFVO a request to register automation information for setting up the VNFs they each manage, and the NVFO serves to mediate the exchange of information necessary for setting up the VNFs between the VNFMs, The automation information defines the structure of the NFV MANO for automatic configuration of the VNF in the NFV environment, characterized in that it defines the internal information required for setting up each VNF, information to be received from the outside, and information to be provided to the outside. to provide.

As described above, when using the VNF automatic configuration method and the NFV MANO structure for this according to embodiments of the present invention, when creating/modifying/deleting a network service in an NFV environment, the settings of the VNFs constituting the corresponding network service must be set. It is performed automatically, enabling quick and efficient service management.

Figure 1 is a block diagram for explaining the ETSI NFV architecture to which the VNF automatic configuration method according to the present invention is applied.
Figure 2 is a conceptual diagram to explain the interface between VNF and VNFM.
Figure 3 is a conceptual diagram to explain problems in VNF settings when a network service is configured with a combination of VNFs provided by different vendors, which is the background of the present invention.
Figure 4 is a conceptual diagram for explaining the structure of an NFV MANO according to an embodiment of the present invention.
Figure 5 is a conceptual diagram to explain how information is exchanged between VNFMs for automatic VNF configuration on an NFV MANO according to an embodiment of the present invention.
Figure 6 is a block diagram for explaining automation information according to an embodiment of the present invention.
Figure 7 is a conceptual diagram to explain the initial instance creation process in the VNF automatic configuration method according to an embodiment of the present invention.
Figure 8 is a conceptual diagram to explain in more detail the event processing procedure after going through the initial instance creation process in the VNF automatic configuration method according to an embodiment of the present invention.

Since the present invention can make various changes and have various embodiments, specific embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all changes, equivalents, and substitutes included in the spirit and technical scope of the present invention. While describing each drawing, similar reference numerals are used for similar components.

Terms such as first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, a first component may be named a second component, and similarly, the second component may also be named a first component without departing from the scope of the present invention. The term and/or includes any of a plurality of related stated items or a combination of a plurality of related stated items.

When a component is said to be "connected" or "connected" to another component, it is understood that it may be directly connected to or connected to the other component, but that other components may exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between.

The terms used in this application are only used to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this application, terms such as “comprise” or “have” are intended to designate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, but are not intended to indicate the presence of one or more other features. It should be understood that this does not exclude in advance the possibility of the existence or addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the technical field to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and unless explicitly defined in the present application, should not be interpreted in an ideal or excessively formal sense. No.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings.

Figure 1 is a block diagram for explaining the ETSI NFV architecture to which the VNF automatic configuration method according to the present invention is applied.

Referring to Figure 1, the NFV architecture presented by ETSI may be configured to include a virtualized network function (VNF: 120) and a network function virtualization infrastructure (NFVI: Network Function Virtualization Infrastructure: 140). .

Here, OSS (Operations Support System) is a system to support the operator's network operation and provision and maintenance of customer service, and BSS (Business Support System) is for customer billing and customer relationship management (CRM: Customer Service). Relationship Management), a system that supports call center task automation, etc.

There may be at least one VNF instance (121-1, ..., 121-N) on the VNF (120), and an Element Management (EM) 122-1, ..., 122-N corresponding to each of these. ) may exist. On the NVFI (140), there will be actual physical hardware (145, 146, 147), a virtualization layer (144) that virtualizes the actual physical hardware resources, and virtualization resources (141, 142, 143) virtualized by the virtualization layer (144). You can.

Meanwhile, in the NFV environment, network functions are operated using cloud resources, so the ability to manage and control them is important. Therefore, in the ETSI NFV architecture, there may be an NFV Management and Orchestration (MANO) component (MANO) 150 to manage and coordinate the components.

MANO 150 manages virtual resources (computing resource, network resource, storage resource) and performs the role of orchestrating virtual resources. Therefore, it is responsible for checking the availability of virtual resources for network services composed of multiple VNFs, responsible for actual distribution, and configuring the distribution order and related information between VNFs for successful service initiation to successfully deploy various NFVIs. It must be passed on.

Within the MANO (150), there is an orchestrator (151) that coordinates the overall operation, a virtualization network function manager (VNFM: 152) that manages the VNF (120), and a virtualization infrastructure that manages the NFVI (140). A virtualized infrastructure manager (VIM: 153) may exist.

The role of the VNFM (152) is to perform lifecycle management of VNFs between the orchestrator (151), which manages VNFs, virtual resources, and services. In particular, the VNFM 152 manages the relationship between virtual resources and VNFs in a cloud environment and performs the function of maintaining and optimizing the continuity of services provided by VNFs by immediately responding to events or state changes that occur between them. do. Within the MANO 150, there may be multiple VNFMs provided by each VNF manufacturer.

NFVI refers to the hardware and software elements that constitute the environment in which VNF can be performed, and VIM is an administrator who plays a role in managing and controlling them in an integrated manner. and provides a unique application program interface.

NFVI has a virtualized infrastructure manager (VIM) and a reference point Nf-Vi, and has a VNF and Vn-Nf reference architecture. VIM 153 is similar to the function of Cloud OS (or Cloud Management Platform) that manages and controls the cloud center.

Figure 2 is a conceptual diagram to explain the interface between VNF and VNFM.

In an NFV environment, VNF instances can be installed or deleted at any time as needed. At this time, VNF instances can be installed/edited/deleted through the VNFM provided by each vendor.

Referring to FIG. 2, the interface 211 for initial configuration required for this procedure and the interface 212 for performing configuration changes are a standard interface ( For example, it may be defined as ETSI GS NFV-IFAA008).

Meanwhile, Openstack/OPNFV, a representative Cloud OS considered as a VIM, provides a metadata service function for initial setup, but for modification during operation, a separate agent must be installed on the VNF or CLI (Command-Line Interface) on the VNFM. It must be operated by adding the base configuration technology (e.g. juju, Puppet). However, these functions do not provide the ability to receive or provide information about VNF instances managed by another vendor's VNFM, and do not provide the function to automatically process information from other VNFs when it is necessary for VNF settings.

Figure 3 is a conceptual diagram to explain problems in VNF settings when a network service is configured with a combination of VNFs provided by different vendors, which is the background of the present invention.

Referring to FIG. 3, let us consider the case where, in a network service composed of multiple VNFs, each VNF is a product of a different vendor and is managed by a different VNFM.

For example, the provided network service 300 is composed of a combination of the first VNF 310 and the second VNF 320, and the first VNF 310 is a load balancer that appropriately distributes the load of the servers according to the load of the servers. It is assumed that the second VNF 320 performs the function of a server connected to the load balancer of the first VNF 310. Additionally, they are connected by a virtual link (VL3) and are managed by different VNFMs (eg, a first VNFM and a second VNFM; not shown in FIG. 3).

In the illustrated configuration of FIG. 3, the IP addresses of servers indicated as the second VNF 320 are required to set up the load balancer of the first VNF 310. Generally, the IP address is determined each time an instance of the second VNF 320 is created, so when the network service 300 is created for the first time, the second VNF 320 is created first and the IP address is easily found. Information can be passed to the first VNFM that creates/manages the first VNF (310).

However, in the case where an instance of the second VNF is added/deleted/changed during operation of the network service 300, the information transmission method and function for automatically changing the settings of the first VNF (310) are provided in the current ETSI NFV standard. Not provided. Therefore, to solve this problem, it is necessary to define the NFV MANO structure and the automatic configuration method of VNF.

Figure 4 is a conceptual diagram for explaining the structure of an NFV MANO according to an embodiment of the present invention.

Referring to FIG. 4, in the NFV MANO structure according to an embodiment of the present invention, in order to exchange information between VNFMs for automatic configuration when multiple VNFMs exist, the NFVO 410 includes an automation engine 411, VNFMs 420 and 430 may include automated agents 420 and 430, respectively. In FIG. 4 , for convenience of explanation, it is illustrated that only two VNFMs 420 and 430 exist, but in an actual NFV environment, a larger number of VNFMs may exist.

In addition, there may be an additional storage unit 440 that maintains/manages automation information (described later) defined between the automation engine 411 and the automation agents 421 and 431. The automated information storage unit 440 may exist within the NFVO 410, or may exist outside the NFVO 410 as illustrated in FIG. 4.

Meanwhile, the automation engine 411 and automation agents 421 and 431 are names used to describe components for the above-described information exchange that exist within the NFVO 410 and VNFM 420 and 430, and are necessarily independent software modules. It does not mean that it must exist. That is, the automation engine and automation agent may be comprised of part of the software embedded within NFVO and VNFM.

Here, since the automation information is information related to the VNF constituting the network service, it can be defined by expanding the table that maintains the network service (NS) profile (NSD) and may be stored in a separate table.

Figure 5 is a conceptual diagram to explain how information is exchanged between VNFMs for automatic VNF configuration on an NFV MANO according to an embodiment of the present invention.

The methods described in FIG. 5 are explained assuming the network service 300 previously described in FIG. 3 . That is, it is assumed that the first VNF (310; load balancer) is managed by the first VNFM (420), and the second VNF (320; server) is managed through the second VNFM (430). Meanwhile, although not shown in FIG. 5, the procedures illustrated in FIG. 5 are procedures performed after the VNF instance creation is requested by the NFVO 410 to the VNFMs 420 and 430. Meanwhile, in Figure 5, the automation engine 411 of the NFVO 410, the automation agent 421 of the first VNFM 420, and the automation agent 431 of the second VNFM 430 are omitted, but are understood to exist. It has to be.

For the network service of FIG. 3, the IP address of the second VNF is required as automation information in the configuration variable of the first VNF.

First, referring to (a) of FIG. 5, the first VNFM 420 (i.e., the automation agent 421 of the first VNFM 420) provides information about the IP address of the second VNF for the first VNF. A request (i.e., automation information for the first VNF; 450) is registered in the NFVO 410 (i.e., in the automation engine 411 of the NFVO 410) (S510). At this time, the automation engine 411 of the NFVO 410 uses the automation information 450 of the first VNF (i.e., the IP address of the second VNF is required to set up the first VNF) to configure the second VNFM (430). ) (i.e., to the automation agent 431 of the second VNFM 430) registers a request for information about the IP address of the second VNF (S520). The second VNFM 430 (i.e., the automated agent 431 of the second VNFM 430), based on the registered information request, sends this information to the NFVO (410) at the time the IP address of the second VNF is obtained. ) is notified (S530). Finally, the NFVO (410) informs the automated agent (421) of the first VNFM (420) of this information (S540).

Once the automation information 450 for the first VNF is registered by procedures S510 and S520, procedure S530 is performed each time the IP address of the second VNF instance is changed, added, or deleted, and only once procedures S510 and S520. Procedures S530 and S540 occur from time to time by changing the instance of the second VNF.

Next, (b) in FIG. 5 shows a case where the NFVO (410) automatically registers a request for information about the second VNF to the second VNFM (430) without a request from the first VNFM (420) using automation information. This is a conceptual diagram explaining . That is, in the case illustrated in (a) of FIG. 5, the first procedure (S510) is omitted. This can be changed depending on the level of automation information registered in the automation information 440 of FIG. 4, and in (b) of FIG. 5, the information is defined to the extent that the information request registration process can be omitted in the automation information, so NFVO uses this. Based on this, the procedure for receiving a request from the first VNFM (S510) is omitted.

Lastly, in Figure 5(c), the first procedure (S510) and the second procedure (S520) are omitted in the case illustrated in Figure 5(a), and this is notified when creating an instance of the second VNF. The automated information request procedure was omitted. As described above, the registration procedure (S510, S520) is omitted based on automated information, and the information is provided when requesting the second VNFM to create a second VNF, or each VNFM shares information in advance to perform a separate information request procedure. This allows the configuration of each VNF to be performed automatically without the need to perform it separately.

Figure 6 is a block diagram for explaining automation information according to an embodiment of the present invention.

Referring to FIG. 6, automation information according to an embodiment of the present invention may exist for each VNF, and includes an internal event for basic settings of the VNF and an external event and reverse external event indicating dependency between VNFs. ) may include. These events can be used to indicate the procedures performed when setting up an actual VNF.

By way of example, the automation information of two virtual VNFs (VNF1 and VNF2) is described in more detail as follows.

First, an internal event (610) is a setting that is basically operated when creating/modifying an instance of a VNF, and is independent of external circumstances and sets itself using information that does not change.

Meanwhile, external events are divided into cases of using information delivered from the outside and cases of delivering information to the outside, and are divided into a normal external event (620) and a reverse external event (630). can be distinguished. At this time, it can be seen that the reverse external event 630 of VNF1 has a corresponding relationship with the external event 660 of VNF2, which is the counterpart.

An external event sets itself using information from another VNF or information transmitted externally, such as a Manager, and a reverse external event is a value transmitted as an external event from another VNF. is defined and its operation is defined. In the case described in FIGS. 3 and 5, the IP address of the second VNF 320 is a value transmitted to the second VNF 320 for an external event, and is transmitted to the first VNF 310 for an external event. You can see that this is the received value.

However, external events do not necessarily have an unconditional dependency on external events, and there may be cases where they are driven based on information defined in other blocks of MANO.

In the case of Internet events that are not variable in NS and environment, they can be defined and processed internally between VNFM and VNF by defining their contents in the VNF package rather than including them in the automation information of NFVO. In the present invention, the event is not limited to various internal technical methods and can be implemented using various formats such as shell script, open API, SNMP, and message, for example.

7 and 8 are conceptual diagrams for explaining a VNF automatic configuration method according to an embodiment of the present invention.

FIG. 7 is a conceptual diagram illustrating the initial instance creation process in the VNF automatic configuration method according to an embodiment of the present invention, assuming the network service situation of FIG. 3 described above.

Referring to FIG. 7, the NFVO 410 requests each of the VNFMs 420 and 430 to create VNFs constituting the target network service 300 with reference to the NSD shape information 450 (S710, S711). At this time, the creation of a VNF can be requested including automation information for each VNF (including information about internal events, external events, and station external events for each VNF).

Each VNFM (420, 430) that received the request creates its own VNF (i.e., the first VNF (310) and the second VNF (320)), and sends internal event information from the automation information of each VNF to each VNF. It can be delivered to (S720, S721).

VNFMs 420 and 430 and VNFs 310 and 320 may perform automated internal settings based on internal event information. Each of these internal automations does not affect the other VNFMs.

That is, in the embodiment of FIG. 7, the NFVO 410 transmits automation information for each VNF when requesting VNF creation, so that only the internal event of FIG. 6 described above is performed without a separate information request registration procedure between NFVO and VNFM. Applies to cases where there is.

FIG. 8 is a conceptual diagram illustrating in more detail the case where external events and station external events are included in the event processing procedure after going through the initial instance creation process described in FIG. 7 in the VNF automatic configuration method according to an embodiment of the present invention. am.

When external events and station external event information are transmitted through S720 and S721 in FIG. 7, the automated information registration request starts from the first VNFM and is transmitted to the NFVO and the second VNFM for registration, as described in FIG. 5 (a). The request is completed. Figure 8 shows the subsequent procedure.

It is conveyed to the second VNFM (430) that the internal settings of the second VNF (320) have been completed (S810). At this time, the second VNFM 430 is externally related information to be provided to the second VNF 320 (i.e., a value to be transmitted as a reverse external event, for example, the server for the network service of FIG. 3). The existence of an IP address can be confirmed by referring to the registration request result (in the case of Figure 5 (a)) or the automation information of the second VNF (in the case of Figure 5 (c)).

When the existence of relevant information (external reference External Event) that must be transmitted externally is confirmed, the information of the second VNF is transmitted to the NFVO 410 (S820).

The NFVO 410 confirms the first VNF 310 to which the received information is applied, and transmits the information from the second VNFM 430 to the first VNFM 420, which manages the first VNF 310 ( S830).

The first VNFM 420 requests the first VNF 310 to process an external event (S840). Accordingly, setting of the first VNF 310 is completed.

Each component (NFVO, VNFM) for performing the VNF automatic configuration method according to the present invention may be composed of program codes, and the program codes are stored in at least one memory device and executed by at least one processor. You can. At this time, the at least one memory device and at least one processor may exist in one device or may be distributed across two or more devices. In addition, each of the above components is defined only by its intended function and is not limited by the above-mentioned name. Additionally, at least two or more of the components described above may be integrated and implemented as one functional unit. Additionally, at least one of the components described above may be distributed and implemented in two or more functional units.

Although the present invention has been described above with reference to preferred embodiments, those skilled in the art may make various modifications and changes to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. You will understand that you can do it.

410: NFV Orchestrator,
420, 430: Virtualization network manager
411: automation engine, 421, 431: automation agent
440: automation information storage unit, 600: automation information
610: Internal event, 620: External event
630: Event outside the station

Claims (10)

As a method of operating an NFV Orchestrator (NFVO: NFV Orchestrator) in a Network Function Virtualization (NFV) system,
The automation engine of the NFV Orchestrator (NFVO) receives first automation information for setting the first VNF managed by the first VNFM from the first automation agent of the first virtualization network function manager (VNFM: VNF manager). receiving a registration request for;
The automation engine of the NFVO receiving a registration request for second automation information for setting a second VNF managed by the second VNFM from a second automation agent of the second VNFM;
registering the first automation information and the second automation information; and
The NFVO transmits information necessary for setting up the first VNF to the first VNF based on the registered first automation information, and information necessary for setting up the second VNF based on the registered second automation information. Comprising transmitting information to the second VNF,
The NFVO mediates the exchange of information necessary for configuring the first VNF and the second VNF between the first VNFM and the second VNFM, based on the first automation information and the second automation information.
How NFVO works. delete In claim 1,
The first automation information is stored in a table that maintains a network service profile, or is stored in a separate table.
How NFVO works. In claim 1,
The step of receiving a registration request for the first automated information is received from the first VNFM to the NFVO while the first VFNM creates the first VNF, and receives a registration request for the second automated information. The step of receiving the NFVO from the second VNFM in the process of the second VFNM creating the second VNF,
How NFVO works. In claim 1,
The first automation information includes information generated by an internal event of the first VNF and/or information generated by an external event of the first VNF, and the second automation The information includes information generated by an internal event of the second VNF, and/or information generated by an external event of the second VNF,
How NFVO works. In claim 5,
The internal event and the external event are implemented in the form of a shell script, open application programming interface (API), simple network management protocol (SNMP), and/or messaging,
How NFVO works. In claim 5,
The internal event is creation/modification of an instance of the first VNF or the second VNF,
How NFVO works. In claim 5,
The external event includes an external event that transmits information to a VNF other than the first VNF or the second VNF and a reverse external event that receives information from a VNF other than the first VNF or the second VNF. containing,
How NFVO works. delete In claim 1,
The first automation information is information related to the second VNF necessary for setting the first VNF, and the second automation information is information related to the first VNF necessary for setting the second VNF,
How NFVO works.

Images