Developing NFV regulations

Since its inception, many IT industry insiders have been convinced that network functions virtualisation (NFV) technology is ideally positioned to revolutionise the way in which commercial networks are built, managed and used to create client services.

They've said the new-generation technology has the potential to consolidate many network equipment types into industry-standard, high-volume servers, switches and storage repositories located in remote data centres, on disparate network nodes and within any end-user premises.

And they've underlined the fact that NFV is able to implement many network functions in software, minimising the need for costly new hardware purchases.

Their faith in NFV was validated last month - March 2014 - when the European Telecommunications Standards Institute (ETSI) and the Open Networking Foundation (ONF) announced plans to further develop NFV standards, at the same time committing to advance open networking and cloud infrastructure standards.

ETSI is an independent, non-profit organisation that has been instrumental in developing standards for ICT within Europe. It was created in 1988, as a non-profit organisation, by the European Conference of Postal and Telecommunications Administrations, which has been the co-ordinating body for European telecommunications and postal organisations since 1959. It is represented in more than 62 countries, including South Africa, through its association with the SA Bureau of Standards.

One of the benefits of the collaboration between ESTI and the ONF is its potential to assuage the fears of end-users who, as a result of a lack of industry-wide standards, have been concerned about 'cloud service provider lock-in' and the problems associated with moving virtual machines and data from one cloud to another cloud.

This is evidenced by widespread scepticism associated with the Open Virtualisation Format (OVF), pioneered by VMware and touted as 'the' cloud standard for facilitating the mobility of virtual machines. It has yet to resolve many of the cloud interoperability issues that are now endemic in the marketplace.

Another ESTI/ONF benefit, this time from service providers' perspective, is its potential to influence future network design, altering the way network architectures are planned, with a view to increasing and optimising operational flexibility. A further advantage is the promise of a significant reduction in both operating and capital expenditure linked to the provision of a platform for increased services revenue.

With the rapid growth of rich media applications and the decrease in voice revenue, NFV is also seen as a catalyst for structural market change on a global scale.

However, before these or any objectives associated with cloud infrastructure standardisation are realised, the relationship between NFV and SDN technology will have to be broadly acknowledged and enhanced by all parties.

As I mentioned in my previous Industry Insight, SDN is increasingly seen as a cost-effective, adaptable answer to demands by wired, wireless and mobile network users for more programmability, tighter control and broader-based automation.

SDN and NFV relate through their collective ability to deliver and control standardised policies on the network. While NFV builds virtualised network functions, its support is not defined within the NFV paradigm. However, the same virtualised platform that supports provisioning machines may also support virtualised network devices as well as the flows that underpin virtualised network functions. This latter programming is the domain of SDN.

NFV is also seen as a catalyst for structural market change on a global scale.

SDN also introduces programmability that opens up the way applications can be used to manage and control the network. These applications range from dynamic virtual network provisioning to more granular firewall monitoring, user identity management and access policy control.

In this way, network services could, in the near future, be made into a series of standardised, interoperating, cloud-hosted components with any number of virtual devices employed. This will undoubtedly help reduce costs to deploy many common network functions - such as compression and cryptography - as well as those associated with special projects.

The lines between cloud computing, NFV and SDN are as yet still blurred, as virtualisation struggles to overcome traditional hardware barriers. For NFV to work as intended, it will have to collaborate with standardised components that follow distinct and interoperable interfaces. And it will have to work with proprietary components created by various vendors to support their cloud capabilities.

Engineers may well have to create multiple instances of a function in order for improved reliability or performance benchmarks to be reached. That said, open source packages or software-based implementations of vendor-specific routers, switches, firewalls and other elements could be eminently suitable components for NFV implementation in their current forms.

Looking to the future, there is evidence of a common architecture and common tools emerging to accelerate innovation and reduce development costs in the cloud environment. I believe there will be significant consolidation of telco, cloud and enterprise technologies going forward, allowing end-users to improve time-to-provisioning metrics while increasing flexibility and scale.