Demystifying SDN: SDN via APIs
In my previous blog, I explained the basics of Software Defined Networking (SDN), how SDN has evolved to this point, the separation between the control plane and data plane, plus we named the three main flavors of SDN: Open SDN, SDN by APIs and SDN via overlays. We also covered the principles of the first approach, Open SDN.
In this blog, I will cover the implementation of this technology via APIs, a preferred method used by traditional networking hardware companies.
SDN implementation via APIs refers to southbound APIs that configure and program the control plane active on the device. There are a number of legacy network device APIs in use that offer different degrees of control (SNMP, CLO, TL1, RADIUS, TR-069, etc.) and a number of newer ones (NETCONF/YANG, REST, XMPP, BGP-LS, etc.) that offer different degrees of control over the network devices, data plane, topology, etc., each having different advantages and disadvantages. I won’t cover them in depth in this blog post but I want to make sure we all understand one key difference between them and the Open SDN approach: OpenFlow is used to directly control the data plane, not just the configuration of the devices and the control plane.
SDN by APIs Overview
Let’s start with some understanding on how network configuration and management is traditionally done. In the networking world of today, we still configure most devices though a Command Line Interface (CLI) by either connecting to the console of a device or through telnet/ssh of the device. Each device is then configured individually. That has been networking configuration 101 for more than 25 years.
The new SDN approach I covered in my previous blog has many technological and operational advantages, but it requires a company, institution or operator to replace old hardware for new hardware that supports the technology, and in some cases, new protocols like OpenFlow.
Obviously, no company is going to replace all of their hardware overnight, as it would require considerable expense, implementation and architecture challenges that, until resolved, could impact company operations. In addition, there would be plenty of non- technical issues, like employees knowing device X and network OS Y like the palm of their hands and not looking forward to the time it might take to learn new technology and processes.
When a company decides to transform to a software defined networking infrastructure, they may not get support from their existing Network hardware vendor, which may have been enjoying hefty margins in network hardware sales and not thrilled to push a technology that will make their expensive boxes replaceable for cheap vendor agnostic white boxes.
Architectural views of SDN by API
The left image shows an architecture view of a traditional network device (router, switch, etc.) with the software components and applications (Upper Rectangle) and hardware components (Lower Rectangle) such as ASIC (application specific integrated circuit for packet processing) and memory.
By adding a RESTful API interface we add an additional abstraction layer and upgrade legacy devices allowing to be controlled by an SDN controller using non OpenFlow standards.
SDN by API Vendors:
Juniper Networks
We can argue that Juniper was one of the SDN pioneers in this area, through JunOS SDK, providing a rich set of tools for programmability and automation for all JunOS compatible devices. Some of the options available would allow you to control data plane packet processing, plus a wide variety of device functions. This SDK was created before SDN was popular, but as academia was already working on the SDN idea though Ethane back in 2007, perhaps Juniper was already looking to the SDN future back then. In present day, Juniper launched the SDN controller contrail, using NETCONF and XMPP protocls instead of OpenFlow.
We can argue that Juniper was one of the SDN pioneers in this area, through JunOS SDK, providing a rich set of tools for programmability and automation for all JunOS compatible devices. Some of the options available would allow you to control data plane packet processing, plus a wide variety of device functions. This SDK was created before SDN was popular, but as academia was already working on the SDN idea though Ethane back in 2007, perhaps Juniper was already looking to the SDN future back then. In present day, Juniper launched the SDN controller contrail, using NETCONF and XMPP protocls instead of OpenFlow.
Cisco Networks
We can’t talk about networking without talking about Cisco Networks. Cisco originally had its own proprietary program called Cisco onePK, consisting of a broad set of APIs that were proprietary for Cisco devices. Cisco now has two SDN-via-API controllers: the APIC-EM (Application Policy Infrastructure Controller-Enterprise Module) and the the APIC-DC (focused on Data center). Cisco is also implementing a new policy based protocol called OpFlex.
We can’t talk about networking without talking about Cisco Networks. Cisco originally had its own proprietary program called Cisco onePK, consisting of a broad set of APIs that were proprietary for Cisco devices. Cisco now has two SDN-via-API controllers: the APIC-EM (Application Policy Infrastructure Controller-Enterprise Module) and the the APIC-DC (focused on Data center). Cisco is also implementing a new policy based protocol called OpFlex.
Arista
Arista Software Driven Cloud Networking (SDCN), combines the principles that made cloud computing the unstoppable force that it is: automation, self service provisioning, and linear scaling. Arista’s SDCN Is based around its API-centric definition of SDN and about the scaling of the existing control plane with different APIs.
Arista Software Driven Cloud Networking (SDCN), combines the principles that made cloud computing the unstoppable force that it is: automation, self service provisioning, and linear scaling. Arista’s SDCN Is based around its API-centric definition of SDN and about the scaling of the existing control plane with different APIs.
OpenDaylight
Opendaylight is a bit of a hybrid, on one site it uses OpenFlow so we may be tempted to think it is purely an OpenSDN approach.. However the ODL controller also supports southbound APIs that program the legacy control plane on network devices, using plugins such as NETCONF and BGP-LS/PCE-P. There are different companies, for example, Fujitsu, that is developing its SDN Controller (Virtuora) based on OpenDaylight and no longer being Open Source.
Opendaylight is a bit of a hybrid, on one site it uses OpenFlow so we may be tempted to think it is purely an OpenSDN approach.. However the ODL controller also supports southbound APIs that program the legacy control plane on network devices, using plugins such as NETCONF and BGP-LS/PCE-P. There are different companies, for example, Fujitsu, that is developing its SDN Controller (Virtuora) based on OpenDaylight and no longer being Open Source.
Summary
SDN via APIs is a hybrid approach that will make the transition to the controller-based networking technology model more gradual and easier, especially for companies with a lot of legacy equipment or with close ties to specific proprietary networking vendors. Another plus is not having the centralized point of failure you may face in a pure OpenSDN. Compared to the other two approaches Tt ranks in-between for scale and performance..
On the negative side you won’t have support for Stateful Flow awareness or Deep packet Inspection plus it won’t escalate easily to mega data centers.
For additional information, please check part I of this series; Demystifying SDN: Open SDN Approach and view information on our just released Dell EMC NFV Ready Bundle for VMware.
Comments
Post a Comment