What Would Open Networking Look Like?What Would Open Networking Look Like?

If there's one movement that's clear, in our chaotic networking industry, it's the movement toward "openness." From a marketing perspective, you could argue that the most popular adjective is "open," and we're struggling to find new things to apply it to. The question is whether anything is really happening under the covers. What does an open network even look like?

Network users and operators have long told me they consider "open" to mean "supporting free substitution of components." If I have Box A in my network now, and if I can substitute Box B in its place, I have an open network. OK, but does that mean you can simply drop in one box to replace the other, that the interfaces are all totally identical? Could we accept as an "open" network a network requiring minor tweaks to support substitution? Could we even support major ones?

A Complicated Future
Traditional device networking had three types of interfaces. One class supported port/trunk data plane connections. Another supported control interactions like advertising routes, and a third supported device management. Software components are in a sense like devices. They have their own interfaces, typically called "application program interfaces," or APIs, and placing network software APIs into the same three classes as device interfaces is tempting. In point of fact, network software like a hosted router instance will have those three classes of interfaces, but they'll also have a whole set of APIs that devices never showed -- and these APIs are what make openness complicated in a software-defined future.

Suppose you want to host a single software element you call "Virtual_Router." You have to be able to deploy it on a server, which is going to require software and a set of APIs. You have to be able to manage the server, and manage the router instance, which is another API set. This, remember, is in addition to a router's three standard interfaces.

It gets worse. Suppose you want to be able to scale the port and trunk interfaces of your virtual router; we all know that cloud-hosted applications can scale. Now the port and trunk pieces have to connect with the core router elements -- with another set of APIs. You could easily identify a couple dozen APIs in a complete software-defined network (SDN) or network functions virtualization (NFV) implementation, and a deployed SDN/NFV network might have tens of thousands of them. The classic answer to dealing with this explosion is to publish the APIs in some sort of catalog -- so, in effect, "open" means "open to inspection." This is the definition vendors like.

That doesn't work, because APIs are not like those physical interfaces we saw in devices. Devices interwork in very specific ways. APIs describe not how the collective hosted virtual device works, but how work moves inside that virtual device. APIs support software component workflows, but while a "router" may have standard features, does every router vendor divide its software into the same components, or use the exact same information formats to communicate among them?

Want an example? Let's look at scaling the capacity of network software under load. One vendor might ask for a scaling limit in packets per second in its "scaling control" API, and another might want to scale copies of a component based on CPU utilization of the processor that hosts it. A third vendor might not even accept explicit scaling control. The biggest problem with "openness" today is that open APIs mean more than just published APIs, they mean APIs that agree on the format of information they pass --and that depends on the details of the software implementation.

Enter Intent
Network software groups are attempting to address this issue through a kind of hierarchical modeling based on what's called "intent." Intent models describe the "what," meaning functionality, rather than the "how," meaning implementation. A "virtual router" is first modeled as just that -- a virtual router. It exposes specific properties, explicit APIs. Anything that wants to be a virtual router has to look like this high-level model. Inside it, another level might define "port-instances" and "trunk-instances" that also describe features of pieces of the virtual router. At some point, though, the intent model of a piece contains hidden and perhaps proprietary logic. What's inside is then not "open."

You can, under this definition of "open", substitute one compliant "virtual router" for another. You can, if the virtual router model is decomposed into port- and trunk-instance models, also substitute implementations of these for each other. If, however, the fundamental core routing logic is not modeled separately, then you can't substitute one implementation for another.

What this means is that in network software and software-driven networking, we save the concept of openness by admitting that everything isn't open, and by describing that which is open in a way that doesn't allow for variations in implementation or proprietary extensions. It means talking about "open APIs" is silly, because it means nothing in context. The future of openness is the future of describing software models that separate function from implementation.

What we should be doing is building those models. If we can define standard structures for devices and networks of devices, and if we can build them on the intent-based hierarchies described here, our future software-defined network elements will be open everywhere that's realistic, and that's as good as we can hope for.

Follow Tom Nolle on Google+!
Tom Nolle on Google+