We all understand the promise of SDN and NFV and its ability to unlock agility, flexibility and speed for the network. But the key to unlock these promises are the application programming interfaces (APIs) that describe how the network will be programmatically controlled and therefore consumed.

But what if your key – your API – only works on certain locks, or has an expiration date, or worse yet doesn’t work on your lock altogether? That’s essentially the situation service providers can find themselves in today. Let me explain.

Although essentially every service provider is moving to deploy SDN and NFV, we know that one of the big impediments holding providers from full commitment is the lack of standards. I was recently at a standards body meeting where we were discussing the standardization of SDN APIs. We were assessing different users and how their applications would consume network resources.

As the debates went back and forth, I had an epiphany. No matter how carefully and thoroughly we consider everything that we know today, there is plenty more that will happen in the future that we cannot possibly anticipate or account for today.

So, if everything around networking is changing, how can we possibly lock down the APIs through which the network will be programmatically controlled? APIs will undoubtedly need to change accordingly.- Abel Tong, Senior Director, Ciena Blue Planet

Looking at networking today, everything is changing. We have mobile, the cloud and the Internet of Things (IoT). Users are changing. And, these users have new requirements. They want everything available at any time and from anywhere. Applications are changing. New applications are dynamic, bandwidth hungry and may interconnect multiple users. Technology is changing. SDN and NFV are bringing new capabilities, features and business models. White box and open compute are emerging as viable alternatives to legacy, bespoke vendor proprietary platforms.

So, if everything around networking is changing, how can we possibly lock down the APIs through which the network will be programmatically controlled? APIs will undoubtedly need to change accordingly.

There is no doubt: APIs are critical. So, if we cannot yet create the ultimate APIs because we don’t know what they will need to solve, then what should we do? Simple. We should solve for things that we do know. Along that line of thinking, any SDN or NFV-based API created today needs to bake in these three characteristics or face being locking service providers out of the full benefit of SDN/NFV:

1) An API must be simple

An API should be as simple as possible, but no simpler. Yes, that’s a tight rope to walk, but it is critically important. There are billions of users consuming network services – mobile, cloud and the IoT. For these users – i.e., the vast majority of users – simplicity is paramount for understanding and then correctly consuming the network.

2) An API must be extensible

While the simplest API may address the needs of many; simple is not sufficient. Some users will need incrementally more control. For example, a given user may need control over elasticity while another needs control over quality of service. As different requirements come up, a service provider needs to be able to incrementally differentiate for more control. In other words, a service provider needs to be able to make changes and deliver the services, functionality and APIs to meet their customer’s needs. And further, a service provider needs to make these changes quickly and efficiently so as to meet customer needs when their customers need them.

3) You need more than one API

Some users will be highly sophisticated and require a full-featured API. These users may include service providers, Internet Content Providers (ICPs) and high-end enterprises, which operate networks critical to their businesses. The sophisticated user needs advanced capabilities and the ability to programmatically fine-tune the network to meet their specific needs. Thus, APIs for the sophisticated users must be robust and feature rich.  The sophisticated API is clearly different from the simple API. So again, a service provider needs to create and introduce extended APIs, quickly and efficiently so as to meet customer needs when their customers need them.

So where do we go from here? Consider the following example of Blue Planet’s Carrier Ethernet (CE) services API. The API is extremely simple. The API for Ethernet Virtual Private Line (EVPL) consists of 2 end-points, VLAN IDs, and a bandwidth profile. If new services drive changes, a service provider can modify Blue Planet’s model driven template definitions and expose additional functionality through the API as needed.

For example, one Blue Planet customer enhanced their base CE services API to include hierarchical QoS control. If a comprehensive, feature rich API is required, Blue Planet can support a more robust API based on a comprehensive CE resource definition. So, for example, a service provider can allow for a comprehensive API (e.g., MEF’s Network Resource Provisioning (NRP) project), which essentially exposes all CE service attributes. So, with Blue Planet, simple, modified and advanced can co-exist simultaneously.

Now, if you are waiting on standards, don’t hold your breath. If you wait long enough, the on-going standards activities will eventually come up with some APIs. But the way things are going, these APIs will only reflect the best of today’s knowledge. And can you really afford to wait and hope anyway?

We can all agree: the only constant is change. New applications will drive the need for new services, functionality and APIs. So what can you do? Blue Planet enabled service providers will have the ability to both support the standards and embrace change. Simple, extensible and multiple APIs are a part of the secret sauce inside Blue Planet’s model driven templating. The recently announced Blue Planet DevOps Toolkit gives service providers and Blue Planet partners the ability to extend their Blue Planet platform on their own and as their customers demand. It’s the master key to unlocking SDN and NFV for your network. For more details, check out our website and contact us for more information.