imelamory - Fotolia
Full disclosure: Author Jeff Loughridge, an independent IP networking consultant, has contributed to the documentation of the open source Snabb Switch project.
The implementation of new network functionality has traditionally lived in the corridors of hardware vendors. The hyperscale Web companies were the first to break this model by using commodity x86 hardware with internally developed software. Now, the democratization of network feature development is ready to spread further, thanks in part to Snabb Switch, an emerging open source network functions virtualization toolkit.
Snabb Switch answers an intriguing question: What innovation might emerge if network functions could be written in a high-level language by network engineers with deep domain knowledge? The Snabb open NFV toolkit offers operators and enterprises the ability to solve network problems without being hindered by vendor lead times and pricy networking hardware.
In a nutshell, Snabb -- which means "fast" in Swedish -- is an open source virtualized Ethernet networking stack. The software, which can process millions of Ethernet packets per second, enables programmers to easily create virtualized networking software to operate on standard x86 servers.
By providing an NFV toolkit in the form of a virtualized Ethernet networking stack, Snabb Switch lowers the barrier of entry for network developers to enable specific network functions. Few companies have the internal knowledge to write control plane logic for massively distributed systems. But small units of functionality could be written as modular apps using Snabb Switch as the underlying framework. Consider an analogy to app developers on mobile platforms. A fraction of developers would be able to write the operating system, but the expertise required to write an app is within the reach of even novice developers.
Snabb Switch is the brainchild of Luke Gorrie, an engineer who spent most of his career writing software for network devices and who founded Snabb, a network software consultancy, in 2012. Gorrie was inspired by CloudFlare's use of a Lua scripting module for the Nginx Web server to implement customized load balancing for its content delivery network. Using that innovation as his inspiration, Gorrie wanted the networking community to have the same flexibility, only by allowing programmers to create extensions to manipulate Ethernet frames in a software switch the way Cloudflare did for HTTP.
Extensibility and code sharing are pillars of the Snabb Switch project. Gorrie expressed his views on extensions on the snabb-dev mailing list:
"The goal is to make it easy for motivated end users to create small extensions to do what they want, even if it involves adding code into the data path of a production network element. And it should be easy for people to pass these scripts around to their friends and so on, so that the ecosystem as a whole grows."
The extensions are created using configuration scripts -- also known as "designs" -- and apps. A Snabb Switch configuration script relies on existing apps. The script describes how the apps should be "wired" together. The packets output by one app are connected to the input of another app in a series known as the app network in Snabb Switch. The app is the more advanced of the two methods. Example apps packaged with the project include a packet capture reader, a packet filter and a learning bridge.
Understanding how Snabb Switch achieves its packet-forwarding speeds requires a brief history lesson. High-performance computing on x86 hardware was traditionally implemented by pushing functionality into the Linux kernel. This approach has limits, as interrupt handling and context switches incur performance penalties. Recent frameworks like Intel DPDK take the kernel out of the equation. Snabb Switch doesn't use DPDK, but it's similar in that it moves packet processing into user space. The result is that the arcane knowledge that kernel hackers possess is no longer needed.
With Snabb, ISP skips usual feature-development process
Alexander Gall, an engineer at the Swiss ISP SWITCH, discussed an advanced application of Snabb Switch at the 2014 TERENA Networking Conference (TNC). While many operators implement Layer 2 VPNs that use MPLS to transport data, the Swiss ISP believes the reduced complexity and ease of interconnecting administrative domains favor a pure IP approach. A protocol currently in Internet Engineering Task Force (IETF) draft, called Keyed IPv6 Tunnel, offers a method for transporting Ethernet frames over IPv6.
Here's how this story would traditionally play out: An operator would ask a vendor to develop a new feature. The vendor would determine the level of effort required for development and the benefit of expending the resources for development. If large customers weren't requesting the feature, the vendor probably would decide not to develop it. Even if the vendor decided to proceed, operators would have to wait at least 16 months for delivery. Then the operator's certification and deployment might add additional time to the vendor's lead time.
SWITCH looked at the Snabb Switch project as a way to roll out its own network protocol and skirt the usual process. At TERENA, Alexander described how Keyed IPv6 Tunnel was easily written in Lua. The ISP didn't have to go out and buy a proprietary box from a network vendor. Instead, it could use x86 servers it already owned. This example shows that NFV can be used to produce faster time to market with new services at a reduced expense.
Snabb Switch in development
Users new to Snabb Switch frequently try to understand the software as it relates to Open vSwitch (OVS), the de facto standard software switch for open source hypervisors. Both projects are geared toward switching packets in virtual environments. OVS is a feature-rich replacement of the Linux bridge and offers a programmable control plane using OpenFlow and the Open vSwitch Database Management Protocol. The focus for Snabb Switch is the programmability of the data plane, as described in this article. Yet nothing in the Snabb Switch architecture prevents a developer from adding a feature to control forwarding with any SDN southbound API protocol.
Snabb Switch is in the early stages of development, and as a result, still exhibits the characteristics of this immaturity. The development team is small, but is growing. The number of network interface cards (NICs) the project supports is limited to a few Intel NICs. Additionally, Snabb Switch's documentation is still a work-in-progress, which leads to lengthy ramp-up time for new users to get acquainted with the software.
That said, Snabb Switch stands out in the increasingly crowded SDN ecosystem because of its practicality, accessibility and performance. The project is not vendor vaporware, nor does it require a wholesale replacement of existing networking protocols and infrastructure. Snabb Switch is available on GitHub and does not require special-purpose networking hardware to achieve impressive performance on commodity x86 servers. Snabb Switch has already attracted the interest of large operators -- such as Deutsche Telekom and BT -- and will be integrated with the OpenStack Neutron plug-in.
To many providers, the NFV deployment may bring to mind a large, costly transition from the present state to a somewhat murky new state. Its first incarnation needn't fundamentally alter the way network services are currently delivered.
If you have a simple -- yet important -- feature you're missing in your production or lab infrastructure, or you haven't pursued the feature's development internally because operating at 10 G wire speed was a requirement, consider downloading and evaluating Snabb Switch. What commodity hardware can deliver with a little bit of Lua programming may surprise you. This may be the foundation for your first NFV win.
About the author: Jeff Loughridge has been operating, maintaining and designing IP/MPLS backbone networks since 1997 in both engineer and management roles. He currently runs his own consulting business, Brooks Consulting LLC, primarily providing services to Tier 1 ISPs and mobile operators. His specialties include optimizing IP networks for simplicity and reduced cost, TDM-to-Ethernet access migration, integrating IP and DWDM and MPLS/VPN design.
How to make SDN and NFV interwork with legacy equipment.
Will network engineers have to become programmers?
Find out how NFV will affect service providers and enterprises.
NFV orchestration must address the whole service-chaining process.
Brush up on where SDN and NFV meet.