NVF Appliances and their Orchestration Engine
Today's Networks Are Complicated
All Network hardware devices contain both a data plane and a control plane. The data plane describes the part of the network where data is forwarded, that's the easier network plane, and is handled by very mature standards for network addressing. The control plane describes your network's decision maker and it determines where traffic is sent and how quickly.
The control plane is where the complication occurs. If you have multiple device types, you have an equal number of control planes. That means you have multiple decision makers in your network! This makes your network control plane a perfect example of the classic problem of too many cooks in the kitchen. It is essential that all of the decision makers are using the same rules and same priorities, and that requires you to manage the control planes.
A typical network configuration has a router paired with a firewall device plus a WAN acceleration device. This combination requires three hardware devices each with their own control plane, resulting in three unique control planes that are all making unique decisions and all need to be individually managed to make sure decisions by each are effective.
SDN, NFV, and VNF Simplify Your Network
The latest network theory to solve the complexity is Software Defined Networking (SDN). SDN touts the possible benefits of detaching the multiple control planes of multiple devices into an all-powerful central command and control plane that can administer a fleet of on demand data planes.
While SDN represents some visionary thinking and is the buzz word of today, implementing SDN theory into practice is a lofty goal not yet fully defined.
Instead of exploring SDN, we are confident what is here and available today, may already meet your needs. From our typical network configuration from above, reducing each piece of network hardware into one appliance that can be orchestrated centrally may be the first step towards network nirvana. The reduction of devices reduces complexity allowing network administrators to provide a more flexible environment that allows quicker deployment of new functions, with simpler and improved management, and operational savings. What makes every network admin excited is they know a less complex, elegantly managed networks main benefit is simple
no more truck rolls!
Consider a Network Function Virtualization (NFV) appliance and its orchestration engine. NFV is the action of taking a single device (or hardware task) and converting it to a virtual machine or software version which performs the same activities of the hardware. The result of NFV is the creation of a Virtual Network Function (VNF). The NFV orchestration engine is the central management and deployment of VNFs just in time on such an NFV capable appliance.
Implementing NFV/VNF technology allows you to simplify your networks decision making (control plane), increase your vendor flexibility, reduce your hardware cost, and lower your cost of ownership today; even without the future promises of SDN or other experimental future technology. NFV/VNF solutions are already readily available as well as production tested for performance and reliability.
VNF Deployment, Anywhere, Anytime
Being able to remotely deploy new VNFs just-in-time to existing deployed NFV appliances is a powerful proposition. Think again about the typical network solution
a router paired with a firewall device plus a WAN acceleration device? Rather than 3 devices being deployed with 3 distinct vendors and potentially 3 separate truck rolls, imagine instead shipping a single NFV appliance to a new location. The appliance only requires being plugged in and network connectivity established. Remotely, and in a distributed fashion, an initial routing VNF is deployed. At a later time, a new VNF is added, chained to the first that provides firewall capabilities. Again, at a later time, WAN optimization is added and chained. On and on we can go. And we can do those deployments per device, or by the thousands of devices, all from a single remote management interface.
Deploying any VNF at any time provides a powerful win for business, but first you must find the right NFV partner for you.
How do I select an NFV vendor?
NFV Appliance goals are to provide flexibility, cost savings, and performance improvements. The biggest hurdle in todays NFV appliance market is price/performance. Look for a vendor that delivers on this important goal first.
Your vendor must have deep technical expertise with Linux. The expertise has to be with embedded Linux. Embedded Linux is essential to our primary goal delivery of a superior price/performance ratio over todays hardware based solutions. Embedded Linux skills cannot be built overnight, these skills must be core to the company and not an outsourced function. Evidence of Linux competency is easily tested by evaluating the devices OS size and maintenance.
To determine their acuity, ask your potential vendor the amount of RAM, CPU, and Disk Space used by the basic operation of their device before any VNFs are added. If the devices OS is larger than 100 Megabytes, its probably time to ask yourself if the vendor has the Linux depth to deliver efficiency for core functions.
When maintaining an NFV appliance, the biggest challenge will be the ability to secure and patch the Linux OS inside the base appliance. Check your vendors approach are they piece patching the OS or do they upgrade using an encrypted and certificate-protected binary image? If your vendor is piece patching, that introduces significant risk as it will result in hundreds of different images and extremely difficult problem determination for your devices in the field.
Ease of management is a core feature of an NFV strategy. Once you have a competitively priced & efficient device selected, it is important to evaluate how the device will be managed in the field. A scalable, hosted central management platform, or orchestration engine is a necessity for distributed NFV. This engine must be open, extensible, scalable, and intuitive.
When evaluating an orchestration engine, dig into the basics: latency and operating/implementation costs. Operations teams are measured on how quickly they perform their job, closing tickets, and ending calls. The pressure of constant measurement forces them to bypass slow tools. How long does it take to perform key tasks on the tool? The last thing you want is the devices to fail because the internal teams are not successful using the corresponding tools and software necessary to support the devices.
Has thought been given to reducing costs? In larger deployments, especially in retail, significant dollars can be saved if you can implement the solution on a nonpublic address; making nonpublic IP address support extremely attractive and for many implementations, absolutely essential.
Another sticking point could be operational ease and impact to cost of ownership. Do they support IPv6? How granular can you define your profiles & management settings? Does the server support time of day scheduled configuration and update options? Does it have an emergency configuration and update function for Out-Of-Band (OOB) support? Does it support a remote control function for the multitude of VNF applications? e.g. reboot, change configuration. And, finally, does it offer robust reporting and alerting?
It is also time to consider unique requirements of your installation site profile? Are you installing to multiple countries? It is important to verify your vendor supports global distribution, certifications, and support. Are you installing in sites that have unique network interface requirements? Does the vendor support the variety of network interfaces you need? Integrated Global Cellular, Fiber (MM, SM), GIG Ethernet, USB?
Asking these questions ensures that your NFV vendors solution is the best match for you.
Select Your VNF Vendor Next
In the future, SDN will also include a new Orchestration plane that will provide centralized, virtualized, programmatic, and dynamic control of data and control planes. Ideally, this new Orchestration plane will also provide vendor independence by using an open standard such as OpenStack. But until that standard is adopted, solving this problem with NFV and VNFs is much more practical and potentially provides for a better outcome where best in class vendors in each network specialization can provide VNFs that a smart NFV appliance can chain together independently.
The first question to ask is if you need a router VNF for most sites? Most remote sites require very few routing customizations or advanced functions so remote site needs can be handled by the native routing function of your NFV appliance operating system. That allows you to focus your time on selecting the right VNF vendor for each of your advanced features (VoIP, WAN Optimization, etc.). Make a list of your required advanced features and evaluate each independently.
It is important to select an optimized VNF, which is a VNF designed and developed from first principles to perform optimally as a VNF on an NFV appliance. Many vendors have attempted to enter the VNF space simply by placing a Virtual Machine (VM) wrapper around large and slow legacy applications that were typically run on dedicated hardware. To determine if your vendor has designed an efficient VNF from the ground up, check their requirements for RAM, CPU, and disk space.
Just as important, VNFs should be modular and you should only have to buy the features you need. This will save you money and more importantly, save disk space and operating power in your NFV appliance (remember great price/performance is still our primary goal!).
What other functions can I run bedsides networking?
A capable NFV appliance can run multiple VMs including chaining the VMs. The only limit to the number of VMs are only limited to hardware (interfaces, RAM, Flash, Disk space). Beyond typical networking functions such as routing, WAN, firewall, VPN; do you need a windows server to run digital signage? Need a managers PC for inventory function? How about Point of Sale? Maybe you look for an HDMI interface?
NFV Appliance Selection Algorithm
All of this advice can be simplified to 5 basic questions:
- Map out your current (& future) network requirements and determine for which network functions you need a VNF
- Remember to find out CPU/RAM/DISK requirements for each VNF
- Look for a vendor that has all the hardware features you need (today and tomorrow)
- Interfaces
- Maximum RAM
- CPU cores and speed
- Maximum disk storage
- Look for a vendor that has a real, open, scalable, extensible NFV orchestration engine
- Look for a vendor that has an embedded Linux OS closely tied to the hardware
- Look for a vendor with extensive knowledge of hardware processors (that does not always mean Intel)
My final question: Does this sound like your network hardware provider today?