Motivation for "Northbound APIs" and SDN Programming Language (text)
by
Sasha Shkrebets
—
last modified
Mar 20, 2023 08:04 AM
We are starting a new module on programming SDNs, which has four lessons.
In this module, we will first explore the motivation for
programming SDNs, then we'll look at programming languages for SDNs.
Welcome back.
We are starting a new module on programming SDNs, which has four lessons.
In this module, we will first explore the motivation for
programming SDNs, then we'll look at programming languages for SDNs.
Third, we'll talk about how to
use programming languages to compose SDN control.
And finally, we'll talk about how to
augment existing network controllers to handle more
complicated high level events, such as security
events, traffic load balance events and so forth.
This module will also have a programming assignment and a quiz.
Let's jump in and start talking about the motivation for programming SDNs.
It's worth recognizing that while OpenFlow makes programming
networks possible, it does not make programming networks easy.
It's difficult to perform multiple independent tasks using an SDN controller.
For example, if you wanted to write a
control program that performed routing and access control together.
How do you make sure that the two independent modules don't interfere with
one another, or tell the switches to do things that conflict with one another?
Second, OpenFlow offers a very low level of abstraction.
It provides a control channel to control the flow table entries and switches.
But we're talking about a level of
abstraction that is controlling entries in memory.
Operating at this level of abstraction to perform higher level tasks, like
implement security policies or traffic load balance, is particularly difficult.
We need higher level abstractions to perform these more complicated functions.
Third, the controller only sees events for packets that switches
do not know how to handle, so we've seen in
some exercises already, that we'd like to keep packets away
from the controller after the controller has made a decision.
About how to handle packets for a particular flow.
For example, the POX Controller allows us to
modify flow table entries with the OpenFlow flow mods.
However, since the controller only sees events for packets
that the switches do not know how to handle.
It can be difficult to write policies that
assume that the controller is seeing every packet.
An abstraction that is sometimes helpful for writing higher level programs.
Finally, there can be race conditions.
If the controller is installing flow table rules.
And the correct operation of the network depends on those rules being installed in
a particular sequence across the network or even on a single switch in the network.
Then the incorrect installation of rules
might result in incorrect network behavior.
So we'd like to ultimately have a programming language, a
compiler that ensures that flow table entries are installed correctly.
The solution to this problem is to develop what is being called a Northbound API.
The Northbound API is a programming interface that allows applications.
And other orchestration systems to program the
network at a higher level of abstraction.
Thus far, we have been talking about SDN controllers that use a Southbound API,
like the OpenFlow control protocol, to control flow table entries in switches.
But if we want to implement more complex policies in applications, we would like
to develop an API that the controller exposes to higher level applications.
Here you can see that developers might use a
Northbound API to implement more complex applications such as
firewalls, load balancers, and so forth, and the controller would be
responsible for ensuring that those applications interact correctly.
There are various uses for the Northbound API, including.
Computing paths across the network, particularly paths that comply with
intended policies, computing paths that avoid loops, performing
routing and recovering from failures, and enforcing security policies.
There are a number of possible users for the Northbound API.
Sophisticated network operators who would like to develop and deploy
complex network policies, might write network policies and programs in a
high level language that talks to the controller through a Northbound API.
Service providers might wish to offer value-added services by developing
applications that uses Northbound API to talk to an SDN controller.
Vendors might also package applications and services that sit on top of a
particular switch or controller that are developed using a Northbound API.
Researchers are also actively trying to develop
new Northbound APIs that others can use.
Really anyone who wants to develop capabilities on top of
a Southbound API like OpenFlow, could be using the Northbound API.
A Northbound API offers many benefits.
One is vendor independence.
Different vendors might offer switches, or
other network devices with different Southbound APIs.
Depending on the capabilities of a particular switch or network device.
However, agreement on a small number of Northbound APIs, would allow service
providers, operators and others, to develop
complex applications that run on a network.
Independent of the switches, and network devices,
that are actually installed in the network.
Another benefit is the ability to quickly modify or customize
control, using popular programming languages, like Python, Java or Ruby.
There are many examples of possible
applications that could use a Northbound API.
One is creating a large virtual switch, in other words, making it appear
as though the entire network is controlled by a single virtual switch.
This type of abstraction can simplify many network management tasks.
We'll see in this module that we can
use a Northbound API to implement various security applications.
We can also use a Northbound API to
implement various types of resource management and control applications.
Such as traffic engineering, or load balancing applications.
Middleboxes are proliferating, and it is now incumbent on network operators how
to integrate the increasing number and
diversity of middleboxes into their networks.
A Northbound API could allow network
operators to integrate middleboxes with applications that
are also running in coordination with switches,
routers, and other devices in the network.
Currently, there is no standard for the Northbound API, but
in this module, we will look at various APIs and programming
languages that make it easier for network operators, researchers and others
to develop various application on top of Southbound APIs like OpenFlow.
Each of these Northbound APIs that we'll discuss compiles
to OpenFlow rules that are ultimately installed on the switch.
Ultimately, we're looking for good Northbound
APIs that enabled orchestration of high-level services.
In summary, OpenFlow is a Southbound
API technology that provides control over switches.
It makes it possible to program networks, but it doesn't make it easy.
A Northbound API can help.
It can allow network operators and programmers
to handle sophisticated events, to compose policies,
and to write policies that respond to
specific events that may happen in the network.
In the rest of the module, we will look at various programming languages and
applications built on top of OpenFlow controllers
that make these types of applications easier.