KR20180058458A - Virtualized network function management method and virtualized network function manager using TOSCA based information model, and network function virtualization system using the same - Google Patents

Abstract

A virtualized network function (VNF) manager which manages VNFs comprises: an orchestrator interface unit interlocked with an orchestrator; a VNF virtual resource management unit managing virtual resources for the VNFs and collecting performance information and state information on the VNFs; and a VNF lifecycle management unit receiving a network service instance creation command from the orchestrator through the orchestrator interface unit, searching for a topology and orchestration specification for cloud application (TOSCA) information model file based on an identifier of a target VNF delivered via the command, and generating an instance of the target VNF in connection with the VNF virtual resource management unit based on the searched TOSCA information model file. According to embodiments of the present invention, an information model is defined to provide a network service based on TOSCA information model technology and the information model is utilized, thereby effectively distributing the network service to various virtual infrastructures.

Description

TECHNICAL FIELD [0001] The present invention relates to a virtual network function management method using a TOSCA-based information model, a virtual network function manager, and a network function virtualization system using the TOSCA based information model }

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to network function virtualization (NFV) technology, and more particularly, to a method and apparatus for managing virtualized network functions (VNFs) using a topology and orchestration specification for cloud application (TOSCA) Method, a virtualization network function manager (VNFM: VNF Manager), and an NFV system using the same.

Currently, the Virtual Network Function Manager (VNFM) architecture proposed in the MANO (Management and Orchestration) structure of ETSI ISG is a structure capable of processing VNF and VNFM conforming to the standard interface.

However, there is a problem in that a technology for configuring a network service using mutually related VNFs and automatically and efficiently distributing the network service to the virtual infrastructure is not considered, and a process for dealing with the distribution process independent of the underlying virtual infrastructure can not be defined have.

In other words, in actual operation situation, it is required to dynamically distribute a large number of VNFs in various virtual infrastructure environments, to define an information model for effectively providing network services, and to efficiently convert the target virtual infrastructures.

The present invention is based on a Topology and Orchestration Specification for Cloud Application (TOSCA) for effectively distributing network services composed of a plurality of VNFs to various virtual infrastructures in a virtualization network function manager (VNFM) Based MANO environment proposed by ETSI and propose the structure and operation method of VNFM for efficient processing.

It is another object of the present invention to provide a virtual network function management method using a TOSCA-based information model.

It is another object of the present invention to provide a structure of a virtual network function manager using a TOSCA-based information model.

It is another object of the present invention to provide a configuration of a network functional virtualization (NFV) system using the virtual network function manager and method described above.

In order to achieve the above object, the present invention provides a VNFM for managing VNFs on an NFV system. The VNFM according to an embodiment of the present invention includes an orchestrator interface unit operatively associated with an orchestrator; A VNF virtual resource manager for managing virtual resources for the VNFs and collecting performance information and status information of the VNFs; And a controller for receiving a network service instance creation command from the orchestrator through the orchestrator interface unit, searching for a TOSCA information model file based on the identifier of the target VNF transmitted through the command, And a VNF lifecycle manager for generating an instance of the target VNF in cooperation with the VNF virtual resource manager.

Here, the TOSCA information model file can be stored in the TOSCA information model database.

Here, the VNF lifecycle manager may include a TOSCA parser for analyzing the TOSCA information model file and constructing information for generating the target VNF instance; And a virtual infrastructure converting unit for generating an instance of the target VNF in cooperation with the VNF virtual resource manager based on the TOSCA information model file analysis result of the TOSCA parser.

Here, the orchestrator interface unit includes a message parser for receiving and parsing the network service instance creation command in the form of a REST message through the orchestrator interface unit, and for transmitting the parsed message to the VNF lifecycle manager; And a message generator for generating a REST message based on the message received from the VNF lifecycle manager and delivering the REST message to the NFV orchestrator.

Here, the VNFM processes scaling control for the VNFs, and further includes a VNF configuration manager for transmitting installation information and configuration information of the VNF instance and software to the VNFs upon initialization and restoration of the VNFs .

In addition, the VNFM may further include a VNF interface unit that interfaces with the generated target VNF instance and processes the message communication function with the VNFs in cooperation with the VNF configuration management unit.

Here, the VNFM may further include EMs (Element Management) connected to the VNFs and an EM interface unit for managing interfaces related to the setting for VNF operation.

Here, the VNFM may convert a message from the VNF virtual resource manager into a virtualized infrastructure manager (VIM) application programming interface (API) format and transmit the message to the VIM, And a VIM interface unit for transmitting the VNF virtual resource management unit to the VNF virtual resource management unit.

Here, the TOSCA information model may define at least one of a connection point, a network service, a VDU, a VL, and a VNFC as a node template, A resource component necessary for the network resource can be defined including at least one of a computing resource, a network resource, a port, a router, a security group, and a subnet.

According to another aspect of the present invention, there is provided a method of operating a VMFM for managing VNFs on an NFV system. A method of operating a VNFM according to an embodiment includes receiving a network service instance creation command from an NFV orchestrator; Retrieving a TOSCA information model file based on the identifier of the target VNF delivered via the network service instance creation command; And generating an instance of the target VNF based on the searched TOSCA information model file.

Wherein generating the instance of the target VNF comprises: analyzing the TOSCA information model file to construct information for generating the target VNF instance; And generating an instance of the target VNF based on the TOSCA information model file analysis result and the management information on the virtual resources for the VNFs.

Here, the network service instance creation command from the NFV orchestrator is received from the NFV orchestrator in the form of a REST message, and the result of the generation of the target VNF instance according to the network service instance creation command is transmitted to the NFV orchestrator Lt; / RTI >

Herein, the method of operating the VNFM processes scaling control for the VNFs, and transmits the installation information and setting information of the VNF instance and software to the VNFs upon initialization and restoration of the VNFs As shown in FIG.

Here, the VNFM operation method converts management information, performance information, and status information of the virtual resources of the VNFs into a virtualized infrastructure manager (VIM) application programming interface (API) Or receiving the management information, performance information, and status information from the VIM.

Here, the TOSCA information model may define at least one of a connection point, a network service, a VDU, a VL, and a VNFC as a node template, A resource component necessary for the network resource can be defined including at least one of a computing resource, a network resource, a port, a router, a security group, and a subnet.

 According to another aspect of the present invention, there is provided an NFV system. The NFV system includes Virtualized Network Function (VNF); Network Functionality Network Function Virtualization Infrastructure (NFVI); And an orchestrator interface unit including an NFV management and adjustment (MANO) composed of an orchestrator, a VNFM, and a VIM, and interworking with the VNFM and the NFV orchestrator; A VNF virtual resource manager for managing virtual resources for VNFs and collecting performance information and status information of the VNFs; And a network service instance creation command from the NFV orchestrator through the orchestrator interface unit, reads a TOSCA information model file based on the identifier of the target VNF transmitted through the command, And a VNF lifecycle manager for generating an instance of the target VNF in cooperation with the VNF virtual resource manager.

Here, the TOSCA information model may define at least one of a connection point, a network service, a VDU, a VL, and a VNFC as a node template, A resource component necessary for the network resource can be defined including at least one of a computing resource, a network resource, a port, a router, a security group, and a subnet.

In an exemplary embodiment of the present invention, an information model for providing a network service based on a TOSCA (Topology and Orchestration Specification for Cloud Application) information model technology is defined and utilized to efficiently distribute network services to various virtual infrastructures , It is possible to efficiently distribute network services to various virtual infrastructures.

1 is a block diagram for explaining an ETST NFV architecture to which a VNFM according to the present invention is applied.
2 is a block diagram of a virtual network function manager (VNFM) according to one embodiment of the present invention.
3 is a flowchart illustrating a method of operating a virtual network function manager (VNFM) according to an exemplary embodiment of the present invention.
4 is a conceptual diagram illustrating node templates for the basic elements for network virtualization in the TOSCA information model according to an embodiment of the present invention.
FIG. 5 is a conceptual diagram illustrating node templates for resource elements necessary for instantiating each of the network virtualization element node templates illustrated in FIG. 4; FIG.
6 is a conceptual diagram illustrating TOSCA-based information modeling for a VNF according to an embodiment of the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. 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. Like reference numerals are used for like elements in describing each drawing.

The terms first, second, A, B, etc. may be used to describe various elements, but the elements should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In the present application, the terms "comprises" or "having" and the like are used to specify that there is a feature, a number, a step, an operation, an element, a component or a combination thereof described in the specification, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

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

1 is a block diagram for explaining an ETST NFV architecture to which a VNFM according to the present invention is applied.

Referring to FIG. 1, the NFV architecture proposed by the ETSI may be configured to include a Virtualized Network Function (VNF) 120 and a Network Function Virtualization Infrastructure (NFVI) 140 .

In this case, OSS (Operations Support System) is a system to support provider network operation and provision and maintenance of customer service. BSS (Business Support System) is a billing system for customer, CRM Relationship Management, and call center automation.

..., 122-N corresponding to each of the VNF instances 121-1, ..., and 121-N may be present on the VNF 120. [ ) May exist. There is virtualization resources 141, 142 and 143 virtualized by the virtualization layer 144 and the virtualization layer 144 that virtualizes the actual physical hardware resources on the NVFI 140 .

There may also be an NFV Management and Orchestration component (MANO) 150 on the NFV architecture for managing and coordinating the components.

The MANO 150 manages virtual resources (computing resources, network resources, storage resources) and performs orchestration of virtual resources. Therefore, it is necessary to confirm whether or not the virtual resources can be used for the network service composed of a plurality of VNFs, to actually distribute the virtual resources, and to configure the distribution order and related information among the VNFs for successful service initiation, .

MANO 150 includes an orchestrator 151 for adjusting overall operation, a virtual network function manager (VNFM) 152 for managing VNF 120, and a virtualization infrastructure manager A virtualized infrastructure manager (VIM) 153 may exist.

The role of the VNFM 152 is to perform life cycle management of the VNFs between the VNFs, the virtual resources, and the orchestrator 151 that oversees the services. In particular, the VNFM 152 manages the association between virtual resources and VNFs in a cloud environment, and maintains and optimizes the continuity of services provided by the VNFs by instantly responding to events or state changes occurring therebetween. do.

NFVI refers to hardware and software components composed of environments in which VNF can be executed. OpenStack and CloudStack are based on open source. Each NFVI provides its own application interface.

The NFVI can be divided into three domains, a compute domain (including storage), a hypervisor domain, and an infrastructure network domain. Virtual computing and virtual storage belonging to the hypervisor domain refer to virtual resources allocated to virtual machines based on physical resources, and the virtualization layer refers to hypervisors such as KVM and XEN.

Computing hardware and storage hardware belonging to the compute domain refer to physical hardware resources. A virtual network belonging to the infrastructure network domain refers to a virtual network allocated to a virtual machine. (network hardware) refers to each physical network device. NFVI has a virtualized Infrastructure Manager (VIM) and a reference point Nf-Vi, and has a VNF and Vn-Nf reference architecture.

2 is a block diagram of a virtual network function manager (VNFM) according to one embodiment of the present invention.

According to an embodiment of the present invention, the virtualization network function manager (VNFM) 200 provides a management control function for the entire lifecycle from creation to termination of a VNF operating on a virtual infrastructure. In particular, the VNFM 200 manages the association of virtual resources and VNFs in a cloud environment, maintains continuity of services provided by VNFs by instantly responding to events or state changes occurring between virtual resources and VNFs, .

2, the VNFM 200 according to an exemplary embodiment of the present invention may include an orchestrator interface unit 210, a VNF lifecycle management unit 200, and a VNF virtual resource management unit 230 . In addition, the VNFM 200 may further include a VNF configuration management unit 240, an EM interface unit 250, a VNF interface unit 260, and a VIM interface unit 270.

The orchestrator interface unit 210 is an interface component for processing an operation for VNF life cycle management in cooperation with an orchestrator (NFVO) 151 illustrated in FIG. 1. Specifically, A message generator 211 and a message generator 212.

The message parser 211 parses the REST (Representational State Transfer) message received from the NFVO to authenticate whether it is a normal message, generates a message to be transmitted to the VNF lifecycle manager 220 according to the type of the message, Can be performed.

The message generator 212 configures the HTTP header of the REST message to be transmitted to the NFVO according to the message received from the VNF lifecycle manager 220, adds detailed information of JSON (JavaScript Object Notation) format to the body, Depending on the message type, you can perform REST client functions that generate GET, PUT, POST, or DELETE messages.

In addition, the orchestrator interface unit 210 may transmit the REST message including the valid authentication information to the REST message to be transmitted to the NFVO, and may request the authentication of the REST message received from the NFVO.

The VNF virtual resource management unit 230 manages virtual resources for VNFs managed by the VNFM 200 and collects performance information and status information of the VNFs and transmits the collected information to the VNF lifecycle management unit 220 . Meanwhile, the VNF virtual resource management unit 230 may store information on the virtual resources, the performance information, and status information in a predetermined storage 310. The repository 310 may exist as an external component of the VNFM 200 (as an example in FIG. 2) and may exist as an internal component of the VNFM 200.

The VNF lifecycle management unit 220 performs the VNF control management function requested through the interface with the NFVO and the interface between the VNF and the EM. The VNF control management function may include at least one of a VNF package reference function, a VNF instance life cycle management control function, a VNF performance and failure interface function, a VNF lifecycle change notification function, and a VNF virtual resource allocation information request function.

The VNF lifecycle management unit 220 receives the network service instance creation command from the orchestrator through the orchestrator interface unit, searches the TOSCA information model file based on the identifier of the target VNF transmitted through the command, And may create an instance of the target VNF in cooperation with the VNF virtual resource management unit 230 based on the TOSCA information model file. Meanwhile, the TOSCA information model files may be stored in a predetermined storage 320. The storage 320 may exist as an external component of the VNFM 200 (as an example in FIG. 2) and may exist as an internal component of the VNFM 200.

In detail, the VNF lifecycle manager 220 may include a TOSCA parser 221 and a virtual infrastructure converter 222.

The TOSCA parser 221 reads and analyzes the TOSCA information model file and constructs information for generating the target VNF instance. The virtual infrastructure converter 222 converts the TOSCA information file into the TOSCA parser 221, The VNF virtual resource manager 230 may generate an instance of the target VNF based on the analysis result of the TOSCA information model file of the target VNF.

The VNF configuration management unit 240 processes scaling control for the VNFs managed by the VNFM 200. Upon initialization and restoration of the VNFs, As shown in FIG. At this time, the VNF configuration management unit 240 may transmit the information to the VNFs through the VNF lifecycle management unit 220 or may directly transmit the information to the VNFs.

The EM interface unit 250 is responsible for the interface with the EM related to the VNF operation setting and can process the message communication function with the EM.

The VNF interface unit 260 interfaces with the generated VNF instance and can perform a message communication function with the VNF in conjunction with the VNF configuration management unit 240 described above.

Finally, the VIM interface unit 270 converts the message from the VNF virtual resource management unit 230 into a virtualized infrastructure manager (API) application programming interface (VIM) and transmits the message to the VIM interface unit 270. The VIM interface unit 270 transmits periodic and non- To the VNF virtual resource management unit 230.

Each component of the VNFM 200 and the VNFM 200 may be constituted by program codes, and the program codes may be stored in at least one memory device and executed by at least one processor. At this time, the at least one memory device and the at least one processor may exist in one apparatus or may be dispersed in two or more apparatuses. In addition, each of the above-described components is defined by a desired function of each component, and is not limited by the above-mentioned names. Also, at least two of the above-described components may be integrated into one functional unit. Also, at least one of the above-described components may be implemented by being distributed in two or more functional units.

Meanwhile, in the operation method of the virtual network function manager according to an embodiment of the present invention, the configuration of the VNFM is not limited to the configuration of FIG. That is, the configuration of the VNFM illustrated in FIG. 2 is a configuration of the VNFM according to the embodiment of the present invention, and does not mean that the operation method of the VNFM described below must be performed by the VNFM having the configuration described above. However, for convenience of explanation, the following description is based on the configuration of the VNFM illustrated in FIG.

3 is a flowchart illustrating a method of operating a virtual network function manager (VNFM) according to an exemplary embodiment of the present invention.

Referring to FIG. 3, a procedure for receiving and processing a defined network service using a TOSCA-based information model in a VNFM is illustrated.

First, the orchestrator transmits a network service instance creation command to the orchestrator interface unit 210 of the VNFM 200 to distribute the network service (S310). That is, the VNFM 200 can receive a network service instance creation command from the NFV orchestrator. At this time, the message parser 211 constituting the orchestrator interface unit 210 of the VNFM 200 receives the network service instance creation command in the form of a REST message and transfers the received command to the VNF lifecycle manager 22.

Next, the VNFM 200 searches the TOSCA information model file based on the identifier of the target VNF transmitted through the network service instance creation command (S320). At this time, the VNF lifecycle management unit 220 of the VNFM 200 receives the network service instance creation command transmitted through the orchestrator interface unit 210, and based on the identifier of the target VNF transmitted through the command The TOSCA information model file stored in the predetermined storage 320 can be retrieved.

At this time, it is determined whether a pre-registered TOSCA information model file exists (S330). If there is no pre-registered TOSCA information model file, the requested network service instance is stopped. 3, the VNFM 200 uses the message generator 212 of the orchestrator interface 210 to inform the orchestrator 210 that there is no TOSCA information model file for the requested network service, As shown in FIG.

If there is a pre-registered TOSCA information model file, the corresponding TOSCA information model file can be read and parsed (S340). For example, the TOSCA parser 221 of the VNF lifecycle manager 220 may perform the parsing operation.

Next, the VNFM 200 generates an instance of the target VNF based on the retrieved TOSCA information model file. That is, the VNFM 200 configures information for generating the target VNF instance based on the analysis result of the searched TOSCA information model file, and analyzes the TOSCA information model file analysis result and the virtual resources for the VNFs The target VNF instance is generated based on the management information (S340).

For example, the VNFM 200 parses and analyzes the corresponding TOSCA information model file using the TOSCA parser 221 (S341), forms information for generating the related VNF, and interworks with the VNF virtual resource manager 230 The additional resource information defined in the TOSCA information model can be analyzed (S342). Next, the result of analyzing the TOSCA information model and the information obtained in conjunction with the VNF virtual resource management unit 230 are transmitted to the virtual infrastructure conversion unit 222. After the VIM of the virtual infrastructure to be instantiated is confirmed, the virtual infrastructure converter 222 can transmit an instance initialization command for the corresponding VNF using the API for the virtual infrastructure (S343).

Meanwhile, although not shown in FIG. 3, the result of generating the target VNF instance according to the network service instance creation command may be transmitted to the NFV orchestrator in the form of a REST message.

The goal of TOSCA is to improve the portability of application layer services in various cloud environments. It is a technology that specifies topology and management procedure of application in XML based language.

TOSCA defines a meta model to define IT services, and the metamodel defines the structure of the service as well as how to manage the service. The topology defines the structure of the service, and the topology template consists of a number of node templates and relationship templates. The relationship template defines a topology model of the service expressed as a graph with directionality. A node in a graph is represented by a node template, and a node template is a component constituting a service and expressed in the form of a node type. The node type defines the properties of these components and the operations for those components through the interface.

FIG. 4 is a conceptual diagram illustrating node templates for basic elements for network virtualization in the TOSCA information model according to an embodiment of the present invention. FIG. 5 is a diagram illustrating each of the network virtualization element node templates illustrated in FIG. FIG. 4 is a conceptual diagram illustrating node templates for resource elements necessary for instantiation.

4, in order to configure various network services, in one embodiment of the present invention, a connection point 410, a network service 420, a VDU Virtualization Deployment Unit 430, Virtual Link 440, and Virtual Network Function Components 450 can be defined as node templates.

In addition, components necessary for actually instantiating each of the network virtualization element node templates configured in a virtualized manner may be referred to as a resource descriptor, and as shown in FIG. 5, a computer 510, a network 520 ), A port 530, a router 540, a security group 550, and a subnet 560, and can be defined as a node template.

6 is a conceptual diagram illustrating TOSCA-based information modeling for a VNF according to an embodiment of the present invention.

6, a VNF 600 called a vADC is composed of one VNFC (vnfc1) 610 and the corresponding VNFC has one VDU (vdu1) 620 and three connection points P1 to P3 (630 to 650) .

The following is an example of the contents of the VNFD (VNF Descriptor) information model file for the VNF illustrated in FIG.

VNFD Information Model File Example

tosca_definitions_version: tosca_simple_yaml_1_0

description: vADC VNF Description

template_name: vADC VNF v1.1

imports:

  - etri_nfv_vdu.yaml, etri_nfv_vnfc.yaml, etri_nfv_cp.yaml, etri_nfv_vl.yaml

service_properties:

     id: ADC-vnfd

     vendor: AAA

     version: 0.1

     type:

        - vADC

topology_template:

    node_templates:

        vdu1:

            type: tosca.nodes.etri.nfv.vdu

            properties:

                id: vdu1

                vm_image: vADC-r1.1

                compute_requirement:

                    cpu_model: x86_64

                    hypervisor_parameter: QEMU

                virtual_memory_resource_element: 8G

                virtual_network_bandwidth_resource: 1G

                service_type: vADC

                mgmt_driver: pio_vADC

        vnfc1:

            type: tosca.nodes.etri.nfv.vnfc

            requirements:

                - vnfc_vdu_ref:

                    node: vdu1

            properties:

                id: vnfc1

                connection_points:

                    - {cp: P1}

                    - {cp: P2}

                    - {cp: P3}

        P1:

            type: tosca.nodes.etri.nfv.cp

            requirements:

                - cp_vnfc_ref:

                    node: vnfc1

            properties:

                id: P1

                type: virtual nic address

        P2:

            type: tosca.nodes.etri.nfv.cp

            requirements:

                - cp_vnfc_ref:

                    node: vnfc1

            properties:

                id: P2

                type: virtual nic address

        P3:

            type: tosca.nodes.etri.nfv.cp

            requirements:

                - cp_vnfc_ref:

                    node: vnfc1

            properties:

                id: P3

                type: virtual nic address

The following is an example of the contents of a resource information model file for the VNF illustrated in FIG.

Example of resource information model file

tosca_definitions_version: tosca_simple_yaml_1_0

description: vADC VNF Resource Input Description

template_name: vADC VNF Resource Input v1.0

imports:

  - etri_nfv_res_securitygroup.yaml

  - etri_nfv_res_network.yaml

  - etri_nfv_res_port.yaml

  - etri_nfv_res_router.yaml

  - etri_nfv_res_subnet.yaml

  - etri_nfv_res_compute.yaml

topology_template:

    inputs:

        management_network:

            type: string

            description: management network name

        external_network:

            type: string

            description: service external network name

        internal_network:

            type: string

            description: service internal network name

        public_network:

            type: string

            description: public network name

    node_templates:

        port_P1:

            type: tosca.nodes.etri.nfv.res.Port

            requirements:

                - port_cp_ref:

                    node: P1

            properties:

                networkResourceId: P1

                typeNetworkPortData:

                    - portType: L3

                      networkId: {get_input: management_network}

                      metadata:

                        - attach_subnet: {get_input: management_network}

                          connection_point: public_P1

                          connection_point_subnet: {get_input: public_network}

        port_P2:

            type: tosca.nodes.etri.nfv.res.Port

            requirements:

                - port_cp_ref:

                    node: P2

            properties:

                networkResourceId: P2

                typeNetworkPortData:

                    - portType: L3

                      networkId: {get_input: external_network}

                      metadata:

                        - attach_subnet: {get_input: external_network}

                          ip_address: 200.0.10.7

                        - attach_subnet: {get_input: external_network}

                          ip_address: 200.0.10.100

        port_P3:

            type: tosca.nodes.etri.nfv.res.Port

            requirements:

                - port_cp_ref:

                    node: P3

            properties:

                networkResourceId: P3

                typeNetworkPortData:

                    - portType: L3

                      networkId: {get_input: internal_network}

                      metadata:

                        - attach_subnet: {get_input: internal_network}

                          ip_address: 100.0.0.7

        vADC:

            type: tosca.nodes.etri.nfv.res.Compute

            requirements:

                - vnfc:

                    node: vnfc1

            properties:

                computeId: vADC

                computeData:

                    flavorId: vadc.vnfc1.1

                    virtualMemory:

                        virtualMemSize: 8192

                    virtualCpu:

                        numVirtualCpu: 4

                    virtualNetworkInterfaces:

                        - {networkPortId: port_P1}

                        - {networkPortId: port_P2}

                        - {networkPortId: port_P3}

                metadata:

                    availabilityZone: nova.compute01

    outputs:

        vnfc_names:

            value: "['vADC']"

            description: VNFs Name List

        vADC_service_type:

            value: "vADC"

            description: vnf's type

        vADC_name:

            value: "{get_attr: [vADC, name]}"

            description: vnf's instance name

        vADC_show:

            value: "{get_attr: [vADC, show]}"

            description: vnf's detailed information

        vADC_serv_1:

            value: "100.0.0.5"

            description: vADC target server address

        vADC_serv_2:

            value: "100.0.0.4"

            description: vADC target server address

        vADC_vip:

            value: "200.0.10.100"

            description: vADC target server address

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the present invention as defined by the following claims It can be understood that

200: Virtualization Network Function Manager
210: an orchestrator interface unit
211: message parser 212: message generator
220: VNF Lifecycle Manager
221: TOSCA parser 222: virtual infrastructure converter
230: VNF virtual resource management unit 240: VNF configuration management unit
250: EM interface unit 260: VNF interface unit
270: VIM interface section

Claims (20)

As a virtualization network function manager (VMFM: VNF manager) that manages virtualized network functions (VNF) on a network function virtualization (NFV) system,
An orchestrator interface unit interlocked with the orchestrator;
A VNF virtual resource manager for managing virtual resources for the VNFs and collecting performance information and status information of the VNFs; And
Receiving a network service instance creation command from the orchestrator through the orchestrator interface unit, searching for a TOSCA information model file based on the identifier of the target VNF transmitted through the command, and searching the VNF And a VNF lifecycle manager for generating an instance of the target VNF in cooperation with the virtual resource manager.
Virtualization Network Function Manager. The method according to claim 1,
The TOSCA information model file is stored in the TOSCA information model database,
Virtualization Network Function Manager. The method according to claim 1,
The VNF lifecycle management unit includes:
A TOSCA parser for analyzing the TOSCA information model file to construct information for generating the target VNF instance; And
And a virtual infrastructure transformer for generating an instance of the target VNF in cooperation with the VNF virtual resource manager based on the analysis result of the TOSCA information model file of the TOSCA parser,
Virtualization Network Function Manager. The method according to claim 1,
The orchestrator interface unit comprises:
A message parser for receiving and parsing the network service instance creation command in the form of a REST message through the orchestrator interface and delivering the network service instance creation command to the VNF lifecycle manager; And
A message generator for generating a REST message based on a message received from the VNF lifecycle manager and delivering the REST message to the NFV orchestrator;
Virtualization Network Function Manager. The method according to claim 1,
Further comprising a VNF configuration manager for processing scaling control for the VNFs and for transferring VNF instance and software installation and configuration information to the VNFs during initialization and recovery of the VNFs.
Virtualization Network Function Manager. The method of claim 5,
Further comprising a VNF interface unit that interfaces with the generated target VNF instance and processes a message communication function with the VNFs in cooperation with the VNF configuration management unit,
Virtualization Network Function Manager. The method according to claim 1,
Further comprising: an EM interface unit for managing EMs connected to the VNFs and an interface for setting a VNF operation;
Virtualization Network Function Manager. The method according to claim 1,
A message from the VNF virtual resource management unit is converted into a VIM (Virtualized Infrastructure Manager) application programming interface (VIM) type and transferred to the VIM, or data received from the VIM is transferred to the VNF virtual resource management unit Further comprising a VIM interface portion for communicating,
Virtualization Network Function Manager. The method according to claim 1,
The TOSCA information model defines at least one of a connection point, a network service, a VDU, a VL, and a VNFC as a node template,
Virtualization Network Function Manager. The method of claim 9,
Wherein the TOSCA information model defines resource components required to instantiate the node template including at least one of a computing resource, a network resource, a port, a router, a security group, and a subnet,
Virtualization Network Function Manager. A method of operating a virtualized network function manager (VMFM: VNF manager) for managing virtualized network functions (VNFs) on a network function virtualization (NFV)
Receiving a network service instance creation command from an NFV orchestrator;
Retrieving a TOSCA information model file based on the identifier of the target VNF delivered via the network service instance creation command; And
And generating an instance of the target VNF based on the retrieved TOSCA information model file.
How the Virtualization Network Function Manager works. The method of claim 11,
Wherein generating an instance of the target VNF comprises:
Analyzing the TOSCA information model file to construct information for generating the target VNF instance; And
And generating an instance of the target VNF based on the TOSCA information model file analysis result and the management information on the virtual resources for the VNFs.
How the Virtualization Network Function Manager works. The method of claim 11,
Wherein the network service instance creation command from the NFV orchestrator is received from the NFV orchestrator in the form of a REST message and the result of the generation of the target VNF instance according to the network service instance creation command is transmitted to the NFV orchestrator in the form of a REST message,
How the Virtualization Network Function Manager works. The method of claim 11,
Further comprising processing scaling control for the VNFs and forwarding VNF instance and software installation and configuration information to the VNFs upon initialization and recovery of the VNFs.
How the Virtualization Network Function Manager works. The method of claim 11,
Performance information and status information of the virtual resources of the VNFs into a VIM (Virtualized Infrastructure Manager) application programming interface (VIM) type to transfer the information to the VIM, , Performance information, and status information. ≪ RTI ID = 0.0 >
How the Virtualization Network Function Manager works. The method of claim 11,
The TOSCA information model defines at least one of a connection point, a network service, a VDU, a VL, and a VNFC as a node template,
How the Virtualization Network Function Manager works. 18. The method of claim 16,
Wherein the TOSCA information model defines resource components required to instantiate the node template including at least one of a computing resource, a network resource, a port, a router, a security group, and a subnet,
How the Virtualization Network Function Manager works. In a network function virtualization system,
Virtualized Network Function (VNF);
Network Functionality Network Function Virtualization Infrastructure (NFVI); And
An NFV management and coordination (MANO) consisting of an orchestrator, a VNFM, and a VIM,
The VNFM
An orchestrator interface unit interlocked with the NFV orchestrator;
A VNF virtual resource manager for managing virtual resources for VNFs and collecting performance information and status information of the VNFs; And
Receiving a network service instance creation command from the NFV orchestrator through the orchestrator interface unit, reading a TOSCA information model file based on the identifier of the target VNF transmitted through the command, And a VNF lifecycle manager for generating an instance of the target VNF in cooperation with the VNF virtual resource manager.
Network function virtualization system. 19. The method of claim 18,
The TOSCA information model defines at least one of a connection point, a network service, a VDU, a VL, and a VNFC as a node template,
Network function virtualization system. The method of claim 19,
Wherein the TOSCA information model defines resource components required to instantiate the node template including at least one of a computing resource, a network resource, a port, a router, a security group, and a subnet,
Network function virtualization system.

Images