NFV should be about ‘Open IT with choices’

Would it be too dramatic to say the end is nigh for traditional monolithic networking systems and architecture?

July 30, 2014

Would it be too dramatic to say the end is nigh for traditional monolithic networking systems and architecture? Quite possibly, but the reality is that the enterprise networks of five years’ time will have only a passing similarity to those of five years ago as software–defined networking (SDN), mobility and big data transform the way people view and manage their architecture. Now it is the turn for the giants of the IT communications industry to take centre stage; the telecoms service providers.

These companies are caught in a proprietary world based on an archaic model. For every service-oriented network function – whether it be IMS, session border controller, SSGN/GGSN, or even firewall, DPI or CDN- there are racks full of proprietary infrastructure. These all require complicated installation and integration processes, in order to ensure they play nicely with the rest of the network, as well as management from network administrators with specialised knowledge of that particular product.

With long proprietary product cycles and tight regulatory standards restricting innovation and modernisation in the industry, the telecoms service provider model is at severe threat from agile internet-based service providers. Able to leverage new optimised processes and flexible infrastructure to provide similar services at a lower cost, these organisations can adapt to market demands and deliver new services rapidly. The choice facing these service providers is increasingly one of evolution or extinction.

A snapshot on NFV

Network Functions Virtualization (NFV) offers the path to evolution. At the highest level, it works by:

  1. Virtualizing the roles of the various network functions appliances into a series of Virtual Network Functions (VNF). These VNFs run on standardised servers, necessitating the virtualiziation of the physical network infrastructure to enable seamless deployment.
  2. VNFs are then linked together to provide a specific service for the customer, using service chaining architected, managed, repaired and monitored through open-source frameworks like OpenStack.
  3. Service providers can now integrate this optimised virtual infrastructure with their existing or renewed orchestration system. This allows them to integrate their OSS/BSS implementation for dynamic rating, billing and delivering services in the blink of an eye.

The benefits this can bring to telecoms service providers are profound, and can all be passed on to the customer. Replacing proprietary pieces of hardware with standardised servers and networking brings the agility to deliver new services dynamically while significantly reducing CAPEX and OPEX costs. This liberates the carriers from hardware lock-in which incurs extra costs further down the line; while being a boon to their customers fatigued from service providers being unable to adapt and deliver services that address changing business needs. The elevation of all the network functions to a single virtualized infrastructure with a common framework also means OPEX costs are likewise reduced, as operational visibility and management is simplified.

For the provider, the implementation process for a NFV solution is also considerably faster – especially if its customers are in the process of virtualizing their internal networks. As a result, new customers can be brought into the network faster, whilst existing customers can have their services upgraded quicker and with less complexity. Above all, NFV delivers new services that monetise the infrastructure.

Road to realisation

However a series of areas need to be addressed to pave the way for industry-wide NFV adoption:

  • SDN/NFV Overlays: An area of significant crossover between the two technologies; the creation of network overlays which successfully segregates the physical and virtual network are fundamental to the success of both SDN and NFV.
  • Optimizing commoditized Servers: Putting VNFs on an ‘off the shelf’ server is a key feature of NFV, but not one without interesting challenges, especially around maximising performance and interoperability with other network devices. Key work is required around delivering high-performance virtualized software which sits on standard hardware.
  • Manageability: Connecting and controlling VNFs to form service chains through systems like OpenStack raises further challenges. Service providers require sophisticated VNF management software to orchestrate, monitor, repair and monetise for services. Furthermore traditional network functions need to be reimagined to fit into an OpenStack-like environment.
  • Orchestration APIs: Lying above the OpenStack-like integration platform is the service provider’s orchestration layer, which supports OSS/BSS functions in the network. As VNFs replace traditional network functions, new APIs on to these OSS/BSS systems are required to accommodate the change. With the networking paradigm rapidly shifting the emphasis is on DevOps to enact these changes to the OSS/BSS.
  • PoC & Field Trials: Traditional adoption rates for new technology in the telecoms service provider industry are very slow, with meticulous, extended test cycles the norm. NFV needs to move past the Proof of Concept stage; come off the paper and into the network. This is the challenge of the next two years. Actual deployments need to be seen sooner than later for moving from hype to reality.

Each of these challenges requires dedicated expertise to overcome. From the physical layer upwards, connectivity is key. Vendors are seeking various ways to meet these challenges with a choice to pursue either proprietary or open avenues.