How will NfV and SDN impact the future of networks and what are the questions for the CIO?
Two TLAs (three letter acronyms) dominate most discussion about the future of communications networks: NfV – network functions virtualisation - and SDN – software defined networks. NfV is a mainstream industry development and we are at the heart of it. SDN is deployed in a number of datacentre networks linking compute capability to the wide area network in an “on demand” fashion. The techniques of software defined networking will be pivotal to achieving large scale network virtualisation and so here too we are at the heart of things.
And so together they have the potential to impact the network market by making it quicker to adjust key performance characteristics. Furthermore, because both technologies are on the wider IT virtualisation and automation continuum, the disruption is inevitable. So the key questions for IT leadership are about economics, integration and time and not so much about technology.
Knowing that parts of their current infrastructure are rooted in the past and simply cannot be updated, the #1 question for CIO’s is: “How can I take everything I have into the future? And who can help to take me there?” NfV and SDN will have a role to play in the future, but that role is perhaps in the orchestra pit or the lighting rig, not on centre stage. This will be occupied by the service provider and the customer.
NfV involves the implementation of network functions in software that can run on generic computing hardware. These virtual functions can be deployed anywhere in the network without having to install new equipment.
Over time we expect a number of the functions currently delivered by appliances - both at the customer site and within our network - to migrate to NfV software implementations. Appliances which are based on significant software based processing will be the first functions to be implemented. These include firewalls, intrusion detection, network analytics and application optimisation.
We do not expect NfV to replace the core and access components of our global network. These rely on high performance custom hardware to deliver the performance and scale services our customers need of our services. The core connectivity between hundreds of nodes in over 170 countries serving hundreds of thousands of customer sites requires significant investment in fibre and physical infrastructure. This engineering masterpiece can never be virtualised.
When NfV is a commercial reality we’ll have the ability to introduce software driven network enhancements in significantly shorter timescales. We’ll deliver a virtual appliance to a customer site in minutes where previously it took weeks to commission and install the hardware version. We’ll help our customers successfully leverage the acceleration in innovation as the work of existing suppliers with a proven track record is spurred on by a new stratum of network appliance vendors whose market entry is gated only by how long it takes to write their piece of software.
However, there is still some way to go. Many of today’s most intensive network applications - even those running under x86 - require specific hardware such as special network cards, specific disks and specific CPU types and a special management of hypervisors to get anywhere near the performance that is required. There are also significant challenges in managing the quality of the customer experience. For instance, I/O buffering can be deployed to manage the shortcomings of the x86 platform but we know the damage that buffering in the network can do to network performance.
To overcome some of these issues amongst other things, we initiated the Network Functions Virtualisation Industry Specification Group under the auspices of ETSI. Open to all including non-ETSI members, the NfV ISG aims to build the NfV ecosystem, identify common approaches to solve technical challenges and encourage innovation. The group already includes 22 global carriers plus over 85 leading equipment and software vendors.
Some of these companies are working with us in our labs at Adastral Park where we are running a programme of compatibility and interoperability tests and evaluating orchestration solutions that are critical to the successful implantation of NFV with a communications provider’s network.
We are currently working on realising NfV with over 30 global network customers from all parts of the world and across multiple industries. This work ranges from feasibility studies to proof of concepts to active CPE trials with vendors such as Cisco and Riverbed.
BT’s labs are working to produce an industrialised NfV node ready for deployment in the BT global network fully integrated with the BT OSS. The precise date for release is currently commercially sensitive. But we are not talking the distant future.
Furthermore, as a service provider, BT is well aware of the huge installed base of function-specific devices across the networked world. NfV will not replace existing network appliances overnight. NfV appliances will need to co-exist with the installed base of equipment within our and our customer’s networks for some considerable time. Therefore, we’ve designed our NfV architecture to let us integrate and control physical and virtual network appliances alongside each other.
So NfV will not herald a rush to replace network elements but has triggered an evolution. The speed of the evolution will be driven by customers, their new requirements and the suitability for the specific functions to be virtualised in software rather than use dedicated hardware. Indeed there are some functions in the network where virtualisation will play a very small part. Optical, DWDM, DSL and high end core routing will require dedicated platforms for the foreseeable future.
Successive generations of technology have improved network speed, reliability and cost efficiency but they have not kept pace with the customers’ expectations to change the inherent shape of the network. SDN is about bringing new agility and speed to network configuration.
You can provision a virtual machine in today’s datacentres in a short time. Similarly, new SDN techniques are orchestrating the local area network within these datacentres in the same way. Connectivity to applications can be turned up at the same time as the compute infrastructure and applications.
However SDN isn’t as mature in the wide area network where its techniques will be essential for service provides to reap the full benefits of network function virtualisation. Some web scale companies such as Google and Microsoft are using SDN to control networks which are closely linked to specific applications - allowing them to schedule and calendar large flows from these applications over the WAN. These early SDN approaches do not transfer directly to a global enterprise WAN that must support many customers with many applications demanding the levels of robustness and availability that we deliver to our global customers day in day out.
However, SDN based approaches will be essential for the effective orchestration of networks containing virtual devices. Meanwhile, we see it being used to turn up new connections between the datacentre and WAN customer sites, to add new in-line services into the network and new connectivity between locations. We also think that by adding some additional information into our core network routing protocols (e.g., latency constraints for particular traffic, routing particular traffic over one connection rather than another) SDN can provide a useful dimension to creating and supporting new classes of enterprise traffic.
The first deployment of SDN in our network is likely to be one that better integrates our BT Connect and BT Compute services so that we can turn up connectivity from our WAN to our compute services at the speed of modern cloud computing rather than traditional WAN services.
We also expect to see SDN letting us manage the hosted application connectivity provided by NfV so allowing us to deploy flexible “service chains” of value added applications. An example would be managed internet breakout with firewall, intrusion detection and optimisation functions configured as in a specific “chain” on a custom basis tailored to the requirements of an individual customer.
Finally, we expect SDN to provide agile access network capability for specific markets where rapid turn up of connectivity is required on a pre-provided infrastructure. We are developing an Agile Optical Network proposition around this idea for our financial customer base.
So SDN will bring new agility to the network and we see it as an important companion to NfV to enable the new network based applications and services to be more flexible in future.
There is no denying both NfV and SDN have great potential and in many ways they are mutually supportive. But as with many new innovations it is early days for these technologies and we don’t expect to see rapid changes to our underlying core infrastructure or core services, rather we will see these technologies gradually adding new value to the existing infrastructure as they are proved and specific use cases deployed for our customers.
Introducing new technology is a challenge that BT takes up day in day out. We see our job at BT to enable the legacy to work with the new to deliver a stunning business outcome. When the employee of a global business lands to do business on the other side of the world, he or she need not know that their email and calendar services are delivered from the Microsoft Azure cloud, that their ERP and bid management tools are run from the corporate data centre and that most of their voice calls are carried over the company’s global WAN. All they want to know is that all these apps work and that they work instantly and seamlessly. All the CIO needs to know is that they do so most efficiently and within budget.
Note that all that was said without once mentioning NfV or SDN, nor was BT’s global IP network, cloud compute services, unified communications portfolio and network integration skills.
In short it’s not about how you do it or what you do it with, but what you have today and what you want to achieve tomorrow.
That’s where the conversation about the future of networks should start. Not with two specific TLAs - NfV and SDN.
Back to NfV / SDN listing page »