Virtualized testing keeps pace with NFV cost savings
Even in a single metropolitan area, service providers deploy dozens of routers and appliances with custom ASICs, running millions of lines of code and performing specialized functions. The costs involved in increasing capacity raises the cost per gigabyte, and is increased still further by operational expenditure for on-going management of services, power consumption, and the cost of employing the increasingly rare but necessary skills. Given the complexity of today’s networks, the provision of a new service, even a simple one, to meet customer demand can take months.
The success of virtualization methodologies that have provided flexibility in IT environments is encouraging network operators to adopt similar techniques. Network Functions Virtualization (NFV) has become a hot topic as a potential solution.
The benefits of NFV
NFV adapts IT virtualization technology to provision many of the functions provided by traditional network equipment on industry-standard high-volume servers, switches and storage located in data centres, network nodes or in end-user premises. Instead of deploying separate boxes dedicated to specific network functions such as edge routing, BNG, DPI, IPSec gateways, mobility gateways, and security functions, the same functions are run as virtual machines in ordinary high power servers.
This offers immediate benefits. Fewer boxes means lower capital expenditure and less power consumption, while software flexibility allows faster roll-out of new services with less risk. Other benefits include:
- Multi-version and multi-tenancy network appliances sharing resources;
- Services targeted on geography or customer sets;
- Greater openness for pure software firms, small players and academia to join the ecosystem.
Potential use cases include:
- Virtualized content distribution networks would allow on-demand service scaling;
- Network nodes can now support BNG, PE routing, and CG-NAT on standard high-volume servers;
- Residential gateways and set-top boxes can be virtualized;
- Virtualizing the mobile packet core functionality allows more flexibility to manage increasing traffic and dynamic loads;
- Virtualized security capabilities – firewalls, IDS, IPS and WAN acceleration deployed in a server on the customer premises – means fewer dedicated appliances and fewer visits to site;
- Software-based DPI implementations can provide traffic analysis and reporting of service security and quality.
The challenges of testing NFV
The benefits are significant and highly attractive, nevertheless replacing thousands of specialized routers and appliances with NFV-based servers presents quite a challenge. For a start, no-one likes to junk costly equipment that still promises years of good service before it becomes obsolete, so migration to NFV will be subject to depreciation of legacy equipment. In addition, staff skilled in traditional network deployments, CLIs and element management systems will need to be re- trained to work with cloud-management systems.
Above all there is the challenge of the unexpected when making any change to a complex system. However good the virtualization process looks on paper, what matters is how it works in practice. If the upgraded system fails or performs below expectation, it will result in angry customers, lost revenue and ultimately discourage the adoption of NFV. So everything — virtualized functions, virtual environments and end-to-end services – must be thoroughly validated by testing before deployment.
What are we testing for? The end user is mainly interested in performance and quality of experience – they want the service they have paid for to achieve its SLAs. They don’t really care whether the BNG, routing, CDN or mobility functionalities are virtualized or running in purpose-built appliances. For operators, performance and quality are also important, but there are additional concerns regarding the control-plane and data-plane scale, and whether, for example the number of PPPoE sessions, throughput and forwarding rates, number of MPLS tunnels and routes supported are broadly similar between physical and virtual environments.
The new, virtualized network may be reducing costs, but it must not in any way deliver worse service than the corresponding physical environment. Operators and users accustomed to 99.999% availability will expect the same for virtual environments. So node, link and service failures must be detected within milliseconds and corrective action taken promptly without degradation of services.
When virtual machines are migrated between servers, any loss of packets or services must not break the relevant SLAs. Instantiating or deleting VMs can affect the performance of existing VMs as well as services on the server, so new VMs must be assigned the appropriate number of compute cores and storage without degrading existing services. It is also critically important to test the virtual environment, including the orchestrator and cloud-management system.
Pre-deployment and turn-up testing of the virtualized network functions mean that they can be rolled out with confidence, but it is also important to monitor services and network functions on either an on-going, passive basis or an as-needed, active basis to make sure that the system can cope with evolving demand and unexpected surges. Monitoring virtual environments is more complex than their physical equivalents, because operators need to tap into either an entire service chain or just a subset of that service chain. For active monitoring, a connection between the monitoring end-points must also be created on an on-demand basis, again without degrading the performance of other functions that are not being monitored in that environment.
Physical or virtual test methodology?
In principle there is no difference between testing a physical network function or the same function virtualized in a server. If the virtual machine in the server is doing the same job, then you can simply run the same test on it.
Figure 1. Click image to enlarge.
Figure 1 illustrates this with a physical test system used to validate virtual functions in a standard server. In this example PPPoE clients, BGP routers and MPLS tunnels are emulated in the test systems, and connected to peer sessions in the server using control plane protocols, at the same time as user data-plane streams are emulated for originating and terminating traffic. Data plane measurements could include: latency on (tens of thousands of data streams); throughput and forwarding rate; packet delay variation, dropped and corrupted frames. On the control plane, states and state transitions for hundreds of control plane protocols, error notifications, and the scaling of multiple simultaneous protocols are measured.
Figure 2. Click image to enlarge.
In Figure 2, however, we see a service chain that comprises a virtual load balancer, virtual firewall and virtual CE router, being tested using virtual test appliances to emulate realistic user behaviour and originate and terminate stateful HTTP, FTP and video traffic. Metrics being measured can include: sustained data transfer rates; number and speed of connection and transactions per second; round trip time; denial of service handling; packet loss and leakage across service chains and time between VM instantiation and first available packet.
What are the pros and cons of these two approaches – physical or virtual?
Physical testing is more expensive and labour intensive. Considering the importance of cost savings as a driver for NFV, there is a similar need to reduce the cost of testing. Virtual test appliances are an attractive solution, even allowing the creation of an entire test lab in a single server.
There is however the possibility that the virtual test software, by consuming some of the server’s processing resources, will have an effect on the measured performance of the NFV in the server. While this might be compensated for under laboratory test conditions, physical test appliances are still recommended for virtual environments demanding the highest levels of data-plane performance (line-rate) or microsecond-level timing accuracy.
In most other cases, however, virtual test systems are every bit as good as physical appliances. Virtual test appliances are ideal for organizations that need the flexibility of testing network functions on multiple, geographically disparate servers. They are also the right choice for organizations that need to test individual network functions within a service chain, or organizations that are on a limited budget.
A White Paper Testing Methodologies for Validating NFV Environments is available from the Spirent website that gives more examples of testing using virtual appliances – these include VM migration and stability testing. The paper is available at: https://www.spirent.com/White-Papers/Broadband/PAB/Validate_NFV_Environments
Conclusion
Network operators are looking for effective ways to scale their services while keeping down costs to maintain revenue growth. NFV has emerged as a promising solution, enabling service providers to deploy large numbers of virtualized network functions on industry-standard high-performance servers. As well as cutting both operational and capital expenditure, operators benefit from shortened time to market. Other advantages for the industry include the growth in independent software vendors, and easier development and deployment of new revenue-generating features.
In theory, virtualised network functions perform exactly as their physical counterparts. In practice such complex systems always require thorough testing under simulated but realistic operating conditions to eliminate unexpected phenomena arising out of complexity. So NFV functions and infrastructure must be stringently tested in the lab before turn up of services, in order to minimize network outages in the final network. It is also necessary to monitor performance on an on-going basis to ensure continued good service.
With the massive scaling of today’s networks, testing at this level could add considerable cost – although, of course, the long-term cost of not testing might be far greater. The use of virtual test appliances, however, greatly reduces this overhead, both in terms of capital outlay and labour. This approach is recommended for all but the most critical functions, where a certain proportion of physical testing would still be recommended.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
