Open Networking Is Not Necessarily Unified

Open networking is progressing along so many different tracks these days that it’s hard to keep them straight. But even worse than simple confusion is the very real possibility that too many open initiatives will actually make SDN less functional and prone to the same isolation that plagues legacy networks.

What is most interesting, of course, is the degree to which long-time proprietary hardware and software vendors are embracing open source on the network. Despite some industry cynics, there is very little evidence that anyone is trying to take control of a given open platform. Rather, there seems to be broad recognition that basic openness and interoperability are necessary to deliver more advanced benefits – ones that will likely open the channels for premium revenue streams – higher up the stack.

A case in point is Microsoft, which last month released a Linux-based switch operating system on the Azure cloud. The aptly named Azure Cloud Switch, which Microsoft is contributing to the Facebook-led Open Compute Project, functions across disparate networking devices as would any open switch, but the company says it also layers a range of advanced testing and debugging capabilities on top of the basic Linux kernel to enable rapid functions like application development and scale. At the same time, Microsoft can continue to refine the platform for specialized use cases and industry verticals using a specialized API-based interface that communicates directly with ASICs on the switch hardware.

Other open source projects are making their way into SDN platforms through specific industry tie-ups. HP recently announced support for the PicOS operating system from Pica8 for the Altoline switch portfolio. The move brings OpenFlow 1.4 Layer 2/3 capability to HP’s Virtual Application Networks (VAN) controller, enabling highly configurable network environments on either 10 GbE or 40 GbE infrastructure. Users will also gain full access to HP’s SDN App Store, where they can tap into OpenFlow, Open vSwitch and other platforms.

At the same time, standards groups are adding a variety of new capabilities designed to take much of the guesswork out of abstract network configuration. As we mentioned last week, the Open Networking Foundation recently released a new pair of northbound interfaces that would add “intent-based” application control to OpenFlow. The Aspen and Boulder projects would allow apps to communicate their needs to the SDN controller, which would then configure the appropriate resources. The practical effect is that it would allow developers to streamline their apps, and thus their ability to navigate disparate infrastructure, by not having to carry their own network information.

It’s important to realize, however, that all of this openness does not guarantee full interoperability. As Moor Insights & Strategy’s John Fruehe explains on Forbes, there are big differences between open networking, open SDN and open source. An open source solution, for example, might not include open networking, and vice versa. And any given SDN solution could be open, closed or both, depending on how it is configured. About the only solution available right now that conforms to all three is Juniper’s OpenContrail system, which is available for free but, like Red Hat, does not come with free support.

As the market for open solutions grows, including those that are based on widely used protocols like OpenFlow, enterprises will still struggle to produce top-to-bottom, end-to-end multi-platform network architectures.

This is not necessarily a bad thing. A completely unified abstract network stack would likely be a very sclerotic entity with a lengthy approval process for even basic upgrades. The modern data environment is simply too dynamic for such an approach, which is why a vibrant developer ecosystem that conforms to a flexible open platform is usually how it’s done.

Most enterprises reserve the right to define their networks as they see fit, and this will become easier when configuration is done in software alone. But the flip side of that is that some network functions might not next extend across the entire environment, even if they are open.

Photo courtesy of Shutterstock.

Latest Articles

Follow Us On Social Media

Explore More