KR20210042713A - Test apparatus to test interoperability of nfv system - Google Patents

Abstract

Disclosed is a test apparatus for testing interoperability of a network function virtualization (NFV) system. According to one embodiment, the test apparatus includes: a test profiler for generating a test case profile for testing interoperability of a plurality of virtual network function (VNF) function-under-tests (FUTs), which are test targets, among a plurality of VNFs constituting a series of service function chains (SFCs); a plurality of test agents installed in the VNF FUTs, respectively, to collect a metric from each of the VNF FUTs, and executing a test command based on the test case profile in each of the VNFs; and a test controller for parsing the test case profile to generate the test command, providing the test command to the test agents, receiving the metric collected from each of the VNF FUTs from the test agents, and analyzing the received metric to generate a test result for the interoperability of the VNF FUTs. Accordingly, interoperability is tested while complying with European Telecommunications Standards Institute (ETSI) standards.

Description

Test device for testing interoperability of NFV system {TEST APPARATUS TO TEST INTEROPERABILITY OF NFV SYSTEM}

The following embodiments relate to a test apparatus for testing interoperability of an NFV system.

The European Telecommunications Standards Institute (ETSI) proposed the concept of Network Function Virtualization (NFV) to reduce hardware expenditure and network operation complexity. In NFV, network functions are implemented in software form as VNF instead of dedicated hardware, and are separately executed in other virtual machines or containers on general hardware. Different VNFs are arranged in a prescribed order to form a service function chain (SFC) to meet the communication requirements. ETSI has adopted testing and quality of experience (QoE) monitoring as one of the key use cases and topics to be addressed when implementing an NFV environment. The examples focus on the VNF test. Some prior art has some related work related to VNF testing, but there are several problems, such as non-compliance with ETSI standards, targeting specific NFV platforms or vendors, and lack of interoperability testing.

According to an embodiment, a test apparatus for testing interoperability of a network function virtualization (NFV) system includes a plurality of virtual network functions (VNFs) constituting a series of service function chains (SFCs). A test profiler that generates a test case profile for testing the interoperability of VNF function under test (FUT); A plurality of test agents installed in each VNF FUT of the plurality of VNF FUTs, collecting metrics from each of the VNF FUTs, and executing a test command based on the test case profile in each of the VNFs; And parsing the test case profile to generate the test command, providing the test command to the plurality of test agents, receiving the metric collected in each VNF FUT from the plurality of test agents, and the And a test controller that analyzes the received metric and generates a test result regarding the interoperability of the plurality of VNF FUTs.

The plurality of test agents may communicate with each other to test the plurality of VNF FUTs to exchange test data including at least one of throughput, package loss, and service path accuracy.

The test for the interoperability of the plurality of VNF FUTs may include at least one of a test for a life cycle of each VNF, a test for a dependency of each VNF, and a test for an orchestration of the SFC.

The test controller includes a profile parser that parses the test profile into an object and a test metric, a VNF test agent driver that communicates with the plurality of test agents to provide the test command or receives the metric, the plurality of A management driver for installing the plurality of test agents in each VNF FUT with a driver of each of the plurality of test agents to support VNF FUTs driven in different types of NFV systems among VNF FUTs, and for the test case It may include a controller engine to coordinate the test procedure.

The test controller may inject a defect corresponding to the test case profile into at least some of the plurality of VNF FUTs corresponding to the at least some of the test agents through at least some of the test agents.

According to an embodiment, a test apparatus for testing interoperability of a network function virtualization (NFV) system includes a processor; And a memory including instructions executable in the processor, and when the instructions are executed in the processor, the processor is a test object among a plurality of virtual network functions (VNFs) constituting a series of service function chains (SFCs). A test profiler that generates a test case profile for testing the interoperability of a corresponding plurality of VNF FUTs (function under test), installed in each VNF FUT of the plurality of VNF FUTs, and collects metrics from each of the VNF FUTs , A plurality of test agents executing a test command based on the test case profile in each VNF, and generating the test command by parsing the test case profile, and providing the test command to the plurality of test agents And, implement a test controller that receives the metric collected in each VNF FUT from the plurality of test agents, analyzes the received metric, and generates a test result regarding the interoperability of the plurality of VNF FUTs do.

1 is a diagram illustrating an operation of a test apparatus for testing interoperability of an NFV system according to an embodiment.
2 is a diagram illustrating a conformance test, and FIG. 3 is a diagram illustrating an interoperability test.
4 is a diagram showing the configuration of a test controller according to an embodiment.
5 is a diagram showing the configuration of a test profiler according to an embodiment.
6 is a diagram illustrating a test for an SFC including VNF FUTs according to an embodiment.
7 is a diagram illustrating a procedure for testing interoperability of an NFV system according to an embodiment.
8 is a diagram illustrating a test apparatus for testing interoperability of an NFV system according to an embodiment.
9 is a diagram showing an NFV architecture according to an embodiment.

Specific structural or functional descriptions of embodiments according to the concept of the present invention disclosed in the present specification are exemplified only for the purpose of describing embodiments according to the concept of the present invention, and embodiments according to the concept of the present invention They may be implemented in various forms and are not limited to the embodiments described herein.

Since the embodiments according to the concept of the present invention can apply various changes and have various forms, the embodiments will be illustrated in the drawings and described in detail in the present specification. However, this is not intended to limit the embodiments according to the concept of the present invention to specific disclosed forms, and includes changes, equivalents, or substitutes included in the spirit and scope of the present invention.

Terms such as first or second may be used to describe various elements, but the elements should not be limited by the terms. The terms are only for the purpose of distinguishing one component from other components, for example, without departing from the scope of the rights according to the concept of the present invention, the first component may be referred to as the second component, Similarly, the second component may also be referred to as a first component.

When an element is referred to as being “connected” or “connected” to another element, it is understood that it may be directly connected or connected to the other element, but other elements may exist in the middle. It should be. On the other hand, when a component is referred to as being "directly connected" or "directly connected" to another component, it should be understood that there is no other component in the middle. Expressions that describe the relationship between components, for example, “between” and “just between” or “directly adjacent to” should be interpreted as well.

The terms used in the present specification are only used to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In the present specification, terms such as “comprise” or “have” are intended to designate that the specified features, numbers, steps, actions, components, parts, or combinations thereof exist, but one or more other features or numbers, It is to be understood that the presence or addition of steps, actions, components, parts, or combinations thereof does not preclude the possibility of preliminary exclusion.

Unless otherwise defined, 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 the present invention belongs. Terms as defined in a commonly used dictionary should be construed as having a meaning consistent with the meaning of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in the present specification. Does not.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. However, the scope of the patent application is not limited or limited by these embodiments. The same reference numerals shown in each drawing indicate the same members.

1 is a diagram illustrating an operation of a test apparatus for testing interoperability of an NFV system according to an embodiment.

Network Function Virtualization (NFV) is a new way to provide network services to customers. Unlike dedicated hardware, the network function of the NFV network is executed in a general server, and the service function chain (SFC) connects the virtual network function (VNF) to form a network service. To ensure the stability and quality of VNFs and SFCs, the performance of VNFs and SFCs should be evaluated prior to deployment of VNFs and SFCs in real systems. The conventional approach has not focused on the interoperability of VNFs. Therefore, according to embodiments, a framework for testing interoperability of NFV for VNF and SFC is proposed.

Examples study the test framework for VNF and SFC. The main goal of the framework is to perform comprehensive testing, specifically interoperability testing, for VNFs and SFCs.

One of the problems when building NFV is disability prevention. Failure prevention requires testing of VNFs to verify the stability of network services. The two common testing methods for NFV are conformance testing (functional and non-functional infrastructure testing) and interoperability testing (i.e., VNF lifecycle and orchestration testing of SFCs).

Traditionally, it focuses only on VNF functional testing (conformance testing) or NFV infrastructure (VNF non-functional testing), and does not provide interoperability testing for SFC, VNF dependencies, and lifecycle management. Also, it is only extensible on certain NFV platforms/vendors or does not work on other platforms/vendors.

In this situation, it is necessary to design an interoperability test system for the NFV system. The new test framework focuses on VNF interoperability, orchestration and dependency testing, not infrastructure. Targets are SFC accuracy, VNF interoperability, and VNF dependencies. The framework should also support automation, scalability, extensibility, multi-tenancy and multi-cloud.

The proposed test framework covers the interoperability of VNFs (e.g. life cycle of VNFs, orchestration of SFCs, dependencies of VNFs, etc.), can be integrated with the defect management platform, and must comply with ETSI standards. Fig. 1 shows the architecture of the proposed test framework, which includes major functional blocks such as a VNF test agent, test controller, test profiler, test result database (DB), API engine, and graphical user interface (GUI). Details of each function block are as follows.

1) Test Agent: A test agent is installed in each VNF function under test (FUT). The SFC may include a plurality of VNFs, and at least some of them may correspond to the VNF FUT. A service end point may exist in each of the start and end portions of a plurality of VNFs of the SFC, or VNF FUTs corresponding to at least some of them.

The agent can collect metrics from the VNF and send them back to the test controller. The agent can execute the test command within the VNF FUT as directed by the test controller and then execute the test controller's instructions. The agents communicate with each other to test the VNF FUT within the SFC. At this time, information about throughput, package loss, and service path accuracy may be exchanged.

The test controller can instruct the test agent to inject faults (loads, packages traveling in a forbidden path, etc.) into the VNF under test. Defects may be designed to test the performance and functionality of the VNFs and SFCs under test, depend on the test case, and may be defined in the test profile. Test agents support different types of NFVs (corresponding VNFs, agents, etc.), and corresponding agent drivers can be written in the test controller for this purpose.

2) Test Controller: The test controller is the center of the proposed VNF interoperability test system in which all test flows are coordinated, and can include a profile parser, VNF agent driver, management driver, controller engine and test result DB driver. .

3) Test Profiler: You can use the YAML language to define test templates that include target platforms, certifications, VNFs, and interoperability features under test.

4) Test result DB (database): Saves the test result.

5) API Engine: Can provide external software with secure read/write access to test profiler, test controller and test result DB. It can be used with other types of clients (web, desktop applications, etc.).

6) GUI: An interface that allows a user to enter a test profile and execute test cases through API calls, and can be used by the user to enter a test profile or visualize test results to the user through a graphic, web or command line interface. .

2 is a diagram illustrating a conformance test, and FIG. 3 is a diagram illustrating an interoperability test. There are techniques such as conformance testing and interoperability testing to test NFV. The conformance test is for performing functional and non-functional (infrastructure) tests, and in this test, there is one SUT (eg FUT). Interoperability testing is distinct from conformance testing, and is intended to test orchestration between multiple FUTs. In this case, the plurality of FUTs may be of different types provided by different suppliers. The embodiments relate to interoperability testing among them.

4 is a diagram showing the configuration of a test controller according to an embodiment.

The test controller is the center of the proposed VNF interoperability test system in which all test flows are coordinated, and may include a profile parser, VNF agent driver, management driver, controller engine and test result DB driver.

The profile parser can parse test profiles into objects and test metrics. The VNF agent driver may also be referred to as a VNF test agent driver, and communicates with the VNF test agent to collect data or inject defects, and analyze metrics from the collected data. The VNF agent driver can support various VNF vendors (KVM, VMWare VM, container, etc.).

Management drivers can coordinate tests and support other NFV systems to install test agents into VNFs running inside that NFV system. For example, a management driver can support other NFV systems to coordinate tests and install VNF test agents into VNFs running on NFV systems.

The controller engine can coordinate test procedures and test cases. For example, the controller engine can use a profile parser, a VNF agent driver, a management driver, and a test result DB driver to adjust test procedures and test cases, and expose a function interface to the API engine. The test result DB driver can store the test result in the support DB, and can support a backend for other test result DB.

5 is a diagram showing the configuration of a test profiler according to an embodiment.

The test profiler can include a YAML parser, a profile converter, and a database driver. The test profiler uses these configurations to work with the profile DB, communicate with the test controller, expose data to the API engine, validate the test profile, parse the input test profile (e.g., using the YAML parser), and convert YAML data into test metrics (e.g.: It can perform functions such as using a profile converter.

6 is a diagram illustrating a test for an SFC including VNF FUTs according to an embodiment.

NFV allows network operators to deploy services to their customers in a variety of flexible and customizable ways through one or more SFCs. In order to ensure the reliability and quality of the SFC, a test service for the SFC was previously described that focuses on the interoperability of the SFC. Embodiments can be implemented based on the modular architecture described above.

As described above, the NFV architecture framework was proposed in ETSI. It provides network operators with a flexible and customizable way of service. Instead of using a dedicated hard word or middle box as a network function, software is used to generate the VNF. VNFs can be arranged in a predefined order to create a service chain to achieve network service requirements.

Testing and Quality of Experience (QoE) testing are considered one of the ETSI's primary goals, which must be addressed when building an NFV environment. In embodiments, a testing service is proposed that focuses on the interoperability testing process of network services and SFC instead of performance. The proposed service has a modular architecture, which makes implementation easier and opens more opportunities for network operators to adapt to the NFV system. The examples focus on the implementation process with example test cases to illustrate feasibility.

Designing a test service according to a modular architecture is one of the key principles to implement, test and tune the modules (components) of the embodiments while maintaining custom functionality and extensibility. In addition, the following design principles are proposed to increase the possibility of service adaptation testing in many practical use cases.

Testing and debugging: Since all components of the embodiments operate on their own, dependency problems can be minimized. This keeps each component separate from each other, making it quick and easy to test and debug each component.

Extensibility: All components of the embodiments can be linked to an abstraction layer to help add new functionality to the framework based on specific use cases. You can then connect the new functionality to the test service by connecting to that layer of abstraction.

Standardized communication message format: Communication messages of each component can be standardized for compatibility. For example, according to embodiments, the format of the notification message sent by the agent and the controller may be set to be the same as the header.

Interoperability: All components of the embodiments are autonomous, but the system is designed to meet some common restoration requirements. Accordingly, components can be harmoniously tuned in the embodiments.

Examples focus on VNF interoperability, orchestration and dependency testing. Test targets may include SFC accuracy, VNF interoperability, and VNF dependencies. The framework can also support automation, scalability, scalability, multi-tenancy and multiple clouds.

A test apparatus is implemented based on the design principles discussed above, so that the SFC shown in FIG. 6 can be tested.

The tested SFC may be a network service including one firewall (VNF1) and one content filtering (VNF2). Source and destination can be HTTP clients. The SFC can operate so that traffic destined for ports 80 and 8080 from the client to the server goes through VNF1 and VNF2. The rules of VNF1 and VNF2 may be as follows.

-Allow traffic to port 80 of the server (VNF1, VNF2)

-Block traffic to port 8080 of the server (VNF1)

-Block access to http: // <HTTP ServerAddr>/restricted (VNF2)

In this case, it can be used for implementation through the configurations listed in Table 1 below.

In this case, there may be the following prerequisites.

-All VNFs, clients, servers and SFCs will be deployed in advance.

-VNF1, VNF2, client and server must have pre-installed modules according to the embodiment.

-The test controller must be running on the same Devstack host.

-The management IP address of the client, server, VNF1, and VNF2 must be known in advance.

In this case, the criteria provided by the SFC of FIG. 6 may correspond to the target as follows.

-Port 80 open. Client: Request on server port 80. VNF1: There is a packet. VNF2: There is a packet. Server: There is a packet.

-Port 8080 blocked. Client: Request on server port 8080. VNF1: There is a packet. VNF2: No packets. Server: No packets.

"/resticted" access denied. Client: HTTP request to the server. VNF1: There is a packet. VNF2: URL access denied. Server: No packets.

At this time, the results shown in Table 2 below may be generated.

7 is a diagram illustrating a procedure for testing interoperability of an NFV system according to an embodiment.

Referring to FIG. 7, a definition of a test profile may be received through a user interface in step 710, a test profile may be verified and stored in step 720, and a test execution command is received in step 730. May be, and after the test profile is parsed in step 740, it may be connected to the target platform. At this time, in step 745, a management driver required for the target NFV may be used. In step 750, the test indicated by the test profile may be executed. At this time, in step 755, an agent required for the VNF FUT may be installed in the VNF FUT using a management driver. Thereafter, the test result may be stored in the database in step 760, and the test result may be output through the user interface in step 770.

8 is a diagram illustrating a test apparatus for testing interoperability of an NFV system according to an embodiment.

Referring to FIG. 8, the test apparatus 800 includes a processor 810 and a memory 820.

The memory 820 is connected to the processor 810 and may store instructions executable by the processor 810, data to be calculated by the processor 810, or data processed by the processor 810. The memory 820 includes non-transitory computer-readable media, such as high-speed random access memory and/or non-volatile computer-readable storage media (e.g., one or more disk storage devices, flash memory devices, or other non-volatile solid state memory devices). Can include.

The processor 810 may execute instructions for executing one or more operations described with reference to FIGS. 1 to 7 and 9. For example, the processor 810 is for testing interoperability of a plurality of VNF function under test (FUT) corresponding to a test target among a plurality of virtual network functions (VNFs) constituting a series of service function chains (SFCs). A test profiler that creates a test case profile, installed in each VNF FUT of a plurality of VNF FUTs, collects metrics from each VNF FUT, and executes test commands based on the test case profile within each VNF , Parsing the test case profile to generate a test command, providing test commands to a plurality of test agents, receiving metrics collected from each VNF FUT from a plurality of test agents, and analyzing the received metrics It is possible to implement a test controller that generates test results regarding the interoperability of the VNF FUT.

In this case, the plurality of test agents may communicate with each other to test the plurality of VNF FUTs to exchange test data including at least one of throughput, package loss, and service path accuracy. In addition, the test for interoperability of the plurality of VNF FUTs may include at least one of a test for a life cycle of each VNF, a test for a dependency of each VNF, and a test for an orchestration of an SFC.

According to an embodiment, the test controller includes a profile parser that parses a test profile into objects and test metrics, a VNF test agent driver that communicates with a plurality of test agents to provide a test command or receives a metric, a plurality of To support VNF FUTs running on different types of NFV systems among VNF FUTs, a management driver that installs multiple test agents into each VNF FUT with each driver of a plurality of test agents, and coordinates the test procedure for test cases It may include a controller engine. In addition, the test controller may inject a defect corresponding to the test case profile into at least some of the plurality of VNF FUTs corresponding to at least some of the test agents through at least some of the test agents.

9 is a diagram showing an NFV architecture according to an embodiment.

Network Functional Virtualization (NFV) architecture is 1) Virtual Network Function (VNF), which is a software implementation version of the network function, 2) NFV Infrastructure (NFV Infrastructure) including hardware and software components on which the VNF is deployed, 3) NFV Orchestrator (NFVO) ), VNFM (VNF Manager) and VIM (Virtualized Infrastructure Manager), and MANO (NFV Management and Orchestration) that organizes and manages NFVI resources and the lifecycle of VNF.

The NFV architecture can be largely divided into functional blocks and reference points. First, the functional blocks include VNF, EM, NFVI, VIM, NFVO, VNFM, Service, VNF and Infrastructure Description and OSS/BSS, and reference points are VI-ha, Vn-Nf, Or-Vnfm, Vi-Vnfm, Or -Vi, Nf-Vi, Os-Ma and Ve-Vnfm.

EM (Element Management) is an entity that performs VNF-related configuration and monitoring functions and has logs for them. Through EM, defect detection, security, performance measurement, and configuration of VNF are performed. OSS/BSS refers to a network operator's service operation and business support system.

NFVI refers to all physical and logical elements for management and execution of the VNF from the point of deployment of the VNF. In other words, it refers to an entity that provides resources through the virtualization stage with physical elements. From a VNF point of view, it is not necessary to separate physical and logical elements because virtualized resources are used in the end.

There are two main components of NFVI. The first is hardware resources. That is, it refers to the actual physical resources that the VNF will use through the virtualization layer. The second is the virtualization layer. It abstracts the physical resources through the virtualization layer to enable flexible use of resources without restrictions.

VIM refers to the part that manages and controls computing, storage, network, etc., which are physical resources used by VNFs. It arranges and manages virtualized resources based on physical resources, and also performs management functions through visualization of NFVI through VIM and NFVI error monitoring and management through collection of defect information and resource status from NFVI.

VNFM performs management and control functions for lifecycle management of VNFs and interoperation between VNFs. NFVO has an orchestration function for resources and services. NFVO manages the collection of VNF-related resource usage information in terms of resources, and manages lifecycle and automation in terms of services.

The NFV reference point refers to the interface between the aforementioned components and consists of 8 interfaces. Vi-Ha is an interface used between the virtualization layer and hardware resources. It provides resources for VNFs and collects state information on hardware. Vn-Nf is an interface used between VNF and NFVI, and is used for NFVI to provide resources to VNF. Or-Vnfm is an interface used between NFVO and VNF manager. It is used when VNFM makes resource-related requests (user authentication, validity, reservation, allocation) to NFVO, or when NFVO sends configuration information to VNFM. It is also used when collecting VNF information for network service lifecycle management.

Vi-Vnfm is an interface used between VIM and VNFM, and is used when VNFM requests VIM to allocate resources, configures virtualized hardware resources, and exchanges status information. OR-Vi is an interface used when NFVO makes resource reservations or requests allocation of resources to VIM. This interface is also used to exchange virtualized hardware resource configuration and status information. Nf-Vi is an interface defined in the connection between VIM and NFVI, and is used when responding to a resource allocation request, transferring resource status information, or configuring hardware resources.

Ve-Vnfm is an interface defined between VNF/EM and VNFM, and is used when a request related to VNF lifecycle management is required, configuration and event related information is transferred, or status information for network service lifecycle management is exchanged. do. Os-Ma is an interface defined between OSS/BSS and NFVO. Requests related to network service lifecycle management, requests related to VNF lifecycle management, status information related to NFV, management policy delivery, data analysis exchange, NFV related. It is used to communicate billing and usage records, and to exchange information related to NFVI functions and inventory.

A module in the present specification may mean hardware capable of performing functions and operations according to each name described in the present specification, or may mean a computer program code capable of performing a specific function and operation. Or, it may mean an electronic recording medium, for example, a processor or a microprocessor in which a computer program code capable of performing a specific function and operation is mounted. In other words, the module may mean a functional and/or structural combination of hardware for performing the technical idea of the present invention and/or software for driving the hardware.

The apparatus described above may be implemented as a hardware component, a software component, and/or a combination of a hardware component and a software component. For example, the devices and components described in the embodiments are, for example, a processor, a controller, an Arithmetic Logic Unit (ALU), a digital signal processor, a microcomputer, a Field Programmable Gate Array (FPGA). , PLU (Programmable Logic Unit), a microprocessor, or any other device capable of executing and responding to instructions, it may be implemented using one or more general purpose computers or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications executed on the operating system. Further, the processing device may access, store, manipulate, process, and generate data in response to the execution of software. For the convenience of understanding, although it is sometimes described that one processing device is used, one of ordinary skill in the art, the processing device is a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of these, configuring the processing unit to operate as desired or processed independently or collectively. You can command the device. Software and/or data may be interpreted by a processing device or, to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. , Or may be permanently or temporarily embodyed in a transmitted signal wave. The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -A hardware device specially configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

As described above, although the embodiments have been described by the limited embodiments and drawings, various modifications and variations are possible from the above description to those of ordinary skill in the art. For example, the described techniques are performed in a different order from the described method, and/or components such as systems, structures, devices, circuits, etc. described are combined or combined in a form different from the described method, or other components Alternatively, even if substituted or substituted by an equivalent, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and those equivalent to the claims also fall within the scope of the claims to be described later.

Claims (10)

In a test apparatus for testing interoperability of a network function virtualization (NFV) system,
A test profiler that creates a test case profile to test the interoperability of a plurality of VNF function under tests (FUTs) corresponding to a test target among a plurality of virtual network functions (VNFs) constituting a series of service function chains (SFCs). ;
A plurality of test agents installed in each VNF FUT of the plurality of VNF FUTs, collecting metrics from each of the VNF FUTs, and executing a test command based on the test case profile in each of the VNFs; And
Parsing the test case profile to generate the test command, providing the test command to the plurality of test agents, receiving the metric collected in each VNF FUT from the plurality of test agents, and receiving the A test controller that analyzes the generated metric and generates a test result regarding the interoperability of the plurality of VNF FUTs
Test device comprising a.
The method of claim 1,
The plurality of test agents communicate with each other to test the plurality of VNF FUTs to exchange test data including at least one of throughput, package loss, and service path accuracy,
Testing device.
The method of claim 1,
The test for the interoperability of the plurality of VNF FUTs
Including at least one of a test for the life cycle of each VNF, a test for dependency of each VNF, and a test for orchestration of the SFC,
Testing device.
The method of claim 1,
The test controller
A profile parser that parses the test profile into objects and test metrics,
A VNF test agent driver that communicates with the plurality of test agents to provide the test command or receive the metric,
A management driver for installing the plurality of test agents in each of the VNF FUTs with drivers of each of the plurality of test agents to support VNF FUTs driven in different types of NFV systems among the plurality of VNF FUTs, and
Including a controller engine to orchestrate a test procedure for the test case,
Testing device.
The method of claim 1,
The test controller
Injecting a defect corresponding to the test case profile into at least a part of the plurality of VNF FUTs corresponding to the at least part of the test agents through at least a part of the test agents,
Testing device.
In a test apparatus for testing interoperability of a network function virtualization (NFV) system,
Processor; And
A memory containing instructions executable in the processor
Including,
When the instructions are executed in the processor, the processor
A test profiler that creates a test case profile to test the interoperability of a plurality of VNF function under tests (FUTs) corresponding to a test target among a plurality of virtual network functions (VNFs) constituting a series of service function chains (SFCs). ,
A plurality of test agents installed in each VNF FUT of the plurality of VNF FUTs, collecting metrics from each of the VNF FUTs, and executing a test command based on the test case profile in each of the VNFs, and
Parsing the test case profile to generate the test command, providing the test command to the plurality of test agents, receiving the metric collected in each VNF FUT from the plurality of test agents, and receiving the A test controller that analyzes the generated metric and generates a test result regarding the interoperability of the plurality of VNF FUTs
To implement, test device.
The method of claim 6,
The plurality of test agents communicate with each other to test the plurality of VNF FUTs to exchange test data including at least one of throughput, package loss, and service path accuracy,
Testing device.
The method of claim 6,
The test for the interoperability of the plurality of VNF FUTs
Including at least one of a test for the life cycle of each VNF, a test for dependency of each VNF, and a test for orchestration of the SFC,
Testing device.
The method of claim 6,
The test controller
A profile parser that parses the test profile into objects and test metrics,
A VNF test agent driver that communicates with the plurality of test agents to provide the test command or receive the metric,
A management driver for installing the plurality of test agents in each of the VNF FUTs with drivers of each of the plurality of test agents to support VNF FUTs driven in different types of NFV systems among the plurality of VNF FUTs, and
Including a controller engine to orchestrate a test procedure for the test case,
Testing device.
The method of claim 6,
The test controller
Injecting a defect corresponding to the test case profile into at least a part of the plurality of VNF FUTs corresponding to the at least part of the test agents through at least a part of the test agents,
Testing device.

Images