packets between servers or other connected devices. These switches consist
of two “planes,” or layers of the router
interface: the data or forwarding plane,
which handles the routing of data packets to its network destination; and the
control plane, which creates the routing tables that determine how packets
are sent to a destination. The control
plane is also responsible for managing the connections between switches,
handling errors and exceptions, and
defining quality of service for different
types of packets.
SDN decouples the link between
the switch itself and the data-routing
instructions, while adding an application programming interface between
the two. These now “virtual” switches
are not tied to any single piece of hardware
or groups of devices, and thus can allow
higher-level applications to pull data or
reconfigure network resources from any
connected device on the network.
“We’re still stuck in this manual configuration era,” Harding says. “But [now]
you can program the network, [there are]
a million applications you can pursue.”
SDN can be defined as a three-tiered
“stack” architecture, in which appli-
cations and high-level instructions sit
in the top tier, a controller sits in the
middle directing data traffic, and a
third tier resides at the bottom, con-
taining physical and virtual switches.
Each control device within a network
is equipped with one or more interfaces, which enables the device to communicate with other components. In
networking parlance, these interfaces
are described directionally, with each
direction related to the relationship
between devices. For example, a northbound interface describes the communication with a higher-level component,
while a southbound interface allows a
particular network component to communicate with a lower-level component.
In SDN, the northbound API interface
on the controller enables applications
and the overall management system
to program the network and request
services from it. This application tier
often includes global automation and
data management applications, as well
as providing basic network functions
such as data path computation, routing, and security.
Currently, no formalized standards
have been ratified for northbound
APIs, with several dozen open and pro-
prietary protocols being developed
using different northbound APIs.
The lack of a standard API is likely due to
the varied nature of applications sitting
above the controller, which can include
managing cloud computing systems,
network virtualization schemes, and oth-
er disparate or specialized functions.
Nevertheless, work on open northbound APIs is being done for specific
vertical applications. OpenStack, a
cloud computing effort backed by
Arista Networks, Big Switch Networks, Brocade, VMware, and other
SDN vendors, has developed the
Quantum API, which is a vendor-ag-nostic API for defining logical networks and related network-based
services for cloud-based systems.
Several vendors have developed plug-ins for Quantum, which has helped it
to become the default networking API
for OpenStack, one of the largest open
source cloud management platforms.
Though not explicitly required by SDN,
OpenFlow is a protocol often used as
the southbound API that defines a set
of open commands for data forwarding. These commands allow routers to
an example of sDn architecture.
SDN Controller Platform
Switch Switch Virtual Switch Virtual Switch
Data Warehouse Cloud Computing
(proprietary and open solutions)
Southbound API, ex. OpenFlow