Enterprise NFV Design and Use Cases – Part 2

Design Considerations for Branch Virtualization with NFV

In the 1^st blog on Enterprise NFV Design we discussed the concept of network function virtualization and its benefits, what are the foundation blocks when planning for branch virtualization with NFV?

Let’s look closely into each foundation block and the considerations depending on the use case.

Hardware Hosting Platform:

The hardware platform can be any x86-based server, a server blade that runs inside your existing routing platform, or a customized x86-based platform that provides options for specialized interfaces for WAN (T1, xDSL, Serial, etc.) and 4G/LTE access.  It should be built for the Enterprise office environment – form factor, acoustics, multi-core capable, WAN/LAN ports with the option to support PoE, etc.  Additionally, data encryption has become a mandatory requirement for providing data privacy and security.  To ensure high performance encryption capability, one may want to consider a hardware platform that includes crypto offload module or CPU chipsets that include an enhanced crypto function such as the Advanced Encryption Standard New Instruction (AES-NI) library from Intel.

 

Hypervisor Platform for VNF elements:

A hypervisor is a function which abstracts – isolates – operating systems and applications from the underlying hardware. This abstraction allows the underlying hardware to independently operate one or more virtual machines as guests, allowing multiple guest VMs to effectively share the system’s physical compute resources, such as processor cycles, memory space, network bandwidth and so on.

There are two types of hypervisors.  A type 1 hypervisor runs over bare-metal x86 hardware architecture, as an operating system does, but it also enables other operating systems to run on it. A type 2 hypervisor runs on an OS as a hosted environment. Type 1 hypervisors have direct access to hardware and, hence, provide better performance than type 2 hypervisors which run on an OS.

The common types of hypervisors in the market today are:

• VMWare ESXi
• KVM
• Microsoft Hyper-V
• Citrix XenServer

To successfully host network function virtualizations and meet the throughput and latency requirements of the hosted VNFs, there are considerations you have to factor in for hypervisor selection:

• Data plane latency variation for VNFs
• High performance network I/O for all packet sizes
• High performance network I/O for all traffic types including rich media
• Control plane timing variations and correctness for real-time VNFs
• Inter-VNF communication

To that end, Single Root I/O Virtualization (SR-IOV) is a means to minimize latency for networking of virtual machines that are latency sensitive or require more CPU resources.  To make use of SR-IOV, the hardware (PCIe devices), hypervisor platform, and VNF all have to support the capability.

Service chaining of virtual functions is a critical element of network function virtualization, this functionality helps with interconnecting virtual functions similar to how physical devices are deployed.

Orchestration Engine

Without a centralized orchestration engine today’s legacy networks are plagued with the following limitations:

• The lack of network agility significantly limits IT agility
• Traditional network management is done “box by box.” highly manual and repetitive process.
• Human error is the largest cause of network downtime – we have recently learnt from the public cloud outage experience.
• The majority of a company’s IT budget is used to maintain the status quo.
• Lack of automation keeps total cost of ownership (TCO) high.

While considering a central automation engine the following features are highly critical

• Plug and Play for Day 0
• Centralized policy automation
• Centralized hybrid WAN management
• Public-key-infrastructure (PKI) certificate management
• QoS deployment and change of management
• Network wide visibility and segmentation
• VPN deployment and change of management

VNF elements

A virtual network function (or VNF) takes on the responsibility of handling specific network functions like Routing, Firewall, Application Optimization, Unified Communications (IP PBX, Session Border Controller, etc.) and Wireless LAN Controller. These individual network functions could be served by deploying their specific hardware appliances or can be virtual and connected or combined together as building blocks to offer a full-scale networking communication service. It is critical to deploy VNFs which support SR-IOV to achieve maximum throughput and performance.

Conclusion

Enterprise NFV enables agile, on-demand service and centralized orchestration for integrating the new service into the existing ones. Enterprises gain the ability to choose “best of breed” VNFs to implement a particular service. By using NFV, you can spawn virtual devices to scale to new feature requirements.  For example, with your existing the branch router you have an option of inserting a server blade and spawn up a NFV element that provides additional security functionality or running multiple VNFs, service chained together for routing, security, wan optimization, unified communications, etc. Similarly, SDWAN can be deployed as an integral part of the routing VNF with a centrally automated and orchestrated management system.

Cisco DNA provides the hardware, software and management building blocks to achieve the simplicity and flexibility required by CIOs and IT managers in today’s digital business landscape – here is a whitepaper which delves deeper into this design guidance

In the next blog we will look at real life customer deployments who are leveraging the Cisco DNA architecture to build better customer experiences and differentiation for their businesses.Would love to hear from you on your experiences with Enterprise VNF designs and deployments.

Would love to hear from you on what you see as design recommendations and challenges in the new world of NFV , we can also continue the conversation @jayeshchokshi or https://www.linkedin.com/in/jay-chokshi-a995344