NFV too risky? Pursue network virtualization first

Unless telecommunications service providers look beyond the hierarchical ‘terminal to host’ model of the Internet, they will be taking huge risks in their NFV network implementations.

Guest author

June 9, 2016

7 Min Read
NFV too risky? Pursue network virtualization first periodically invites expert third parties to share their views on the industry’s most pressing issues. In this piece Sue Rudd of Strategy Analytics looks at how operators can best prepare themselves for the move to NFV.

Telco Cloud Operators risk failure in Network Function Virtualization (NFV) unless they incorporate the capabilities of proven legacy networking platforms that go well beyond the limited centralized architecture of Data Center Cloud virtualization. Google and Amazon are insufficient models for global public network virtualization.

Unless telecommunications service providers look beyond the hierarchical ‘terminal to host’ model of the Internet, they will be taking huge risks in their NFV network implementations. To manage the risky NFV evolution, operators should first leverage currently available high performance virtualized networking platforms as they hone their operations.

Distributed Networking as the Paradigm for ‘Telco Cloud’ Network Virtualization

Virtualizing a ‘Telco Cloud’ is very different from virtualizing a centralized resource like a data center Cloud where ‘hosts’ accept requests from ‘terminals’ and send back responses. A true ‘Telco Cloud’ must operate network-wide to dynamically assign processes to processors and forward and control traffic based on agreed standards across global networks in real time. Strategy Analytics new report, ‘NFV too Risky? Pursue Network Virtualization First – How Five Independent Platforms meet 16 Operator Requirements Today,’ suggests that we look at how successful platforms already virtualize network in on ‘off the shelf’ hardware; and creates a checklist of capabilities that service providers may wish to include in their new Network Function Virtualization (NFV) service platform specifications. These go beyond functionality currently specified in NFV standards.

Operators need a paradigm for network virtualization that can allow NFV to evolve beyond the data center model. Without these capabilities it will be very difficult and risky for service providers to create the ‘Telco Cloud’.

Distributed Computing and Distributed Networking

It is very important to remember that the computing industry did not transition from mainframes to PCs directly – in the 1980s minicomputers introduced networks of distributed computing. That model – from which companies like VMware and HP Enterprise sprang – may offer a more relevant starting point than data centers do for a truly ‘distributed flat high performance cloud’. The ‘terminal to host’ client server model that emerged in the late 1980s led to an inherently centralized data center approach that is now embedded in today’s TCP/IP based Internet.

Network virtualization, however, demands a truly ‘flat’ distributed networking model where “the network is the computer” as John Gage of Sun Microsystems (now Oracle) noted in 1984. A key “aspect … is the ability of the network infrastructure to connect many systems together … to become a huge computing environment.” At that time, we did not have the connectivity and performance to create the global ‘Telco Cloud’ we are building today that supports ubiquitous services available everywhere and processing wherever it is needed.

The ‘Telco Cloud’ requires a global virtualized network infrastructure. And that global virtualized network infrastructure requires a highly modular scalable architecture that cannot be ‘retrofitted’ on top of hierarchical centralized ‘terminal to host’ systems. Operators need to minimize the risks of NFV by first pursuing proven scalable distributed networking platforms that now also meet NFV requirements.

Network Virtualization Platform Requirements

Platforms for network virtualization require far more than the ability to ‘spin up’ new instances of server based Virtual Machines (VMs). Specific capabilities must be built into the architecture of robust distributed services software networking platforms. These cannot be ‘added on top’ of traditional compute servers if they are to deliver low latency high reliability state aware global public network services.

Strategy Analytics has developed a list of 16 key requirements for such Network Virtualization Platforms that operators can use as initial criteria to compare alternative NFV capable platforms. In the chart below we also list likely applications for each requirement.

Sixteen Requirements for Virtualized Network Platforms

Requirements for Network Virtualizations Platform


Logically Centralized/Physically Distributed Proc.

Low Latency Solutions


Scale Elastically w/o loss of Performance or ΔLatency

High Availability/Capacity w. Performance at Scale


Capable of Event/Transaction handling

Deterministic/Guaranteed outcomes


Real Time OS interrupts at OS kernel

Match Proprietary Equipment Performance


‘State Aware’ at each node (Asynchronous State)

No lost Transactions/Calls/Sessions


Low Latency <10 milliseconds

Instant Network and User Service Response


Transport AND layer 2 Protocol Independent

Truly Platform and Network Access Agnostic


Real Time Info. For both Virtual & Physical Instances

Network & Service Awareness simultaneously


Parallel and Re-Entrant Service Chaining Options

Optimize Service Chain Performance/Clean-Up


Multiple Service Flows/Sessions that share Class of Service (CoS) Reqt. within a Network ‘Slice’

Allow operators to aggregate Real Time flows into Network ‘Slices’ for Efficient CoS Mgt. & ROI


Monitor and Manage Flows/Sessions in Real Time End to End (E2E)

Deliver both Service Awareness for CRM & CEM Options in Real Time


Context Awareness for multiple events Per User Flow e.g. Minimize database dips, replicated tasks etc.

Use shared Context to dramatically reduce overhead transactions and database delays etc.


Manage, Change & Store Software Image /Configuration for Instant Upgrade or Recovery

Ensure Service Release Control & Agility for small or large feature upgrades


Interprocess Communications Mechanisms for co-ordination of NFV Managers, SDN Controllers etc.

Operate Seamlessly across Multiple NFVM, SDN Controller Domains etc.


Interprocess Communications Mechanisms for co-ordination between Network Orchestration Domains

Operate Seamlessly across Multiple Network Orchestration Domains


Interprocess Communications Mechanisms for co-ordination of Service Orchestration Domains

Operate Seamlessly across Multiple Service Orchestration Domains

Source: Strategy Analytics, Wireless Networks and Platforms

The first six requirements above are ones that are already much discussed with respect to NFV platforms – Logical – not Physical – Centralization or Distribution (1), Scalability (2), Real Time Event/Interrupt Processing (3,4), State Awareness (5) and Low Latency (6). Others, relate to protocol independence (7), information exchange (8) and inter-process communication protocols for co-ordination between Controllers and Orchestration Domains (14,15 and 16).

The remainder relate to the Software Architecture for parallel and re-entrant code processing for Service Chaining (9), Creating and Managing Flows (10, 11), Sharing Context Information (12) and Software Configuration for Network Monitoring and Service Orchestration.

Embedded throughout the list are implications for software methodology that go from OS kernel interrupts (4) to protocol independence (5) linear, parallel and re-entrant code options (9) shared context (12) and upgrade procedures (13).

Note: The approach to platform code software development can be as important as the platform architecture overall

Applying Platform Criteria

Not all of 16 capabilities are essential for every application and operators should obviously allow for variations when applying the criteria to different platform functionality. Of course NFV purists would argue that all platforms should be ‘fungible’ and therefore support all functions. In reality it will likely make sense – and save money – to optimize virtual ‘pools of platform resources’ around performance and software based on domains that match the networking requirements for network and user services with shared characteristics.

Operators are beginning to express concerns about deploying SDN/NFV solutions in live operations without true carrier class network virtualization and reliability. They are successfully implementing NFV in the data center, but data center virtualization does not have the demanding requirements of public telecommunications networks.

At the same time some are aggressively changing operations processes as they simultaneously install unproven ‘bare metal’ solutions. Such simultaneous changes make it difficult to separate process failures from product failures. This could dramatically increase the risks of NFV deployment and ultimately delay rollout. As operators strive to adopt new processes in their digital transformation to ‘All-IP’ networking, it is important that they minimize the risk of service disruption during the transition by leveraging proven technology that meets most or all of the virtualization requirements described above.

Operators should virtualize NFV capable but proven networking platforms first.


SA_Website_bio-srudd-2.jpgSue has over 20 years’ experience in telecommunications developing business cases for mobile broadband, voice and value added IP services. At Strategy Analytics she evaluates the impact of next generation platforms and technologies on new service revenues, network capacity, OPEX, CAPEX and Total Cost of Operations (TCO) per GB. Specifically Sue tracks opportunities for: SDN/NFV, Telco Cloud Services, Video Delivery and CDNs, Traffic Optimization, Signaling, SON, Small Cells, DAS, Wi-Fi Offload and Roaming as well as business cases that optimize service provider profitability

Read more about:

Get the latest news straight to your inbox.
Register for the newsletter here.

You May Also Like