Software-Defined Cloud Networking
-Whitepaper-
Software-Defined Cloud
Networking
Whitepaper
Table of Contents
I.
Executive Summary .................................................................................................................... 1
II.
Transition to Software-Defined Cloud Networking.............................................................. 2
III. Introducing Basebox................................................................................................................... 3
IV. Benefits of a Layered Controller .............................................................................................. 4
V.
I.
Conclusion .................................................................................................................................... 5
Executive Summary
With the steady growth of the cloud computing domain, data centers are rapidly expanding, thus
improving their scalability, ease of use, and innovation cycle speed becomes increasingly
important. In consequence the transition from specialized network functions on proprietary and
closed hardware to software-defined cloud networking is necessary to support this growth.
BISDN‘s approach to this challenge is a software solution named Basebox, a modular SDN
controller designed to manage data center whitebox switches. Basebox is capable of controlling
multiple whitebox switches by forming a single, giant switch abstraction, thus it centralizes
configuration and management of cloud computing infrastructure, such as OpenStack. The
solution utilizes a common Linux interface for ease of network configuration and improved
usability. Furthermore, the distributed, layered controller architecture based on open interfaces,
including OpenFlow, increases scalability, improves uptime and limits vulnerabilities.
Keywords: whitebox switch, SDN, cloud networking, OpenFlow, OpenStack
BISDN GmbH
1
Software-Defined Cloud Networking
-Whitepaper-
II.
Transition to Software-Defined Cloud Networking
Until recently the networking industry used vertically integrated, proprietary hardware to deliver
specialized network functionality. However, with software-defined cloud networking operators are
moving towards the use of commodity hardware with horizontal open interfaces using opensource frameworks and applications (see Figure 1). These network apps can host virtually any
network function while also enabling rapid innovation. Speaking of open source, the OpenStack
project1 is currently the largest initiative to provide cloud-computing software leveraging off-theshelf servers, while the Open Compute Project2 certifies hardware that can be used to build entire
data centers.
Specialized
features
Specialized
control plane
Specialized
hardware
APP
APP
Control
plane
or
APP
APP
Control
plane
or
Control
plane
Whiteboxes
Networking industry in 2010:
Vertically integrated
Closed, proprietary
Slow innovation
Horizontal open interfaces
Rapid innovation
Figure 1: Transition to software-defined cloud networking
The transition to software-defined cloud networking by integrating networking hardware into
cloud-computing software offers major advantages with respect to usability, scalability, high
availability and rapid innovation cycles:


1
2
Usability: Configuring data center switches used to involve a vendor-specific API or GUI.
Configuring a server is usually done via a Linux networking tool. Having a unified interface
for both requires less staff training and less documentation.
Scalability: Data center configurations and sizes vary greatly. Applications are expected to
run on a wide range of different setups without the need to be modified for specific
deployments. That requires several features such as the ability to perform in networks of
different size (no. of servers, ports, amount of control messages, etc.), the ability to
www.openstack.org
www.opencompute.org
BISDN GmbH
2
Software-Defined Cloud Networking
-Whitepaper-


automatically discover networks of arbitrary size to ease configuration, but also a scaling
fault tolerance to ensure high availability. The application scalability problems can however
be mitigated through use of abstraction layers or protocols like OpenFlow.
High availability: Data centers are a critical part of an operator’s infrastructure. An
important aspect is to improve application stability and performance. Leveraging the SDN
paradigm creates new ways of achieving a high availability by preventing outages and
minimize vulnerabilities, particularly in scaling systems.
Rapid innovation cycles: Data center operators no longer have to wait for big hardware
vendors to release new products, security updates or bug fixes. Instead they can buy
vendor-independent hardware and use open source software, have full control over it and
adapt it to their current needs. Moreover, they can upgrade, change and rapidly deploy
their software whenever it is required and thus increase service agility.
As in any other business, data center operators try also to reduce operational costs as well as
optimize hardware investments. Thus, all of the above factors have to be considered by customers
(and their admins) transitioning from proprietary to open source solutions.
III.
Introducing Basebox
BISDN‘s solution for software-defined cloud networking, named Basebox, was built to integrate
a domain of whitebox switches, networking apps, Linux and cloud-computing software like
OpenStack. The Basebox package consists of the switch operating system (BISDN Linux
Distribution) and a separate, redundant, controller package containing two network controllers
(see Figure 2). Basebox follows a layered controller approach of controlling data center switches
and as such is a modular. It combines a controller handling the Linux networking tool integration
(baseboxd) and a controller creating a switch hardware abstraction (CAWR - Capability AWare
Routing). Both controllers communicate with each other via OpenFlow that adds flexibility and
scalability. Thus, the controller package does not necessarily have to be deployed on the switches
but can be placed anywhere in the network as long as it does have IP connectivity to the whitebox
switches.
baseboxd has a northbound Linux netlink interface and translates commands into OpenFlow
messages to control one or multiple southbound OF-DPA (OpenFlow - Data Plane Abstraction3)
compatible whitebox switches. Since it has a Linux interface, one can run any Linux networking
application on top of it. As in other approaches, for each OpenFlow switch port that is attached to
baseboxd a tap interface in Linux is created which can then be used like any other tap interface,
e.g. be added to a Linux bridge or have a VLAN configured. baseboxd will translate any operation
on the tap interface into OpenFlow rules and configure the switches accordingly. It is also able to
3
www.github.com/Broadcom-Switch/of-dpa
BISDN GmbH
3
Software-Defined Cloud Networking
-Whitepaper-
handle control messages like ARP, interpret them, update the network state in Linux and if required
send the corresponding reply. The most important app currently seen is OpenStack (ML2 plugin)
that smoothly integrates with baseboxd as well. Using baseboxd, the network of an OpenStack
cloud can be automatically configured, e.g. when a new tenant configuration is applied.
APP
APP
Linux application / netlink
baseboxd
Application controller
CAWR
Giant switch abstraction
Whiteboxes
Redundant
Array of
Inexpensive
Switches
Switch
BISDN Linux Distribution
Figure 2: Architecture of Basebox
CAWR, on the other hand, creates a single ‘giant switch’ abstraction from a domain of whitebox
switch hardware. It discovers the topology of the switch domain, manages all its internal & external
ports, supports Multi-Chassis Link Aggregation - MLAG, does automatic failover, and handles
congestions and load balancing by setting up traffic paths inside the domain. It performs link
monitoring via Link Aggregation Control Protocol - LACP (to hosts) & Link Layer Discovery Protocol
- LLDP (internally); and in general translates all FlowMods, that it receives from baseboxd, to the
switches using internal algorithms.
IV.
Benefits of a Layered Controller
The approach of a layered OpenFlow-based SDN controller has many benefits. Since the main
parts, baseboxd and CAWR, are separate modules, they can be developed independently from
each other. This leads to even faster innovation cycles. baseboxd can be adapted to new apps or
new Linux Netlink features without caring about any changes to the switch hardware.
BISDN GmbH
4
Software-Defined Cloud Networking
-Whitepaper-
On the other hand, CAWR developers can implement new routing features or protocols without
having to care about the networking app, as they just deliver a switch abstraction over the
northbound interface. Some new features might need adaptations in both controllers, but as long
as the protocol between them supports these, there should be no drawbacks. Moreover, as the
involved protocol is OpenFlow - which is open source - and many other technologies (OpenStack,
ML2, Linux, Netlink and ONIE) used are open as well, developers do not have to wait for specific
releases from hardware vendors; they can upgrade their software whenever they want and have
full control over their data centers.
When developing Basebox, we were striving to create the most scalable solution. Compared to
other solutions on the market, one instance of the software should be able to control multiple
hardware switches at once by forming a single switch abstraction from an array of whitebox
hardware (any vendor, but OF-DPA compatible). This enables the user scale his switching capacity
without any changes to the application that is used.
As an additional feature, the controller software does not need to run on the switch itself, it can be
deployed anywhere: on a physical host, a virtual machine, or a container, as long as the network
connectivity meets the demands of the application. That features again leads to scalability, as the
controller resources can also be adapted to the needs of the application (some might need more
control traffic, some less). To reduce the resources consumption of the controllers in general, we
designed them to store as little (switch) state as possible. Instead, the controllers are able to
retrieve any relevant information from the switch on demand. We also optimized the used link
discovery and monitoring protocols and reduced control traffic to the necessary minimum, as it
can be a constraint in large switch domains. In such domains, an automatic discovery system is
required as well to reduce costs and a scaling fault tolerance to ensure high availability of the data
paths as well as the controllers.
One of the main reasons to develop Basebox was the integration into Linux and cloud-computing
software such as OpenStack. Instead of manually configuring the switches of on OpenStack
installation (e.g. by configuring all VLANs on all ports), Basebox will listen to the ML2 plugin and
automatically configure the switches accordingly. For example, whenever a VM is created in an
OpenStack tenant network, the OpenStack control node will notify baseboxd / Netlink, of such
event and configure only the required switch ports. Of course, any other Linux networking tool
(e.g. Quagga) can be used and even manual configuration of Basebox is possible with the usual
Linux tools like iproute2. So, in terms of usability the data center admin can control the switches
in the same way as the servers and does not need to learn new vendor specific API/GUIs.
V.
Conclusion
Basebox, BISDNs software-defined cloud solution, allows scalable data center operation on
whitebox switches. Especially targeted towards small and medium sized OpenStack installations,
BISDN GmbH
5
Software-Defined Cloud Networking
-Whitepaper-
the solution provides centralized management of multiple hardware switches while combining
built in fault tolerance with scalability and high availability.
GET STARTED!
Find Basebox on GitHub:
www.github.com/bisdn/basebox
Learn more about Basebox: www.bisdn.de/solutions/basebox
©2017 BISDN GmbH. All rights reserved. BISDN, the Basebox, and the respective logos (the “Marks”) are trademarks and service marks of
BISDN GmbH. You are not permitted to use the Marks without the prior written consent of BISDN GmbH. The registered trademark Linux® is
used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis. All other marks are
used under fair use or license from their respective owners.
BISDN GmbH
6