Demystifying NFV: Do We Know What We Have?

Have you ever had a chance to peek into a mountain climber’s backpack? You will find a whole gamut of gear ranging from carabiners and quickdraws, ropes, helmets, harnesses, nut tools, belay, and other protection devices. We’re talking tools that weigh anywhere between 20-30 pounds.

Now, imaging scaling treacherous mountain roads with a bagful of such gear.

Ten minutes into a hard climb, and you will have that burning feeling. With all that weight in your backpack, it’s your legs telling you that you’re burning too many matches too early—and if you do not drop some of that weight, you’re going up in flames before you reach the top.

Now imagine a vertical ascent with no hassle of carrying that backpack from the bottom to the top. All you have is a swiss knife sort of utility-tool with multiple functions stowed inside. Different tools for different landscapes — all in one convertible tool.

The idea behind NFV and network functions is somewhat similar.

NFV: The Fundamental Premise

Like a mountaineer’s backpack, a network provider’s network hosts various proprietary hardware appliances. Multiple nodes, components, and links work together to move the traffic between source and destination.

Since, most of these hardware functions are purpose built, launching a new network service requires a lot of accommodation, planning and capital investment. I won’t even get into the skillsets required to design, integrate and operate these rigid and complex hardware-based appliances.

Furthermore, given the evolutionary nature of the digital landscape, these hardware have the shelf life of a banana. Most cutting edge on-premises devices are obsolete the moment an enterprise decides to go cloudward. This puts the decision makers in a tough spot, impending the inclusion of new revenue centric network services by the economies of scale in an increasingly network-centric world.

Network Function Virtualization (NFV) addresses these problems by isolating the software element from the network hardware. As the network functions are no longer constrained by the underlying physical equipment, a single appliance can be used for numerous purposes, depending on the software it runs. Basically, each node behaves as a micro data center capable of hosting various applications.

NFV and VNF: Can You Spot the Difference?

Does it confuse you when I say, “we are using NFV to deploy path control as VNFs across the domain?” Allow me to explain if your answer is a ‘yes’.

The idea of NFV is to decouple network functions from the hardware. It refers to the operational framework for orchestrating and automating Virtual Network Function (VNF) software appliances on virtualized infrastructure or commercial off-the-shelf hardware (COTS) and then managing VNF appliances through their end-to-end lifecycle.

VNFs, on the other hand, are building blocks within the network and handle specific network functions such as firewalls, switching IDs & IPs, and load balancing. Think of it as the software form of network appliances such as firewalls, load balancers, and routers, etc. VNFs are mostly deployed as virtual machines (VMs).

So, when I say CSCF (Call Session Control Function) is a 3GPP defined application that can be a VNF, it means it has been virtualized and can be installed on a regular COTS server.

NFV & SDN: Bacon & Eggs

NFV and SDN are like bacon and eggs — complementary to each other but not interdependent. However, they taste better when served together and deliver greater value. Though NFV can be rolled out using the existing data center processes, when approached using the SDN principle of separating the data and control plane, it can deliver enhanced performance, simplify compatibility with current deployments, and facilitate operational and maintenance procedures. NFV can complement SDN by providing the infrastructure for the SDN software to be run upon.

The Security Factor

Till a few years ago, most enterprise applications were housed in data centers. Branch offices and distributed users formed a hub and spoke topology, running a minimal amount of cloud data through a centralized location, i.e., the HQ, before sending it out on the public internet.

With functionalities such as NFV and SDN, enterprises are leaping out of stationary data centers into the cloud. Road warriors and users operating from home are accessing resources over a plethora of devices via. a variety of secure and unsecure networks. This changing business landscape calls for better security framework and policies.

The best way to deliver dynamic security services like intrusion detection and prevention, access control, anti-malware, data loss prevention, dynamic threat response and so on; is to deploy these functions via VNFs in a NFV security framework. Alternatively, you can stack boxes for each one of these functionalities.

Where Do I Begin?

When it comes to security most telcos are a few years behind catching up on the cloud networking model. This is where Aryaka hits it out of the park.

Aryaka’s Network Access Point (ANAP), our SD-WAN CPE, integrates a Next Generation Firewall (NGFW) that runs as a virtual network function (VNF) on our ANAP 2600 and ANAP 3000 network appliances. Technology partner Check Point Software and Palo Alto GlobalProtect provides NGFW functionality with CloudGuard Edge.

The combined solution delivers on a converged branch solution with best of breed capabilities in both networking and advanced security, optimally configured via intent-based policies. Enterprises can choose between deployment models that optimally fit their needs: self-managed if they have the resources and expertise to optimally configure and maintain their NGFW, or as a managed service if they would rather outsource basic configuration and day-to-day management to Aryaka experts and merely want to supervise operations.

But you don’t have to take our word for it. Read how we do what we do in this whitepaper explaining the Aryaka security architecture.

Not sure if it’s the right time to be investing in a new technology? Read our whitepaper on SD-WAN ROI to understand why the right time to take that leap was yesterday.

Tired of reading? Please feel free to reach out to us for any questions that you might have around SD-WAN, NFV, Security and anything connectivity.