— Palani Chinnakannan 2014/11/10 20:31

A virtual provider edge (vPE) is a virtual network function that provides the traditional provider edge functionality in the virtual environment. This project provides the testing methodology and test cases for integration testing of the OPNFV platform to host a generic VNF like vPE and measure the performance characteristics associated with the vPE traffic patterns. This project uses a L3VPN connectivity over a MPLS backbone network to provide private and secure communication to all devices belonging to a tenant located at multiple sites. The document covers the following elements:

• vPE Topology
• High level Software Architecture
• Hardware Requirements
• Software Components and Requirements
• NFVI Platform Function Test Cases
• Platform Performance Test cases

The Basic vPE topology comprises of a single instance virtualized provider edge (vPE VNF) that provides L3VPN based connectivity between all sites of a given tenant. Advanced configuration comprises of three or more vPE VNFs providing connectivity to multiple sites belonging to a customer, with the sites distributed between the vPE VNFs. In both cases, multiple tenants are emulated each with 4 or more sites to provide a realistic traffic pattern to stress the NFVI infrastructure through the vPE VNFs. In the basic case, the vPE VNF is hosted on a single server, while in the advanced case, the vPE VNFs are tested on multiple servers, The environment also provides the traffic flow between the CE devices belonging to a tenant.

The following figure provides the basic topology for the vPE use case functional and performance testing.

The following are the salient aspect of this figure:

• The SUT (system under test) is the OPNFV platform as well as some elements of the VNF (vPE) like the QEMU, virtio etc., that are outside the bounds of the guest kernel, providing the interface to the VNF.
• A single instance of a open source or vendor provide vPE is instantiated on the OPNFV platform.
• The logical topology comprises of 4 tenants name VPN1 through VPN4. Each tenant owns four or more VPN sites, half of them directly connected to the VNF under test (VPNx-1, VPNx-2, …) and the rest connected to a emulated PE router (VPNx-3, VPNx-4, …). The above figure shows just four sites per tenant. However, the sites are scaled up in the performance testing to meet the traffic profiles listed therein. This provides enough routes to stress the vPE VNF instance, which in turn stresses the OPNFV platform.
• The logical topology of CE/PE devices are emulated using IXIA device with two ports allocated for one instance of this topology. The tests performed creates multiple instances of this topology for reliability testing and therefore the test requires 8 to 16 IXIA ports.

The following table provides the deployment configuration for the basic vPE topology test case. This topology is exercised multiple times during functional testing for studying the robustness of the OPNFV platform. Therefore, the numbers specified in the following table are scaled as per the number of instances instantiated.

The following figure provides the advanced topology for the vPE use case functional and performance testing.

The following are the salient aspects of the above topology:

• The topology consists of four vPE VNFs that are instantiated on the SUT. The test cases identified later specifies how the four instances are deployed. For example, one the same physical server or spread across 4 servers.
• The CE devices (emulated) are distributed across the four instances.
• The focus of this topology is to study the behavior of the OPNFV platform under multiple VNF deployments.

The following table provides the performance tuning characteristics. Some of these characteristics are varied in the test cases to study the behavior of the OPNFV platform. This table requires a in depth review and ongoing updates to select the best performance tuning characteristics.

The following figure is the proposed architecture for the vPE functional and performance testing use cases.

The following are the key aspects of the above architecture:

• The architecture is based on the ETSI NFV ISG functional blocks without the reference points.
• The VIM is decomposed into two major blocks, Openstack and Open Daylight Controller (ODL)
• The ODL controller is driven by the Openstack Neutron component. As shown, in the figure the neutron plugin and its agent communicate with the ODL controller and do not perform any interaction with the compute nodes.
• The ODL controller is responsible for setting up the compute nodes, programming the OVS switches or any other relevant element. This is indicated using the reference points A,B,C,D.
• The VNF instantiated on the NFVI is the vPE VNF, obviously, any other VNF can also be adopted into this architecture. The VNF is configured using a configuration component that is traditionally part of the EMS.

The following table provides the hardware elements required for the project.

== TODO: Add more details on the server characteristics, Switches, Ports etc.

The following table provides a list of high level functional test cases. We need to agree on the columns used and if we need to add any more columns. The following defines the column headers.

• Test Id: Identifier for the Test and starts with a letter 'F' for functional and 'P' for performance. Contains a 3 digit test suite identifier followed by a 3 digit sub test suite or test case identifier. In case of sub test suite, a further 3 digit number identifies the test case.
• Title: A brief one liner for the test suite or test case
• Type: Suite or Test case (Redundant); however, the Test Id may appear independently in threads, docs etc.
• Description/Procedure: In case of test suite, description provides the suite purpose, in case of Test case, the procedure explains clearly what needs to performed. If required use a link to document the exact steps.
• Pass/Fail: The criterion for detecting a pass or a fail. Documenting both pass conditions and failure conditions must be listed.
• Target Release: The OPNFV Release being targeted.
• Automation Required: Defines if automation is a must or not. If Automation is a must have required then providing a pointer to a wiki that automates this will be useful.

The vPE performance testing and measurement covers the following aspects of a vPE VNF deployment in an environment that simulates real traffic profiles:

• Topology
• Basic Traffic profiles
• Advanced Traffic Profiles

The topology required for the performance measurement is specified above.

The following table provides the test suites for the vPE performance testing.