Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Two factors affecting the deployment pace of SDN and NFV technologies

Service providers deploy SDN and NFV technologies at different paces for two main reasons: issues with the organization's business case and slow-going standards progress.

Reading about software-defined networking and network functions virtualization these days almost seems to be an...

exercise in contradictions. Some articles tout explosive progress in SDN and NFV deployments, while others say operators are losing confidence that either technology will really address their current and future needs. Clearly, some operators are more successful with SDN and NFV technologies than others. Why? More importantly, do some operators have special insight into these technologies that the rest of the industry needs to learn?

Historically, about seven out of eight new technologies that reach the lab-trial stage and are widely supported by standards activities never actually deploy in live networks. The operators themselves believe two factors are responsible for most of this lab-to-network transition failure:

  • The first is standards don't closely tie to the business case, so progress doesn't necessarily create the financial drivers needed for actual deployment.
  • The second is developing and approving new network standards takes far too long, given the internet's ability to deliver workable implementations of services in just a few months.

These two factors affect service providers differently, creating different paces of adoption. Other issues also combine with these two to create radically different adoption rates that vary by operator.

SDN and NFV issues that stem from the business case

To start with business-case issues, all operators, at the highest level, are trying to come to terms with the shrinking margin between revenue and profit per bit. In highly competitive markets, this has already forced reductions in capital spending. Around 2008, operators began looking for a solution, and the broad goals of these early efforts were to make network services more agile to create and cheaper to operate. Since that sounds almost exactly like the NFV and SDN missions, you'd think everyone would have jumped on both technologies immediately.

Historically, about seven out of eight new technologies that reach the lab-trial stage and are widely supported by standards activities never actually deploy in live networks.

The problem with that assumption is transforming service agility and cost through infrastructure changes works only to the extent that you change your infrastructure. No operator is prepared to forklift a quarter-trillion-dollar global infrastructure and put in something largely unproven. Not all operators have the same constraints here, however. Operators that are greenfield providers, either setting up in a new geography or as totally new operators, have no existing infrastructure to pull out.

And operators that rely on wholesale infrastructure, like mobile virtual network operators or managed service providers (MSPs), may have no legacy network to replace. Masergy, one of the most prominent NFV successes, is an MSP that needs to adopt NFV technology only in the edge devices it provides. Rudimentary NFV technology can support that mission.

AT&T provides another example of a business issue that creates SDN and NFV leaders and followers. Well before SDN or NFV specifications were even maturing, AT&T was trying to control network cost by reducing vendor ability to create proprietary silos. Its Domain 2.0 architecture broke networking down into functional elements and named at least three bidders in each area, but required the areas be linked only through standards.

That proved difficult, and AT&T devised its own architecture -- its Enhanced Control, Orchestration, Management and Policy -- to provide an open source glue to link Domain 2.0 areas. SDN and NFV were part of the framework, which resulted in AT&T moving on SDN and NFV faster than operators that didn't have business goals driving Domain 2.0.

Standards activity at a crawl

The second main reason why operators adopt SDN and NFV technologies at different paces is the slow pace of standards activity. Both SDN and NFV technologies have been around for four years or more, yet the work of standards bodies is ongoing. Vendors and operators have long been wary of prestandard implementations of new technologies because they feared they'd lock themselves into what turned out to be a proprietary service. But some vendors elect to take this risk, for three reasons.

Extreme need is the first reason to jump into something before standards are stabilized. In Europe -- where many competing network operators look at every low-hanging fruit of opportunity -- SDN and NFV can provide differentiated services or lower costs. As a result, we see some business service deployments in Europe based on current standards.

The second reason for an early jump to SDN or NFV technologies is limited service objectives. SDN and NFV standards lack a mature model for operations integration and support for legacy devices as part of the services. But if an operator doesn't have a formal operations and business support system structure with which to integrate, or doesn't have to build services that include legacy devices, the maturity issues won't affect them. Managed service and virtual customer premises equipment fit both these constraints.

The final reason to accelerate SDN or NFV adoption ahead of standards is the expectation of a major infrastructure change in the near term. Currently, the largest source of this future-shock stimulus is 5G wireless. Any time infrastructure changes, it's easier to adopt new technology, because modernization is already committed and funded by the driver of the change. In the case of 5G, mobile operators know virtualization will play a major role in three years or less, so it makes sense to start to move 4G infrastructure investment toward SDN and NFV in preparation.

Technology drivers that affect SDN and NFV deployment

Technology factors can also affect the pace at which operators deploy SDN and NFV technologies. The most significant of these is the willingness of operators to develop their own versions. AT&T and Telefónica have both developed full or partial models of SDN or NFV deployment on their own, drawing inspiration and sometimes components from open source projects. Other operators, like China Mobile Communications Corp., have been instrumental in driving open source projects that are taking a broader view of SDN and NFV than the standards bodies have taken alone. Because these projects have greater functional breadth, they touch more aspects of the service lifecycle and can deliver a business case more easily.

Will there always be such differences in the level of commitment to SDN and NFV technologies? Probably not. As standards, open source, vendor tools and operator experience expand, growth will eliminate the pockets of specialized needs and technology plans, and the industry will tend to move more in lockstep. That's the sign of maturity SDN and NFV proponents hope to see -- and soon.

Next Steps

A primer for SDN and NFV

NFV helps simplify network management

Three advances helping NFV's business case

This was last published in January 2017

Dig Deeper on SDN network virtualization



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What other factors might be affecting SDN and NFV deployments?
No technology exists in a vacuum, and the context of SDN/NFV has to be understood in the context increased agility requiring greater degrees of automation, and cloudification. These ideas are changing how SPs need to structure their organisations, with the inevitable concerns about what roles people will play. Simply put, the very people who are being relied on to deploy automation, integration with cloud systems and virtual services a la SDN/NFV are those most affected by it.