Managing virtualised network environments

I got a laugh at a conference back in the past when I commented that to the media, any new technology had to be either the single-handed savior of western culture, or the last bastion of international communism. Anything in between wasn’t going to generate clicks on the pieces, and it was too complicated to write in any case. Clearly we’re at that point with NFV. Two months ago it was a darling of the media. Apparently the honeymoon is over, and the focus of the disillusionment is the difference between “workable” and “makes the business case.” What’s interesting is that the points are valid even if the emphasis on them is a bit belated.”
Tom Nolle.

You’ve probably heard the buzz-words by now. NFV (Network Function Virtualisation) and SDN (Software Defined Networking) have many in the ICT industry salivating over their theoretical benefits / opportunities (although there is a sense of disillusionment creeping in). Benefits include cost reduction from using commoditised rather than proprietary hardware; power reduction, recoverability and scalability from using virtualised / elastic compute as well as the flexibility of de-coupling network control software from hardware (traditional network functions like routers see proprietary network control software co-resident on dedicated hardware platforms from a monolithic vendor).

Unfortunately these nascent, potentially game-changing technologies can only thrive if network management tools like OSS (Operational Support Systems), DCIM (Data Centre Infrastructure Management) and ITSM (IT Service Management) can step up to harness (ie operationalise) these potential benefits.

For example NFV basically consists of three fundamental components:

  1. Virtualised Network Functions (VNFs), which are virtualised versions of network functions such as routers, load balancers, firewalls, etc
  2. Network Function Virtualisation Infrastructure (NFVI), which is the platform that supports a VNF
  3. Management and Orchestration (MANO) are the functions that deploy and manage the VNFs and NFVI

It’s not uncommon for organisations to focus on designing and building their network (ie the first two components above) whilst network management (ie the third) is an afterthought. This can be detrimental to the efficient operation of traditional networks of course, but is likely to be far more hazardous for virtualised networks for two main reasons:

  • There are more layers of infrastructure to manage in a virtualised environment, potentially across demarcations between different vendors
  • Virtualisation will allow more devices to be created (ie more touch-points) and they will potentially be more transient in nature (ie relies on more real-time asset management), making the management equation tougher

To an extent, the network virtualisation community has also been guilty of treating network management as an afterthought too. Development on VNFs and NFVI appears to be far more advanced than MANO, although TM Forum’s ZOOM initiative and a dedicated MANO working group at ETSI have recently upped the ante on this challenge.

If a virtualised network is more complex, has more touch-points, needs real-time asset monitoring and necessitates process change, we clearly have a recipe for increased network management costs. Advanced OSS are already beyond the budgets of many enterprises. The potential cost savings at the network layer (eg commoditised hardware) could easily be eaten away by increased network management costs.

The key message in this blog is that if / when you’re asked to begin evaluating network virtualisation for suitability in your specific environment, ensure that management of your network is forefront in your plans. It could easily be the difference between delivering a more cost-effective, efficient network and delivering negative results for your investment.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *