Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Appendix: Description of the vTA VNF and Its Requirements

  1. The vTA VNF is capable of running in a plain, “vanilla” environment using a standard cloud configuration and orchestration based on VirtualBox. There might be some limitations in terms of performance and also some minor limitations in terms of jitter and delay accuracy, depending on your VirtualBox infrastructure and how heavily loaded it is. However, for early proof-of-concepts and evaluations, this should not be a major issue. To obtain line rate packet generation and optimal usage of your specific hypervisor environment, an integration project would be required.
  2. The vTA VNF consists of a single stand-alone VNF. However, the VNF must be able to connect and communicate securely with Paragon Active Assurance Control Center, which is not a VNF. Control Center is readily available in the public cloud (in addition to private cloud installations), something which simplifies test and evaluation projects.
  3. Interfaces trust the natural OS bootstrap order in terms of how they are identified.
  4. The performance is dependent on the underlying hardware. The more powerful the hardware, the higher the performance. For a 3 GHz quad-core processor, achievable performance is up to 10 Gbit/s using five concurrent unidirectional TCP streams.
  5. The minimum recommended specification is: 1 vCPU, 512 MB RAM, and 2 GB of block storage. The latter two settings are in the OVF file which is part of an OVA format vTA image, as mentioned in the section vTA Image.
  6. It is assumed that a generic VNF manager which is not part of the Paragon Active Assurance solution does the instantiation, scaling, and termination of the vTA VNF.
  7. The vTA VNF needs to register with Control Center to receive commands. For public cloud Control Center scenarios, the VNF needs connectivity to the Internet from the eth0 interface. For plug-and-play configuration of the VNF, DHCP should be used for IP addressing of the vTA’s interfaces, as well as for assignment of an available DNS server.
  8. The VNF will resolve the Control Center address and initiate an outbound connection using TCP. (For details, see the Control Center support documentation.) To successfully connect and authenticate itself to the correct Paragon Active Assurance account, the VNF needs to have credentials provided to it through the vTA virtual machine console in VirtualBox, as detailed in the chapter Setting Up a Virtual Test Agent in VirtualBox. Once the VNF has connected to Control Center, it can be controlled either via a web browser or through the Paragon Active Assurance cloud API to start monitoring user experience KPIs, conduct a service turn-up test, or perform on-demand troubleshooting tests. The connection is an encrypted OpenVPN connection.
  9. The vTA VNF also requires synchronization to an NTP server in order to achieve accurate delay and jitter measurements. By default, Test Agents will synchronize their internal clock to time.google.com, a service provided by Google; however, any NTP server (internal or external) can be used.
  10. Rescaling of the VNF again needs to be handled by a generic VNF manager (compare paragraph 6). For example, if the available connection bandwidth is increased, the VNF might need to be scaled up to be able to push enough bandwidth through the link for testing purposes.