by Steve Woo

SD-WAN is the application of SDN principles to the WAN. SDN provided for the separation of the control plane from the data plane, with an open API between these two elements. There was strong focus on enabling the programmable control to come from a different solution than the provider of the data plane forwarding elements. Therefore initial expectations of an SD-WAN API might be for the same functionality.  However, just as the architectural principles have morphed to meet the requirements and realities of the WAN, so must the focus of the APIs.

SD-WAN has focused more on the abstraction of network configurations, moving towards business intent and application aware policies. Enterprise wide policies were more desirable than node by node configuration. This abstraction also applied to the simplification of the use of multiple WAN circuits. The goal became a virtual WAN or logical overlay network that was independent of the physical underlay networks and providers. One aspect of this overlay is innovative methods for controlling the flow of traffic across different underlays and selecting paths across the SD-WAN overlay. 

Therefore the first important consideration for this API is that its goal is to interface with a unified network of multiple and like SD-WAN nodes – an “SD-WAN island.” The goal of directly communicating with individual and interoperable SD-WAN devices is further off in the horizon.

It also became apparent in the WAN environment that requiring flow by flow decisions to be made by a separate controller that was remote over WAN links was not a practical nor desired architecture. This further reinforces that an SD-WAN API for interoperability should be at the higher level in the system stack.

The ongoing efforts of the Open SD-WAN Exchange (OSE) working group is exactly focusing on defining an API at this level. The goal of the enterprise consumer of SD-WAN solutions is to achieve interoperability between these islands of SD-WAN networks. The API will enable a consistent business intent defined in an uber service definition layer to be implemented across different SD-WAN islands. Each domain specific orchestrator or controller  will use lower level APIs to interface to their individual SD-WAN nodes. Enterprises desire the ability to leverage multiple SD-WAN solutions both for second sourcing as well as enabling interoperability in merger and acquisition situations.

Within this framework there is also a priority or phasing of the business intent that should be supported by this API. This aligns with the original goals of SD-WAN described earlier. The ability to declare the business priority of applications to determine the link and path selection across the overlay is foremost. As is the ability to define the reachability and also the segmentation and security requirements across the network.  

There is also another very important use case for an SD-WAN API. This is more likely to come from service providers seeking to implement a managed SD-WAN solution. The use case is to integrate an SD-WAN service into the full lifecycle workflow of delivering a managed service. This workflow starts with the process for ordering a service and collecting customer information that will ultimately feed into the service provisioning. These parameters will not only determine the network configuration but also the billing when the service is activated. Single pane of glass operations monitoring as well as automated ticketing for service requests and incident response is required.  

The good news is that SD-WAN APIs along with SDKs already exist and are in use by several service providers.  The OSE efforts can now find common service and configuration definitions to develop APIs for a common uber service policy.

Author bio

Steve Woo

VP of Product and Co-Founder, VeloCloud

Steve co-founded VeloCloud and leads product and marketing strategy. Prior, he led the cloud strategy at Aerohive Networks after it acquired Pareto Networks, a cloud-based networking innovator, where he was VP of Product Management. Steve also spent time as VP of Product Management at McAfee, where he led the development of a next generation firewall after McAfee acquired Secure Computing / Securify where he was VP of Products. Steve worked for Cisco Systems twice, after acquisitions of two companies where he was an executive (Riverhead Networks and Class Data Systems) that resulted in 50x return on investment to investors. Early in his career he worked at SynOptics Communications / Bay Networks where his product line generated $1.7 billion of cumulative revenue, and he also spent time at McKinsey & Company. Steve has an MBA and MSEE from Stanford, and a BSEE from Cornell.