Lippis Report 217: It’s Network Service Virtualization in the Enterprise rather than Network Function Virtualization
During the October 2013 Open Networking User Group (ONUG) meeting, the ONUG community prioritized nine use cases based upon budget development and propensity to buy. The top three use cases were open branch office networking, open overlay or network virtualization, and integrating layer 4-7 network services to eliminate appliances into overlay networks. All ONUG use cases can be found here. Of particular note is the integrating L4-7 network services ONUG use case as its main focus is the elimination of hardware appliance, be it in the branch office and data center. A knee-jerk reaction to this use case was to define it as Network Function Virtualization or NFV. But these discussions ended with the realization that NFV will not work in the enterprise market. In this Lippis Report Research Note, I explain why and introduce the term “Network Service Virtualization.”
Why CIOs Should Care About Software Defined Networking
The integrating L4-7 network services to eliminate appliances into overlay networks ONUG use case, called Network Service Virtualization, or NSV from here forward, focused on solving a few large enterprise pain points. NSV seeks to provide relief from high cost L4-7 hardware appliances. It also seeks to establish a pooling of virtual and physical appliances that can be put to use servicing applications. Aggravating NSV is a lack of a defined approach of chaining L4-7 services to an application.
Open Industry Network Performance & Power Test for Cloud Networks Evaluating 10/40 GbE Switches
NSV potential benefits include the ability for IT business leaders to deliver on-demand or self-service IT delivery to business unit managers. The facilitation of an automated entire network topology in the virtualization domain promises to deliver opex relief. Opex relief is also realized through cost and complexity mitigation of multiple network re-configuration points required during workload migration. These benefits translate into increased choice and speed of IT delivery that enable Enterprise IT to compete with public cloud providers.
Arista 7500E Software-Defined Cloud Network Switch Performance Test
So what’s the difference between NFV and NSV? Two important architecture approaches differentiate NFV and NSV. First, NFV is being defined by service providers that procure large number of message routers, CDNs, session border controllers, WAN acceleration, DPI, firewalls, carrier grade NAT, SGSN/GGSN, PE router, BRAS, Radio Access Network Nodes, Tester/QoE monitors, etc., to service their customers’ connectivity needs. Second, NFV seeks to virtualize these network functions into virtual appliances with automated orchestration and remote install capability. These hardware appliances are currently installed on a per-service-per-site basis. In short, NFV seeks to eliminate these high cost hardware components into software that runs on x86 platforms, thus leveraging commodity hardware to run network functions. NFV makes perfect sense for service providers and operators.
Brocade VDXTM 6740 Top-of-Rack Switch Performance and Power Test
The ONUG community, made up of the largest enterprises’ IT architects and designers, is defining NSV versus operators. NSV seeks to virtualize enterprise appliances, such as firewalls, load balancers, application accelerators, application delivery controllers, Intrusion Protection Systems, WAN optimizers, call managers, etc., instantiated for each application. Each instance of each NSV is created for a specific application. That is, if there are 10 applications that require network services, then each application will be configured with its own instantiation of that service. That is, 10 applications, then 10 NSV firewalls.
Empowering IT Innovations and Reducing Complexity with Unified Access
The NSV approach is in stark contrast to the NFV model where network functions are virtualized but are not necessarily linked to a specific user application, but to a connectivity service. If the NFV model was used in a large enterprise data center, then service chaining would be required that contorts an application to snake through the data center, hitting a virtualized firewall, load balancer, IPS, etc., much like a pinball bounces between bumpers in a pinball machine.
IBM’s New, Easy-to-Deploy Flex System Communications Module
In short, NSV seeks to virtualize network services by creating an instance of the network service for each application versus virtualizing a network service once for all applications. NSV hopes to present significant capex and opex relief from hardware appliances, as well as an efficient way of applying network services to applications without chaining or tagging packets and rapid automated, on-demand application deployment. But there are NSV challenges, such as software license complications, which are still based upon a single network service entity, be it specialized hardware or virtualized. NSV’s per-application-instance-based approach is very elastic, and as such, breaks the current appliance license model.
Note that the term “NSV” was first used by Pertino Networks to describe how it attaches network services to a customer’s virtual network. Pertino is a cloud-based network service that leverages SDN concepts to deliver a virtualized network service. It created an NSV approach to add value on top of its entry-level network service offering. As of this writing, I’m aware of three other firms that will introduce NSV-based offerings for the enterprise market. You can meet them at ONUG this Spring at Citigroup in NYC on May 5th and 6th.