Torbz - Fotolia


Four steps to make SDN and NFV proof-of-concept trials meaningful

The results of SDN and NFV proof-of-concept trials can advance network deployments, but they often fall short. Check out four steps that can make POC trials more meaningful.

Nearly every network operator who makes a change in technology or enters a new service area does so after a layered set of trials that start in a lab and end up in a live customer environment. The notion of trials supports testing or proving something, so it's surprising the biggest problem with proof-of-concept, or POC, trials is often their failure to advance the technology they're supposed to be proving.

Currently, the results of only one in eight SDN or NFV trials lead to a meaningful network deployment. Enterprises and network vendors want proof that software-defined networking (SDN) and network functions virtualization (NFV) can actually benefit them. The challenges include: How can the networking industry do better, and how can it turn SDN and NFV proof-of-concept trials into something more than science projects?

When a new technology comes along, it's natural to focus first on the simple question of whether the technology works. Can I really host a virtual function or control forwarding through OpenFlow from a central SDN controller? Those are good questions. But even answering yes won't prove the concept -- only the technology. And network operators say relatively few technologies fail the simple "does it work?" test. 

Most tests fail because the technology doesn't generate enough value to justify deploying it. According to operators, many of these issues could be addressed in a POC trial if the validation of functionality focused on the specific features needed to make the business case for deployment. Making that happen means changing how POCs are conducted.

Step one: Define the SDN and NFV success chain

Most tests fail because the technology doesn't generate enough value to justify deploying it.

The first step in meaningful SDN and NFV proof-of-concept trials is to define the success chain, which means defining the things the technology must do to be deemed successful. Operators also need to define the set of conditions that, if true, will drive adoption of the technology. This process is often called making the business case, but it only starts with the business case. Once you know what conditions will drive success, you need to run one or more trials to validate whether those conditions can be met.

Three main drivers exist to gauge the success of SDN and NFV: the reduction of capital expenditures, the reduction of operations costs and increased revenue. A useful SDN or NFV proof-of-concept test should target one or more of these drivers, as well as take steps to prove whether SDN or NFV can really support them and at what level.

Step two: Establish an SDN and NFV POC baseline

The second step in creating useful POC trials is to establish a baseline. Operators complain vendors rely on cost reduction when they don't know what the current costs are, or how much of the costs can actually be addressed or changed. If a specific SDN or NFV strategy can reduce deployment costs by 20%, for example, operators need to know what the current deployment costs are. If it's high, then 20% is a big enough number to affect overall operator profits. If it's low, then taking a technology risk to reduce it by 20% isn't going to do much good.

On the revenue side, the biggest problem is the lack of a realistic total addressable market figure. The market for something like virtual customer premise equipment (vCPE) depends on the number of target customers, for example. Business services must attract business customers, so having a census of the number of businesses and the percentage of them that actually use computer systems and networks is essential. You can invent services with a new technology, but not customers willing to buy them.

Step three: Include the total service lifecycle process

The third step in creating a successful POC trial is to include the total service lifecycle process and all its elements in the test. Services begin with service architecture, followed by building a catalog of services that can be ordered. Next, portals or customer service reps use those catalogs to sell and deploy the services, as well as bill for them. A new technology will affect all of these steps. Therefore, in order to calculate net costs and benefits, POC trials must provide insight into the nature and magnitude of their effect.

This step is where current SDN and NFV proof-of-concept tests fall down and where vendors argue the most against using this POC methodology. You can understand why someone would say, "But we have to prove SDN or NFV work, don't we?" Yes, but only if the proof develops in a context where it can generate one or more of those three drivers: reducing capital expenses, reducing operations costs or increasing revenue. The functionality of a new device or technology will never justify deploying it in your network; you have to justify technology of any sort with a return on investment.

Step four: Guard against the whack-a-mole problem

The final step in running an effective POC trial is to guard against the whack-a-mole problem. Often, new technologies reduce costs or improve benefits in one area, only to create additional costs or risks in another. A concept is proved only if its net effect results in a driver for the tested technology. Unexpected or ignored effects of a new technology can reduce or even eradicate its benefits. Both SDN and NFV demonstrate this in different ways.

For NFV, few would argue operational complications arise when two or three cloud-hosted components, connected by virtual networks, replace a single box. Therefore, NFV requires a level of service automation that ensures new changes are at least as cheap to operate as the old methods. The argument that replacing a broken function is cheaper than replacing a failed device is only part of the story. A well-designed SDN or NFV proof-of-concept trial can try to find out important information on how frequently a device needs to be replaced and how often the more complicated vCPE structure might fail.

Simple technology validation will almost always result in a narrow POC scope, which looks good because testing is simplified. For SDN and NFV POCs to be useful, they have to lead operators out of the lab and into the field. The steps to make that happen must be taken early in the POC process -- otherwise, POCs will simply remain interesting science projects.

Next Steps

Is SDN already proven technology?

Making a business case for NFV

How can SDN and NFV help you?

This was last published in September 2016

Dig Deeper on Telecommunication networking