This article is part of my SDN/network virtualization series “Network Virtualization 101”. To view other articles in this series and/or learn more about SDN and network virtualization, please visithttps://www.linkedin.com/today/author/0_1J4WrxUu5ZhIszQwsUUcg_?trk=prof-sm or http://www.dhimanchowdhury.blogspot.com .
From the simplistic purview, SDN (Software Defined Networking) provides the means of dynamism in “networking infrastructure” solutions by facilitating programmable network control, centralized management and orchestration. For network control, it decouples control plane (think of it in terms of a set of conventional applications/protocol suits e.g. Firewall, NAT, load balancer and BGP etc) from data plane (in other words, networking equipment having only packet forwarding mechanism without conventional protocol suits) and allows centralized control over networking infrastructure. There are few variations to this approach, for example, a networking equipment with hybrid NOS (network operating system) may choose to implement both control plane protocols (conventional protocols suits) and SDN APIs/protocols in the same platform. On the other hand, some networking equipment may only implement agent such as “Indigo” allowing the device to solely depend on SDN controller for flow instructions. We will discuss such implementation later in this article.
Figure 1. Typical SDN (software Defined Networking) setup.
Figure 1. Typical SDN (software Defined Networking) setup.
An SDN controller connects to Switch/routers or similar networking equipment through downstream communication interface using either API or protocol such as “OpenFlow” and “OVSDB”. This downstream communication interface (a shared boundary between two computing endpoints) is known as southbound Interface. Similar to southbound Interface, upstream communication from the controller to other server base tools such as “OpenStack” are realized through Northbound Interface. For example, “Neutron” server elements of OpenStack can be connected to “OpenDaylight” SDN controller using RESTful API as shown in the figure below. Let’s not get overwhelm by this, just keep the concept in mind as we explore SDN APIs and protocols in the subsequent sections. A detailed discussion on OpenStack and OpenDaylight connectivity will be presented in succeeding articles of this series.
Figure 2. OpenDaylight controller uses RESTful API to connect OpenStack Neutron server at Northbound Interface.
We discussed that both northbound and southbound interfaces use either API and/or protocols. A simplistic purview is that both are abstractions: API is top-down while protocol is bottom-up. An API (Application Programming Interface) is more suitable for client/server setup where API acts as the messenger between the two entities while tightly binding them together. We could further understand API by applying the analogy of restaurant order processing where “waitress” is a go-between customer and the kitchen to process the order and serve food. Here, API is synonymous to “Waitress” function from the operational perspective. Conversely, the protocol is a set of rules that governs communication between to networking end points. In order to establish a successful communication, both endpoints must speak the same language.
While some protocols and APIs may be newly introduced for SDN purposes, many other protocols/APIs referred are implemented or in use elsewhere. For example, OpenFlow, OVSDB and ForCES are new sets of protocols for the southbound interface (SBI) whereas BGP and XMPP are not new. BGP for example, a de-facto standard for how various routers within the internet “network mesh” communicate with each other.
The following table attempts to simplify the understanding of various SDN APIs/protocols and their intended use. Readership will find this table useful for SDN controller connectivity with network endpoint devices.
Table 1. Typical examples of SDN protocols and APIs.
Table 1. Typical examples of SDN protocols and APIs.
[Please note, though I have listed Opencontrail and OpenVirtex as SDN controllers, those are more of a network hypervisor or network-level virtualization controller. We will explore further on the network hypervisor type controllers and other NOS type SDN controllers in the later part of this series.]
Among the typical SDN controllers listed in table 1, OpenDaylight provides a wide range of SBI protocols/plugins including LISP, SNMP and other Wireless Access point and IOT (Internet of Things) protocols. As of writing this article, there has been proposal or talks MP-BGP EVPN as standard control plane protocol for VxLAN. If MP-BGP EVPN considered a standard interface for VxLAN configuration, it may find its to some of the typical controllers as SBI protocol.
In the next article, I will discuss various SDN protocols and APIs starting with ForCES (Forwarding Control Element Separation) framework that was proposed by IETF as an alternative to OpenFlow. Some of the largest telecom service providers in the world are exploring the potential of deploying ForCES master-slave protocol framework. Find out why… please stay tuned for next articles.
Comments