FRAMINGHAM, MASS. —Â With its ability to decouple network control from the physical infrastructure, OpenFlow and software-defined networks have been touted as the Next Big Thing in networking. They’ve been pitched as a way for cloud service providers and webscale companies like Google, Facebook and Yahoo to ease or automate network configuration and reconfiguration, and quickly add more functionality without manually touching each and every switch or router in the network.
Such companies can use OpenFlow and SDNs to reroute traffic, balance traffic loads, provide bandwidth on demand for peak requirements, execute policies to scale and segregate the networks of different data center or cloud tenants, and connect subscribers to content and services.
INQUIRING MINDS WANT TO KNOW: What is OpenFlow and why is it needed?
OpenFlow and SDNs have also been coronated as “Cisco Killers” due to the ability to abstract network configuration and extensibility from vendor-specific hardware and software commands, ostensibly relegating Cisco switches to Just Another Device status in a network and freeing customers from vendor lock-in. But Cisco just announced its own programmability initiative through its Cisco ONE architecture and onePK software development kit (see related story) and Insieme Networks is building a line of programmable switches for the company.
So what exactly is the OpenFlow/SDN killer app for the enterprise?
Actually, there are several, vendors in the OpenFlow/SDN/network virtualization arena say.
“Our primary focus is the enterprise market,” says Kyle Forster, co-founder of Big Switch Networks, a maker of OpenFlow controllers for SDNs. Big financial and technology companies are trailblazers with OpenFlow, he says.
They are using it for network virtualization for private cloud buildouts to extend beyond the limits of virtual LANs, which top out at 4,096. Once those private clouds are implemented, enterprises then look for more business critical applications for OpenFlow and SDNs, like data center interconnect, disaster recovery and granular security.
“There are all these requirements on the application for the private cloud 2.0 and that’s where, on the network side, the VLAN architecture really starts to break,” Forster says.
Even before enterprises implement private cloud, data center network virtualization is some low hanging fruit for OpenFlow and SDNs, Forster says. Server virtualization across eight to 30 racks, with 200 to 2,000 VMs per rack, usually breaks the VLAN limit and opens up an opportunity for SDNs.
“That’s the end of the all VLANs everywhere path,” he says.
But OpenFlow and SDNs are not network virtualization, per se; they are network construction tools to facilitate network virtualization, which is really a “solution” built on top of an SDN foundation, says Martin Casado, co-founder and CTO of network virtualization start-up Nicira.
Casado was also one of the chief developers of the OpenFlow protocol and API.
“The enterprise use case motivated the work that I did that became OpenFlow and grew into this SDN mania,” Casado says. “Within the business enterprise, there has long been requirements for security, for isolation and for service interposition. How do you build an enterprise network that allows for security and isolation, with simplified operations and service interposition?”
Casado believes network virtualization brings these attributes to enterprise networks. But whether or not those virtualized networks are built using OpenFlow and SDNs is irrelevant to the user, he says.
“Traditionally, OpenFlow does not do network virtualization,” Casado says. “All OpenFlow does is allow you to control switches and it may allow you to run different applications on the switch. But it doesn’t provide you the ability to create a virtual network that’s topology independent that supports L2 and L3. I don’t know of any OpenFlow solution that does this.
“SDN is just a tool set,” he continues. “Network virtualization is an actual solution. It’s a product that you sell. And it solves many of these problems. It will decouple the security policy from the physical topology. It natively supports mobility. It allows for dynamic service interposition. It natively supports isolation. Whether or not you build network virtualization with SDN is an independent question. You can certainly do it without using SDN; I just question whether you’ll have the guarantees you need on the scale you’ll need. My sense is, without SDN you can’t do virtualization at scale with guarantees. But the solution that will change the operational model of the enterprise is virtualization.”
HP agrees with that perspective from Nicira: OpenFlow and SDNs are just tools to enable the real value of programmability, which are applications like network virtualization and granular policies for different use cases — like managing the bring-your-own-device (BYOD) phenomena in enterprises. HP earlier this year rolled out 16 OpenFlow-enabled switches for the enterprises that interoperate with controllers from vendors Big Switch, NEC and NTT, as well as open source controllers like NoX, Beacon, Floodlight, and Trema.
HP also demonstrated its Virtual Application Network orchestration capabilities at Interop in May.
“SDN is a capability and then there are the network applications that run on top of it: network virtualization, BYOD policy, or things of that nature which is what people are actually using,” says Saar Gillai, CTO of HP Networking. “In network virtualization, SDN can help you in doing some of the overlay tunneling but there’s other things you need to provide to create that capability. SDN is a technology that can be leveraged to provide some unique applications but in and of itself it’s just a technology.”
OpenFlow and SDN’s real value comes from what it enables. Network virtualization allows enterprises to share a common physical infrastructure with different attributes among multiple organizations, says Karl May, CEO of Vello Systems, a maker of OpenFlow and SDN cloud switches for enterprises.
With SDNs, customers build an abstraction of the physical infrastructure to use it for a combination of production and test networks.
“That is greatly undersold when people talk about SDNs,” May says. “That’s a very valuable element of the SDN architecture.”
The programmability afforded by OpenFlow and SDNs enable applications to define the behavior of the network and provide them with a level of deterministic performance, May says. This is appealing to enterprise customers with very high performance computing or Big Data needs, he says.
“The very first thing that they’re asking about is, ‘Tell me how I can customize your product for my applications,'” May says. “I have very limited ability to customize when I make changes to my network or upgrade my firewall — that forces me to touch all 300, 400, 500 or 1,000 of my switches. Some of the operational ease that an SDN architecture provides is beginning to become one of the more significant drivers of interest in the enterprise.”
Much of that operational ease comes from automation, another key benefit of SDNs. Enterprise IT staffs are resource constrained, in time, manpower and money. The programmability aspects of OpenFlow and SDNs help automate procedures that fit into those constraints, says Don Clark, director of business development for the IT Platform Group at NEC America.
NEC’s ProgrammableFlow line of switches are based on OpenFlow.
“The networking and IT staff is having to do more with less resources,” Clark says. “And especially as cloud services spin out the networking staff in a traditional networking model is overloaded with service requests. So enterprises are really looking to automate some of the things that today are manually configured.
“Automation brings benefit of not having to develop all of these applications internally,” Clark says. “Balancing workloads across data centers, today that’s a lot of configuration down on each individual switch. Providing an automated solution that allows them to do that much more dynamically is the kind of thing that allows (enterprise IT) staff to move away from manual configuration and more towards policy.”
Weren’t VLANs, which were all the rage in networking a decade ago, supposed to virtualize and automate and segment and isolate applications and traffic over a shared infrastructure? They did, but that technology is old now and it limitations are now showing.
“VLANs are difficult to configure and are limited in scope,” says HP’s Gillai. “We’re taking it to the next level with a full virtualized network, with an overlay or segment for a particular application or use case which is isolated from anything else that is going on. Each application or use ‘feels’ like it has its own network. And it simplifies network management and resource allocation. We’re now managing resource pools” instead of individual routers and switches.
“VLANs are very low level,” says Nicira’s Casado. “Even if you had VLANs as a low level mechansims, would still need someone to update it, configure it, and wouldn’t scale because you’d have to trunk everything everywhere; you couldn’t go over an L3 boundary.”
Newer technologies like Virtual Extensible LAN (VXLAN) and Network Virtualization Generic Routing and Encapsulation (NVGRE) are also intended to virtualize networks and scale VLANs. Cisco, VMware and Arista are co-authors of VXLAN, while Microsoft, Dell and Intel back NVGRE.
VXLAN and NVGRE are encapsulation and tunneling schemes designed to overlay, proponents say, virtualization onto existing network infrastructures. VXLAN, server-based virtual switching and virtualized Layer 3-7 services, such as firewalls, load balancing, NAT and e-mail gateways, are the underpinnings of VMware’s SDN strategy.
“Rather than wait for the SDN/OpenFlow world to start penetrating into enterprises – which, we’d be here a long time – we had an immediate need of virtualizing the network,” said Allwyn Sequeira, CTO and vice-president of Cloud Networking and Security at VMware. “That’s why we started with vSwitches, virtual distributed switches and VXLAN. That works and it solves a bunch of problems, and it has a lot of the elements of software-defined networking: you have a controller – we have our vCloud Director, vCloud Network and Security Services, we bring up VXLANs on the fly that map onto all kinds of existing (networks), and is future-proof. It could map onto OpenFlow.
“Here, we don’t really need to program the boxes as much as we make sure we give different tenants space, their own virtual wire,” Sequeira says. “That’s one of the things about VXLAN: it has the notion of a tenant ID built in so that you can have different tenants with their own name spaces on the network.”
VMware’s vShield Edge handles the higher-level virtual services, Sequeira says.
But NEC and Nicira see VXLAN and NVGRE as not capably tackling the network virtualization problem.
“VXLAN and NVGRE are complementary” to OpenFlow, NEC’s Clark says. “They provide address virtualization, but not network virtualization. Having the control within the network is still required especially for large deployments being contemplated for these, where VLAN exhaustion is an issue.”
Clark says NEC will soon demonstrate interoperability between the company’s ProgrammableFlow switches and Microsoft’s Windows Server 2012 with NVGRE to show the complementary nature of the two technologies.
Nicira’s Casado says NVGRE and VXLAN are just not up to the task at hand.
“They are tunneling protocols that are just a way of getting a packet across a network,” he says. “We don’t care what kind of tunneling protocol you use. We’re very happy to support NVGRE and VXLAN if anybody asks us to, which no one has yet.”
In the data path, VXLAN and NVGRE are too slow, he says. They don’t support hardware acceleration on network interface cards.
“These are first cuts at stretching VLANs across an L3 domain,” Casado says. “They rely on an existing but not very ubiquitously deployed control mechanism. They don’t provide what I would consider full network virtualization. You can’t create a 10,000 node VXLAN. You can’t arbitrarily support services. There’s no model for doing security, policy,” etc.
VMware’s Sequeira says he expects VXLAN to be “a complete line-speed, hardware assisted-enabled” technology that “completely removes the need (for applications) to worry about what happens underneath in the actual physical infrastructure.”
In the meantime, enterprises want to be able to customize their networks but also make them adaptable, something they are finding difficult to do with closed homegrown scripting and vendor-specific attributes for configuration and extensibility.
“Large enterprises are looking at this as a way to get back on the standards track and not be tied to homegrown systems,” says HP’s Gillai. “Because of the need to have very granular control of policy in their systems, they’ve built whole worlds of scripted systems to provide that with SDN you’ll be able to do in a much more elegant fashion.”
And it can’t come too soon. IDC says OpenFlow hardware, software and services, starting from a barely detectable base this year, will be a $2 billion market by 2016.
Big Switch is in the middle of the building momentum. In the first quarter of this year, it shipped eight times as many OpenFlow controllers as it did in the fourth quarter of last year. And last year, when less than 10% of the conversations around OpenFlow and SDNs turned into trails, now 70% do.
“We’re understaffed for that level of change in the business,” Big Switch’s Forster says. “The market in January completely turned on us. It was like night and day.”
