If you look at the developments in the SDN, NFV, and cloud areas, you find that there’s a lot of discussion about “services” and “APIs”. One of the things I realized when I was reviewing some material from Intel/Aepona and Cisco was that there’s a bit of a disconnect in terms of how “services” and “APIs” are positioned, both with respect to each other and with respect to the trio of drivers we read about—SDN, NFV, and the cloud.
The term “service” is fairly well understood at the commercial level; a network service is something we buy from a service provider and it connects us to stuff. At the technical level, a service is a cooperative relationship among devices linked by transmission facilities, for the purpose of delivering traffic. One thing you can see straightaway (as my British friends would say) is that services can be hierarchical, meaning that they can be made up of component elements. These components are commercially “wholesale” elements, and technically there’s no clearly accepted name for them. We’ll call them “components”. Things like IMS or EPC or a CDN are components.
An API is an interface through which a software application gains access to a “service”, which in most cases is really one of our “components”. Like services, APIs are a bit hierarchical; there are “high-level” APIs that essentially mimic what we can do with appliances (phones, for example) to request service, and lower-level ones that move toward the mission of organizing network elements in that cooperative behavior I mentioned. High-level APIs are simple to do and don’t pose any more risk than the use of phones or other user devices would pose. Low-level APIs could in theory put the network into a bad state, steal resources from others, and create security issues.
Cloud networking means the creation of a resource network to hold application resources and the connection of that network to the user community. In OpenStack, that’s the Quantum interface. Using Quantum I can spin up a virtual network and then (using Nova) add VMs to it. Quantum lets me define a means for connecting this structure to the user—a default gateway for example. So you could assume that everyone who’s talking about virtual networks and virtual network services would be talking Quantum, right? If only that were true!
Let’s look at SDN from Quantum’s perspective. If I want to build a virtual network, I need to specify the connection points and service levels. I can generate a BuildSDN(endPointList, QoS) command and have my Quantum interface build the result, right? Well, maybe. The first problem is that there are a number of connection topologies—LINEs between endpoints, a LAN on which all the endpoints are connected, or a TREE for multicast distribution. Quantum most often assumes a virtual LAN subnet, but there are use cases in both SDN and NFV (“service chaining”) that imply the network connection is a set of paths or lines. I can fix this by adding a parameter to my BuildSDN, the connectionTopology. The second problem is that OpenFlow doesn’t know anything about connection topologies even if I specify one, it only knows individual forwarding table entries. Something has to organize the SDN request into a set of forwarding table changes so the Controller can send them to the devices. If you look at the SDN stories of most vendors, you find it’s silent about how that happens. So we have a wonderful BuildSDN API and nothing to connect it to.
NFV faces similar challenges. The body wants to identify current standards for various roles, but API standards are rare. Most of the network standards we have are really interfaces between devices and not APIs that link software components. How does an interface translate to an API? Do we have to connect two virtual functions with a communications path just because the devices they came out of were connected that way? Suppose they were running on the same platform? And what kind of “API” would we like to see something like IMS or EPC expose? How would those APIs relate to SDN APIs if the activity we were supporting could have elements of both?
The logical way to plan for the future of network services is to consider what’s driving the changes. That’s the cloud. Quantum is the interface that defines “network-as-a-service” to the cloud, and so it’s the gold standard of high-level deployment APIs. We need to be looking at SDN and NFV through Quantum-colored glasses to establish how their own APIs will be derived from the highest-level Quantum models.
But that’s only part of the story. What does an SDN service look like? Is it just an Ethernet or IP service pushed through SDN devices, or is it a service that has properties that can be generated in virtualized, centralized, infrastructure and couldn’t have been offered before? If we take the former view, we cripple the SDN benefit case. Are all NFV’s virtual functions simply models of existing devices, connected in the same way and offering the same features? If so, we’re crippling the benefits of NFV. Deploying stuff is essential for consuming it, but deployment of a flexible framework lets us compose cooperative relationships among functional elements in many different ways, some of which might even result in a whole new way of presenting services to end users. Can we say that any of our current activities are thinking about that?
Cisco is publishing a rich set of intermediate APIs under its ONE banner. Intel, with the acquisition of Aepona, is entering the world of intermediate-level APIs as a means of exposing provider assets. We need a roadmap now, from both vendors. We need to understand how these new and wonderful APIs fit in the context of Quantum, and through that context into both SDN and NFV. Absent that map, we have no way to navigate the value proposition of APIs…or of SDN, NFV, or cloud networking.