 | Issue: | Latin America 2015 |
| Article no.: | 11 | |
| Topic: | The Network Software Provider: A new vendor ategory | |
| Author: | Martin Taylor | |
| Title: | CTO | |
| Organisation: | Metaswitch Networks | |
| PDF size: | 419KB |
About author
Martin Taylor is CTO of Metaswitch Networks. He joined the company in 2004, and headed up product management prior to becoming CTO.
Previous roles have included founding CTO at CopperCom, a pioneer in Voice over DSL, where he led the ATM Forum standards initiative in Loop Emulation; VP of Network Architecture at Madge Networks, where he led the company’s successful strategy in Token Ring switching; and business general manager at GEC-Marconi, where he introduced key innovations in Passive Optical Networking.
Martin has a degree in Engineering from the University of Cambridge. In January 2014, Martin was recognized by Light Reading as one of the top five industry ‘movers and shakers’ in Network Functions Virtualization.
Article abstract
The impact of NFV on the network equipment industry cannot be overstated. The sudden change in the environment that NFV will bring about can be likened to the massive asteroid strike that caused the extinction of the dinosaurs 65 million years ago. Indeed, the analogy is quite apt: It is very tempting to compare the NEPs with dinosaurs, and to point out that this extinction event preceded the emergence of new life forms such as mammals that were smaller, more nimble, more adaptable and more rapidly evolving.
Full Article
Introduction
The vendors that have traditionally engaged with network operators in the building of their networks have come to be known as Network Equipment Providers (NEPs). The equipment they supply comprises physical appliances, each of which performs some specific role in the network.
With the rapidly growing adoption of Network Functions Virtualization (NFV), network operators expect to build their networks in a very different way in the future. In an NFV environment, the network functions that were previously delivered in the form of physical appliances are provided instead by software running on a generic infrastructure comprising commercial off-the-shelf compute, switching and storage hardware.
Network operators that embrace NFV will make fundamental changes to their supply chains. To minimize hardware costs, network operators will want to purchase their generic NFV infrastructure from high-volume vendors of general-purpose hardware, vendors that, in general, have very little knowledge of specialized network functions such as provider edge routers or IP multimedia subsystems (IMS). To procure the software that will provide those specialized network functions, they will need to turn to vendors that combine an in-depth understanding of the network functions with the ability to implement them efficiently in software on generic hardware. This is the type of vendor that we refer to as a Network Software Provider.
The nature of virtualized network software
The software that implements network functions such as firewalls, content caches, mobile packet gateways, session border controllers, telephony application servers and so on is referred to as Virtualized Network Function (VNF). That’s because NFV envisages most network function software to be deployed in the form of virtual machines (or perhaps Linux containers) in a cloud environment such as OpenStack.
Network operators at the leading edge of NFV thinking have realized that their ability to maximize the benefits of NFV depend, in large part, on leveraging the properties of cloud environments to best effect. They have learned a great deal from researching the best-practices of Web-scale application developers and architects and the approaches taken by pioneering software vendors in the NFV space, and they are applying this learning by specifying what they expect of their Network Software Providers. Typically they demand the following characteristics of VNFs:
• VNFs should implement a scale-out architecture that embodies stateless processing elements allied with scalable, fault-tolerant, distributed state stores.
• VNFs should support both local and geographically redundant fault tolerance, with an n+k active-active protection approach.
• VNFs should be composed of a set of relatively simple individual software components that are loosely coupled with each other and that may be reused for a variety of different purposes. This is often referred to as a “microservices architecture.”
• Overall functionality of the VNF may be enhanced by means of independent improvements to one, or a small subset, of the software components that make up the VNF as a whole.
• Each software component should be capable of running in a minimally sized virtual machine, with scaling achieved entirely via scale-out rather than scale-up.
• Open source software components should be used wherever possible, to minimize software development costs and time to market.
• Each software component should make highly efficient use of generic hardware so as to minimize the hardware cost of supporting any given network function.
These characteristics represent the application of current best-practices for cloud application architecture, as applied to virtualized network functions. They are regarded as highly desirable by network operators because they help to minimize both the cost of the hardware required to operate the VNF and the cost of developing (and therefore the cost of procuring) the software, and they promote an agile environment in which innovation in both services and operational practices can flourish.
The impact of NFV will vary by region and by operator, but in Latin America, where mobile data now accounts for more than 30 percent of mobile services revenues, we will see a point soon where the mobile data traffic grows more quickly than the price of mobile infrastructure is dropping. In this region, the potential cost savings that can be had by using virtualized network functions and working with network software providers could be significant. The interest is certainly there – the most recent CALA market data from IHS shows that revenues related to virtualized network functions and NFV projects is expected to grow more than 90 percent in 2015 and 2016 and by nearly 60 percent in 2017.
Software in traditional network equipment
The physical appliances that have traditionally been supplied by NEPs contain a great deal of software. But the architecture of this software differs fundamentally from an idealized cloud application architecture. Most network equipment software displays the following characteristics:
• The software makes no attempt to separate processing and state, and these aspects of the software are inextricably entwined throughout the code base.
• Fault tolerance is provided by means of 1+1 active-standby protection.
• The code base for the entire appliance is essentially monolithic. While the software may comprise many identifiable components, these are typically tightly linked in terms of their APIs, shared data structures, etc. Changes to any component can necessitate a regression test of the entire system.
• Scaling is achieved by means of a scale-up approach, typically leveraging multi-core processors with highly multi-threaded application logic.
• Open source software may be incorporated, but not in a manner that makes it separable in any way.
• Most of the software in the equipment addresses control plane functionality, e.g., IP routing protocols or SIP session management. Extensive use is made of proprietary hardware such as network processors, content addressable memories and digital signal processors to implement the user plane. Highly specialized device driver software is used to interface with this proprietary hardware.
Many network appliances embody industry-standard processors (e.g., Intel x86), particularly to run the control plane software, and this software can often be ported straightforwardly to run on a virtual machine in a cloud environment. But most network operators regard this approach as highly undesirable because it makes inefficient use of hardware, it complicates the scaling of services and it stifles the network operator’s ability to innovate.
The business model for network software
Network Equipment Providers have operated for many years with a well-understood business model, which has the following characteristics:
• Network operators make capital purchases of the equipment they need to roll out their networks. The price paid for equipment reflects the cost of goods plus a markup to generate a reasonable operating margin. This essentially creates a ‘”price floor’” for the equipment.
• Software that runs on the equipment may be separately licensed, but the terms of the license invariably tie the software license to a specific piece of equipment.
• Network equipment has a limited operating life, and NEPs declare older generations of equipment ‘”end of life’” or ‘”end of support.’” This necessitates the network operator engaging in a new round of procurement to replace the equipment. Software licenses associated with the equipment effectively expire when the equipment is retired, so both hardware and software have to be procured afresh.
In transitioning to the NFV model, where network functions are procured as software, every aspect of this business model is called into question. Software has essentially no cost of goods associated with it, so it’s difficult to establish a price floor for it. And software designed to be deployed in a cloud environment is not associated with any given piece of hardware, so the license does not expire when hardware is replaced, and the vendor does not benefit from a replacement cycle associated with equipment obsolescence.
Can NEPs make the transition to NSP?
Most large network operators are now committed to transition their networks to NFV. This means that, for many categories of network functions, there will no longer be a network equipment industry. Functions that require highly specialized hardware, such as cellular base stations, may continue to be procured as equipment, but these are exceptions. Most network functions will be procured as software, so this transition presents an enormous challenge to the NEPs.
NEPs of course own huge software assets. But these assets are in the form of monolithic code bases designed for physical appliances, and re-factoring these code bases to follow Web-scale microservices design patterns will require an enormous investment. Also, the NEPs operate with a business model that fundamentally does not apply in a pure software world. Adapting to a software-centric business model is likely to be very painful for them.
The NEPs are likely to make the case that they alone can provide a complete NFV solution comprising NFV infrastructure and orchestration together with a broad portfolio of virtualized network functions, and offer the reassurance of a ‘”one throat to choke’” approach to building out network services in a virtualized world. But most network operators recognize that this approach, while it might appear superficially attractive, leads inevitably to the kind of vendor lock-in that they’ve suffered from in the past. They know that NFV offers an escape from that kind of vendor lock-in, and that this is one of its greatest benefits. Working with multiple vendors of NFV infrastructure and VNFs of course requires that network operators accept more responsibility for the integration of complete network services, but for most of them that’s a price well worth paying.
The emergence of Network Software Providers
The impact of NFV on the network equipment industry cannot be overstated. The sudden change in the environment that NFV will bring about can be likened to the massive asteroid strike that caused the extinction of the dinosaurs 65 million years ago. Indeed, the analogy is quite apt: It is very tempting to compare the NEPs with dinosaurs, and to point out that this extinction event preceded the emergence of new life forms such as mammals that were smaller, more nimble, more adaptable and more rapidly evolving.
In a post-NFV world, we expect to see two kinds of Network Software Provider – former NEPs that have managed to survive the transition to NSP, and communications software specialists that have thrived because of the enormous new opportunity that NFV creates for their solutions and advanced skill-sets.
Which kind of company do you see surviving the shift to NFV?
