0% found this document useful (0 votes)
68 views

CYB 301 System Defined Network

S.D.N

Uploaded by

destinyotulugbu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
68 views

CYB 301 System Defined Network

S.D.N

Uploaded by

destinyotulugbu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 21

CYB 301

Software Defined Networks


INTRODUCTION

Traditional Networking

Networking has always been very traditional. We have specific network devices like routers,
switches, and firewalls that are used for specific tasks. These network devices are sold by
networking vendors like Cisco and often use proprietary hardware. Most of these devices are
primarily configured through the CLI, although there are some GUI products like CCP (Cisco
Configuration Protocol) for the routers or ASDM for the Cisco ASA firewalls. A network device,
for example, a router has different functions that it has to perform. Think for a moment about
some of the things that a router has to do in order to forward an IP packet:

 It has to check the destination IP address in the routing table in order to figure out where to
forward the IP packet to.

 Routing protocols like OSPF, EIGRP or BGP are required to learn networks that are installed
in the routing table.

 It has to use ARP to figure out the destination MAC address of the next hop or destination and
change the destination MAC address in the Ethernet frame.

 The TTL (Time to Live) in the IP packet has to be decreased by 1 and the IP header checksum
has to be recalculated.

 The Ethernet frame checksum has to be recalculated. All these different tasks are separated by
different planes. There are three planes:

 control plane

 data plane

 management plane

Let‘s take a look at the difference between these three planes…

Control Plane

The control plane is responsible for exchanging routing information, building the ARP table, etc.
Here are some tasks that are performed by the control plane.
 Learning MAC addresses to build a switch MAC address table.

 Running STP to create a loop-free topology.

 Building ARP tables.

 Running routing protocols like OSPF, EIGRP, and BGP and building the routing table.

Data Plane

The data plane is responsible for forwarding traffic. It relies on the information that the control
plane supplies. Here are some tasks that the data plane takes care of:

 Encapsulate and de-encapsulate packets.

 Adding or removing headers like the 802.1Q header.

 Matching MAC addresses for forwarding.

 Matching IP destinations in the routing table.

 Change source and destination addresses when using NAT.

 Dropping traffic because of access-lists.

The tasks of the data plane have to be performed as fast as possible which is why the forwarding
of traffic is performed by specialized hardware like ASICs and TCAM tables.

Management Plane

The management plane is used for access and management of our network devices. For example,
accessing our device through telnet, SSH or the console port. When discussing SDN, the control
and data plane are the most important to keep in mind. Here‘s an illustration of the control and
data plane to help you visualize the different planes as shown in figure 1.1
Above you can see the control plane where we use routing protocols like OSPF and EIGRP and
some static routing. The best routes are installed in the routing table. Another table that the router
has to build is the ARP table. Information from the routing and ARP table is then used to build
the forwarding table. When the router receives an IP packet, it will be able to forward it quickly
since the forwarding table has already been built

Let‘s consider some of the things we have to configure on our network to make this happen:

 The VLANs have to be created on all switches.

 We have to configure a root bridge for the new VLANs.

 We have to assign four new subnets, one for each VLAN.

 We need to create new sub-interfaces with IP addresses on the switches.

 We need to configure VRRP or HSRP on the switches for the new VLANs.

 We have to configure the firewalls to permit access to the new applications / subnets.

 We have to advertise the new subnets in a routing protocol on our switches, routers, and
firewalls.

Although there are network automation tools to help us, we often use the CLI to configure all of
these devices, one-by-one. It‘s a slow, manual process that a human has to do. While it only
takes a few minutes to spin up a new virtual machine, it might take a few hours for the network
team to prepare the network. Changes like these are also typically done during a maintenance
window, not during business hours.

Server virtualization is one of the reasons why businesses are looking for something that speeds
up the process described above. Before virtualization, we used to have one physical server with a
single operating system. Nowadays we have multiple physical servers with hundreds of virtual
machines.

These virtual machines are able to move automatically from one physical server to another.
When they cross an L3 boundary, you don‘t want to wait for the network team to make the
required changes to routing or access-lists. It should be automatic.

The trend nowadays is that everything should be virtual. It‘s not strange to see that this is also
happening to networking. Large companies like Cisco that used to sell only proprietary hardware
are now also offering virtual routers, ASAs, wireless LAN controllers, etc. that you can run on
VMWare servers.
Network virtualization is the process of creating a virtual version of a network, which can be
used to test new configurations or simulate different network conditions. This can be useful for
troubleshooting or for training purposes.

SDN (Software Defined Networking)

A few years ago, every organization or vendor has a different opinion about what SDN exactly is
and different products that they offer. Traditional networking uses a distributed model for the
control plane. Protocols like ARP, STP, OSPF, EIGRP, BGP and other run separately on each
network device. These network devices communicate with each other but there is no central
device that has an overview or that controls the entire network. One exception here (for those
that are familiar with wireless networking) are the wireless LAN controllers (WLC). When you
configure a wireless network, you configure everything on the WLC which controls and
configures the access points. We don‘t have to configure each access point separately anymore,
it‘s all done by the WLC.

With SDN, we use a central controller for the control plane. Depending on the vendor‘s SDN
solution, this could mean that the SDN controller takes over the control plane 100% or that it
only has insight in the control plane of all network devices in the network. The SDN controller
could be a physical hardware device or a virtual machine.

What is software-defined networking?

Software-defined networking (SDN) is an architecture that abstracts different, distinguishable


layers of a network to make networks agile and flexible. It can also be defined as an innovative
approach to network management that separates the control plane from the data plane. It allows
network administrators to control and manage network resources through software, making the
network more agile, flexible, and responsive to changing business needs. Software-Defined
Networking (SDN) is a network architecture where network control is decoupled from
forwarding and is directly programmable. This means that the network infrastructure can be
easily controlled and configured to meet the needs of the applications that run on top of it. The
goal of SDN is to improve network control by enabling enterprises and service providers to
respond quickly to changing business requirements.

In a software-defined network, a network engineer or administrator can shape traffic from a


centralized control console without having to touch individual switches in the network. A
centralized SDN controller directs the switches to deliver network services wherever they're
needed, regardless of the specific connections between a server and devices.

This process is a move away from traditional network architecture, in which individual network
devices make traffic decisions based on their configured routing tables. SDN has played a role in
networking for a decade now and has influenced many innovations in networking.
Here‘s an illustration to help you visualize this:

Above you can see the SDN controller figure 1.2 which is responsible for the control plane. The
switches are now just ―dumb devices that only have a data plane, no control plane. The SDN
controller is responsible for feeding the data plane of these switches with information from its
control plane. There are several SDN controller platforms in use today. Some of the common
ones include OpenDaylight, ONOS (Open Network Operating System), and Ryu. These
platforms provide the foundation for SDN network control and management.

There are some advantages and disadvantages of having a distributed vs a central control plane.
One of the advantages of having a central controller is that we can configure the entire network
from a single device. This controller has full access and insight of everything that is happening in
our network. The SDN controller uses two special interfaces as shown in Figure1.3, take a look
at the image below:

SDN orchestration is the process of automating network configuration, management, and service
provisioning. It simplifies network tasks, accelerates service delivery, and ensures efficient
resource allocation.
Summary

SDN is a relatively new paradigm of a programmable network which changes the way that
networks are designed and managed by introducing an abstraction that decouples the control
from the data plane, as illustrated in Figure 3.1. In this approach a software control program,
referred to as the controller, has an overview of the whole network and is responsible for the
decision making, while the hardware (routers, switches etc.) is simply responsible for forwarding
packets into their destination as per the controller’s instructions, typically a set of packet
handling rules.

SDN architecture

The interfaces are called the northbound interface (NBI) and southbound interface (SBI). Let me
explain both…

Southbound Interface

The SDN controller has to communicate with our network devices in order to program the data
plane. This is done through the southbound interface. This is not a physical interface but a
software interface, often an API (Application Programming Interface). An API is a software
interface that allows an application to give access to other applications by using pre-defined
functions and data structures.

Some popular southbound interfaces are:

 OpenFlow: this is probably the most popular SBI at the moment, it‘s an open source protocol
from the Open Networking Foundation. There are quite a few network devices and SDN
controllers that support OpenFlow. OpenFlow is a communications protocol that allows the SDN
controller to instruct switches on how to handle network traffic. It plays a crucial role in the SDN
architecture, as it facilitates the separation of control and data planes.

 Cisco OpFlex: this is Cisco‘s answer to OpenFlow. It‘s also an open source protocol which
has been submitted to the IETF for standardization.

 CLI: Cisco offers APIC-EM which is an SDN solution for the current generation of routers
and switches. It uses protocols that are available on current generation hardware like telnet, SSH,
and SNMP.

Northbound Interface

The northbound interface is used to access the SDN controller itself. This allows a network
administrator to access the SDN to configure it or to retrieve information from it. This could be
done through a GUI but it also offers an API which allows other applications access to the SDN
controller.

Here are some examples of services to be done by Northbound Interface:

 List information from all network devices in your network.

 Show the status of all physical interfaces in the network.

 Add a new VLAN on all your switches.

 Show the topology of your entire network.

 Automatically configure IP addresses, routing, and access-lists when a new virtual machine is
created.
Through the API, multiple applications are able to access the SDN controller as in figure 1.4.A
user that is using a GUI to retrieve information about the network from the SDN controller.
Behind the scenes, the GUI is using the API.

 Scripts that are written in Java or Python can use the API to retrieve information from the
SDN controller or configure the network.

 Other applications are able to access the SDN controller. Perhaps an application that
automatically configures the network once a new virtual machine is created on a VMware ESXi
server.

REST API

Let‘s take a closer look at what an API is. SDN controllers typically use a REST API
(Representational State Transfer).The REST API uses HTTP messages to send and receive
information between the SDN controller and another application. It uses the same HTTP
messages that you use when you browse a webpage on the Internet or when you enter a contact
form online:

 HTTP GET: used when we want to retrieve information.

 HTTP POST/PUT: used when we want to upload or update information.

It is similar browsing a webpage, only this time, you are not requesting a webpage or picture but
a particular object from the SDN controller, for example, a list with all VLANs in the network.
When the SDN controller receives the HTTP GET request in figure 1.5 it will reply with an
HTTP GET response in figure 1.6 with the information that was requested. This information is
delivered in a common data format. The two most used data formats are:
 JSON (JavaScript Object Notation)

 XML (eXtensible Markup Language)

Here‘s an example to help you visualize this:

Above we have a python script that is using HTTP GET to fetch the following URL through the
API:https://192.168.1.1:8443/sdn/v2.0/net/nodes. This URL will retrieve some of the variables
that are available, for example, information about all nodes (hosts) on the network. Once the API
receives this, it will respond with an HTTP GET response message:
Summary

A typical representation of SDN architecture comprises three layers: the application layer, the
control layer and the infrastructure layer. These layers communicate using northbound and
southbound application programming interfaces (APIs).

SDN architecture separates the network into three distinguishable layers, connected via
northbound and southbound APIs.

Application layer

The application layer contains the typical network applications or functions organizations use.
This can include intrusion detection systems, load balancing or firewalls. Where a traditional
network would use a specialized appliance, such as a firewall or load balancer, a software-
defined network replaces the appliance with an application that uses a controller to manage data
plane behavior.
Control layer

The control layer represents the centralized SDN controller software that acts as the brain of the
software-defined network. This controller resides on a server and manages policies and traffic
flows throughout the network.

Infrastructure layer

The infrastructure layer is made up of the physical switches in the network. These switches
forward the network traffic to their destinations.

APIs

These three layers communicate using respective northbound and southbound APIs. Applications
talk to the controller through its northbound interface. The controller and switches communicate
using southbound interfaces, such as OpenFlow, although other protocols exist.

There is currently no formal standard for the controller's northbound API to match OpenFlow as
a general southbound interface. It is likely the OpenDaylight controller's northbound API may
emerge as a de facto standard over time, given its broad vendor support.

SDN on security

SDN enhances network security through centralized control, allowing immediate threat response
and dynamic security policy enforcement. It also enables network segmentation, keeping
different parts of the network isolated from one another, reducing the attack surface.

How does SDN work?

SDN encompasses several types of technologies, including functional separation, network


virtualization and automation through programmability.

Originally, SDN technology focused solely on the separation of the network control plane from
the data plane. While the control plane makes decisions about how packets should flow through
the network, the data plane moves packets from place to place.

In a classic SDN scenario, a packet arrives at a network switch. Rules built into the switch's
proprietary firmware tell the switch where to forward the packet. These packet-handling rules are
sent to the switch from the centralized controller.

The switch -- also known as a data plane device -- queries the controller for guidance as needed
and provides the controller with information about the traffic it handles. The switch sends every
packet going to the same destination along the same path and treats all the packets the same way.

Software-defined networking uses an operation mode that is sometimes called adaptive or


dynamic, in which a switch issues a route request to a controller for a packet that does not have a
specific route. This process is separate from adaptive routing, which issues route requests
through routers and algorithms based on the network topology, not through a controller.

The virtualization aspect of SDN comes into play through a virtual overlay, which is a logically
separate network on top of the physical network. Users can implement end-to-end overlays to
abstract the underlying network and segment network traffic. This microsegmentation is
especially useful for service providers and operators with multi-tenant cloud environments and
cloud services, as they can provision a separate virtual network with specific policies for each
tenant. An overlay network is a network that is built on top of another network, typically a
physical network. An underlay network is the physical network that the overlay network is built
on top of.

What are the benefits of SDN?

SDN can come with a variety of benefits, such as the following.

Simplified policy changes

With SDN, an administrator can change any network switch's rules when necessary --
prioritizing, deprioritizing or even blocking specific types of packets with a granular level of
control and security. This capability is especially helpful in a cloud computing multi-tenant
architecture, as it enables the administrator to manage traffic loads in a flexible and efficient
manner. Essentially, this enables administrators to use less expensive commodity switches and
have more control over network traffic flows.

Network management and visibility

Other benefits of SDN are network management and end-to-end visibility. A network
administrator needs to deal with only one centralized controller to distribute policies to the
connected switches. This is opposed to configuring multiple individual devices. This capability is
also a security advantage because the controller can monitor traffic and deploy security policies.
If the controller deems traffic suspicious, for example, it can reroute or drop the packets.

Reduced hardware footprint and Opex

SDN also virtualizes hardware and services that were previously carried out by dedicated
hardware. This results in the touted benefits of a reduced hardware footprint and lower
operational costs.

Networking innovations

SDN also contributed to the emergence of software-defined wide area network (SD-WAN)
technology. SD-WAN employs the virtual overlay aspect of SDN technology. SD-WAN
abstracts an organization's connectivity links throughout its WAN, creating a virtual network that
can use whichever connection the controller deems fit to send traffic.
SDN help with network cost optimization

SDN can help optimize network costs by improving resource utilization, reducing the need for
expensive proprietary hardware, and enabling efficient traffic routing and load balancing. It
allows organizations to do more with less, ultimately reducing operational expenses.

What are the challenges of SDN?

Main adopters of SDN include service providers, network operators, telecoms, carriers and large
companies, such as Facebook and Google. However, there are still some challenges behind SDN.

Security

Security is both a benefit and a concern with SDN technology. The centralized SDN controller
presents a single point of failure and, if targeted by an attacker, can prove detrimental to the
network.

Unclear definition

Another challenge with SDN is the industry really has no established definition of software-
defined networking. Different vendors offer various approaches to SDN, ranging from hardware-
centric models and virtualization platforms to hyper-converged networking designs and
controllerless methods.

Market confusion

Some networking initiatives are often mistaken for SDN, including white box networking,
network disaggregation, network automation and programmable networking. While SDN can
benefit and work with these technologies and processes, it remains a separate technology.

Slow adoption and costs

SDN technology emerged with a lot of hype around 2011 when it was introduced alongside the
OpenFlow protocol. Since then, adoption has been relatively slow, especially among enterprises
that have smaller networks and fewer resources. Many enterprises cite the cost of SDN
deployment to be a deterring factor.

SDN Applications

The SDN technologies are applicable in a wide range of communication and networking scopes,
some of the key applications of SDN are: Wireless Communication, Data Centers and Cloud
Environments, Campus, and High-Speed Network. Software-Defined Wide Area Networking
(SD-WAN) is the application of the SDN concept in the WAN architectures. This technology
allows the organization to connect to sites over large distances and eliminates the disadvantages
of the traditional WAN technologies such as high cost and lack of Quality of Service (QoS).
There is wide variety of network environments where we encounter SDN applications. The
enabling of customized control with programmable networks, the simplification of development
and deployment of new network services and protocols make it a preferable choice that is
already used. Below view different environments in which Software Defined Networking is
implemented, summarized from:

• Enterprise Networks. In enterprises we usually encounter large networks, while security and
performance requirements are quite demanding. Of course requirements differ from one
enterprise to another according to the goals, characteristics, number of employees etc. As an
example, networks in Universities, can be challenging in terms of security, with many devices
connecting with these temporary connections not being controlled by the University, or the
resource allocation. Additionally, there is the need in these environments, to provide support for
research related projects, experiments and protocols. With SDN, the difficulty and complexity is
limited by the ability “to programmatically enforce and adjust policies”, or network performance,
or make it simple to monitor network activity. Some examples of SDN implementation include
“Network Address Translation (NAT), firewalls, load balancers, and Network Access Control
(NAC)”. In more complex implementations, SDN can be used for centralized management and
control.

Another issue in large networks aligns with consistent network updates. Instability in networks
roots mainly from configuration changes and may cause security flaws, outages and performance
disruptions. “With a set of high-level abstractions, network administrators are able to update the
entire network, guaranteeing that every packet traversing the network is processed by exactly one
consistent global network configuration. To support these abstractions, several OpenFlow-based
update mechanisms were developed”. Lastly, OpenFlow itself, was initially designed taking
issues found in enterprise networks into consideration.

• Data Centers. Data centers have evolved and continue to evolve rapidly continuously
attempting to meet higher and higher standards. The need for careful traffic management and
enforcement of policies escalates with the size of the infrastructures. Especially in businesses
where even just a small delay can lead to financial damage. Despite the challenges of large scale
networks, and the complexity which large scale brings, data centers have always been adapting
in higher demands and requirements. Therefore, they run well below capacity while being ready
to support higher workloads. An important issue in large scale data centers, is energy
consumption with its large scale cost. There has been research, that has been focused on
improving servers by better managing hardware or/and software, but still the amount of energy
consumed is great. The network, which with the help of SDN, tries to find a sub-network in the
network, that uses minimum power for real-time traffic conditions. Additionally, it turns off
switches that are not used at the time. Their results showed energy savings up to 62%. However,
there are high performance networks in which SDN solutions are not appropriate. There is a need
to balance the simplified traffic management and visibility coming from SDN technology, with
scalability and performance overhead. OpenFlow might be considered excessive, since it
combines central control and complete visibility, even when only “significant” flows need to be
managed. That may add delays, especially when switches are overwhelmed with flow table
entries. There are ways to manage that issue but still it might affect the controller on effectively
managing traffic and gathering statistics. There have been suggestions for design modifications
that try to keep flows in the data plane while maintaining visibility, which could, at some level,
balance these issues out.

• Optical Networks. Software-defined and OpenFlow networks, with the management of data
traffic as flows, are able to support multiple network technologies. Thus, they are able to provide
centralized control for optical networks. According to the ONF and the Optical Transport
Working Group (OTWG) that was created in 2013, SDN and the OpenFlow standard provides
benefits to optical transport networks, such as management flexibility, improvement of network
control, third-party integration, control systems, and new services.

• Home and Small Business. Home or small businesses networks are, maybe, the most widely
used networks and they have become highly complex as well. Low cost network devices allow
flexibility and spread of the network but at the same time require a more careful network
management and stricter security objectives. Networks that are not secured properly constitute
attack targets for malware, while any outages rooting from network configuration issues can
cause financial or other types of losses in small businesses. It is not practical or even feasible to
have a network administrator to each home or office. SDN technology enables visibility and
gives users a view of their network layout. It also offers a single point of control. Furthermore,
there is the option of assigning the network management to a third party, through remotely
programmable switches, distributed network monitoring algorithms, and conclusion exporting,
for the detection of possible security issues.

• Internet Exchange Points (IXP). IXP stations use BGP5 for routing between sectors, which has
certain limitations since it can forward traffic based on destination’s IP prefix only. SDN
deployment on IXP may provide liberation from these limitations, load balancing etc.

• Backbone Networks. An SDN architecture in backbone networks can provide high


programmability and availability. A notable example is Google. Generally, by following a
centralized management approach, there are beneficial results like better network utilization,
easier network testing etc.

SDN use cases

Some use cases for SDN include the following:

DevOps.SDN can facilitate DevOps by automating application updates and deployments. This
strategy can include automating IT infrastructure components as the DevOps apps and platforms
are deployed.
Campus networks. Campus networks can be difficult to manage, especially with the ongoing
need to unify Wi-Fi and Ethernet networks. SDN controllers can benefit campus networks by
offering centralized management and automation, improved security and application-level
quality of service across the network.

Service provider networks. SDN helps service providers simplify and automate the provisioning
of their networks for end-to-end network and service management and control.

Data center security. SDN supports more targeted protection and simplifies firewall
administration. Generally, enterprises depend on traditional perimeter firewalls to secure their
data centers. However, companies can create a distributed firewall system by adding virtual
firewalls to protect the virtual machines. This extra layer of firewall security helps prevent a
breach in one virtual machine from jumping to another. SDN centralized control and automation
also enables admins to view, modify and control network activity to reduce the risk of a breach.

The impact of SDN

Software-defined networking has had a major effect on the management of IT infrastructure and
network design. As SDN technology matures, it not only changes network infrastructure design
but also how IT views its role.

SDN architectures can make network control programmable, often using open protocols, such as
OpenFlow. Because of this, enterprises can apply aware software control at the edges of their
networks. This enables access to network switches and routers, rather than using the closed and
proprietary firmware generally used to configure, manage, secure and optimize network
resources.

While SDN deployments are found in every industry, the effect of the technology is strongest in
technology-related fields and financial services.

SDN is influencing the way telecommunications companies operate. For example, Verizon uses
SDN to combine all its existing service edge routers for Ethernet and IP-based services into one
platform. The goal is to simplify the edge architecture, enabling Verizon to enhance operational
efficiency and flexibility to support new functions and services.

SDN's success in the financial services sector hinges on connecting to large numbers of trading
participants, low latency and a highly secure network infrastructure to power financial markets
worldwide.

Nearly all the participants in the financial market depend on legacy networks that can be non-
predictive, hard to manage, slow to deliver and vulnerable to attacks. With SDN technology,
organizations in the financial services sector can build predictive networks to enable more
efficient and effective platforms for financial trading apps.
In cloud computing, SDN is instrumental in automating network provisioning, which is essential
for dynamic workloads and on-demand resource allocation. It ensures efficient resource
utilization and simplifies network management in cloud environments.

SDN revolutionizes network traffic engineering by providing real-time control over traffic flows.
This enables dynamic optimization and rerouting of traffic based on changing network
conditions, enhancing performance and efficiency.

SDN significantly impacts QoS by providing dynamic control over network traffic. It allows
real-time prioritization and traffic management to ensure that critical applications receive the
necessary resources and deliver a higher Quality of Service.

Network slicing in the context of SDN

Network slicing involves dividing a single physical network into multiple virtual networks, each
tailored to the unique needs of different applications or users. This enables efficient resource
allocation and customization of network services

SDN and SD-WAN

SD-WAN is a technology that distributes network traffic across WANs using SDN concepts to
automatically determine the most effective way to route traffic to and from branch offices and
data center sites. SDN and SD-WAN share similarities. For example, they both separate the
control plane and data plane, and they both support the implementation of additional virtual
network functions.

However, while SDN primarily focuses on the internal operations within a local area network,
SD-WAN focuses on connecting an organization's different geographical locations. This is done
by routing applications to the WAN. SD-WAN is a technology that leverages SDN principles to
manage and optimize wide-area networks. It simplifies the management of geographically
dispersed network locations, providing better control and agility in connecting remote sites to the
central network. Other differences between SDN and SD-WAN include the following:

Customers can program SDN, while the vendor programs SD-WAN.

SDN is enabled by network functions virtualization (NFV) within a closed system. SD-WAN, on
the other hand, offers application routing that runs virtually or on an SD-WAN appliance.

SD-WAN uses an app-based routing system on consumer-grade broadband internet. This enables
better quality performance and a lower cost per megabyte than Multiprotocol Label Switching
(MPLS), which is critical to SDN.

SDN and SD-WAN are two different technologies aimed at accomplishing different business
goals. Typically, small and midsize businesses use SDN in their centralized locations, while
larger companies that want to establish interconnection between their headquarters and off-
premises sites use SD-WAN.

SDN Controllers

We can treat SDN controllers as network operating systems. They form a software platform
which constitutes the base of all the network control applications. Usually, a set of modules form
an SDN controller, and provide different services like routing, security, policy management, and
more, in the direction of meeting the enterprises objectives.

We find a number of SDN controllers that were developed with different objectives in mind. The
most widespread ones are summarized below:

• NOX Controller: This controller was developed by Nicira Networks early on along with the
OpenFlow protocol. As one of the firsts, it is considered a safe and stable option, it is widely
used and is preferred in educational environments. There are two versions of this controller with
the first being the NOX-classic, implemented in C++ and Python supporting the network control
application by using both languages. Using two languages though led to inconsistencies
concerning features and interfaces. It might be due to these issues that this first version is no
longer supported, and instead we moved to the second version which is called simply NOX or
“new NOX”. This version was implemented in C++, supporting the network control application
also developed in C++. Even if considered harder, especially for users that are not familiar with
C++, “new NOX” supports both 1.0 and 1.3 versions of OpenFlow and has better performance
and programmability.

• POX Controller: For users that are not familiar with C++, POX is the Python version of the
NOX controller. With Python’s simplicity and flexibility, POX has been the top choice for SDN
projects, in things like debugging SDN applications or implementing network virtualization. The
POX controller is also supported by the official NOX community. On the downside, POX
supports only 1.0 version of OpenFlow protocol but still provides better performance compared
with the NOX-Classic. However, Python is not a compiling language, therefore it cannot be used
for low-level functionality down to the core of the OpenFlow Protocol, in contradiction with the
NOX.

• Ryu Framework: Ryu simplifies network management and applications control. It is based on
Python and supports a variety of protocols, such as NETCONF2, OF-config3, and OpenFlow, to
include version 1.0 and versions 1.2–1.4. Ryu is implemented using Python.

• Floodlight Controller: Except from C++ and Python, there are Java-based versions of
OpenFlow Controller, one of them being the Floodlight Controller. This is an open source option
with a great industry support, which comes from Big Switch Networks. Maybe the more
complex from the options above, due to a large set of features, it enables easy integration with
external business applications.
• OpenDaylight Controller: Another Java-based SDN controller, OpenDaylight was created as a
Linux Foundation collaborative project and it focuses on innovation in the SDN environment.
Besides the open source community, OpenDaylight project is supported by companies like
Cisco, IBM, Brocade and VMware. It supports both 1.0 and 1.3 OpenFlow versions, as well as
other protocols like OVSDB4 We can remotely configure most network devices using legacy
protocols, such as Simple Network Management Protocol (SNMP) and NETCONF. On the
drawbacks, OpenDaylight is complex because of its architecture and a big number of services
provided, making it having a steep learning curve.

Others

Trema

Trema is an OpenFlow controller framework written in Ruby that provides many solutions to
create a controller in the network. It provides a network emulator and libraries that can create
simple OpenFlow-based networks on a system. These features are an efficient way to provide
development and testing environments for networks. It allows developers to build custom
controllers by adding messaging scripts. Trema focuses on precise coding methods to reduce the
possibility of errors and for easier code maintenance.

Beacon

Beacon is a Java-Language based SDN Controller that supports Multi-threads and event
handling. It is modular, supports multiple platforms and is very fast. Its development began in
the early 2010s and had been used in several trials and projects. It is capable enough to run a data
centre and can run for months without any downtime. Beacon is Open Source and is currently
licensed under GPLv2 and FOSS Exception v1.0. Code packages can be installed even during
runtime without interrupting other packages. Beacon can optionally support custom UI
Frameworks and can embed webserver enterprises.
MuL

Mul is a C Language based SDN OpenFlow Controller. It supports a multi-threading


infrastructure and has a multi-leveled northbound interface for hosting various applications.
Currently, it aims to support southbound interfaces such as OpenFlow 1.3,1.4 and of-config
ovsdb, etc. It is designed with reliability and performance in mind which is essential for critical
networks. Mul is easy to learn and implement, making it highly flexible.

OpenFlow Protocol

Networking technology has developed and improved in a large scale through innovative
transformations and mechanisms, boosting speeds, increasing reliability and security of
networks. Network devices developed on the physical layer, providing high capacity
connections, improving computing power and various applications, offering tools for easy
inspection of functions. However, the network structure hasn’t seen so many changes from its
early days. In the existing structure, various network devices from different vendors executing
different software, or in fact “firmware,” are handling tasks that compound the network
functionality in its whole, like routing, packet transportation or network access decisions. This
doesn’t leave enough room for innovative research ideas, like new routing algorithms which can
be tested in large scale environments. Additionally, every effort for new experimental ideas for
constructing the network may result in network failure at certain points, a fact that has led to
static and non-flexible structure of the network and hasn’t been attracting important innovations
towards that direction.

The OF Protocol solves this problem by providing the ability to network administrators, of
practicing or applying various capabilities through the software. The OF specification can be
found at the ONF organization. The ONF’s administrative board consists of the following well
known companies: Google, Microsoft, Deutsche Telekom, Verizon, Yahoo and NTT. Also,
companies such as HP, IBM, and CISCO, provide hardware that uses OF.

Definition

As the protocol used in SDN, OpenFlow is the first standard that allowed interaction between the
data and control plane. The flow tables used in OpenFlow are analogous to the lookup tables
used by routers and switches in traditional networks. Through these flow tables, we can
implement firewalls or NAT or collect statistical data. Additionally, they provide action rules
which are created or modified from a centralized controller. The network administrator is able to
program flow control through the controller, and to determine specific route from the source to
the destination using the flow based on the packet forwarding processing. It decreases the power
consumption and the network management cost by eliminating the procedure of packets
processing of the router, since now packet routes are determined from the centralized controller.

OpenFlow Architecture
Three basic components form the OpenFlow network architecture:

1. OpenFlow switches that make the data plane.

2. OpenFlow controllers that make the control plane.

3. A secure control channel that connects the switches with the control plane.

The communication takes place between switches and hosts or switches and switches using the
data path, and between controller and switches using the control path. OpenFlow uses Secure
Sockets Layer (SSL) protocol to secure connections between the controller and the switch.
Mutual authentication between the controller and the switch is performed by exchanging
certificates signed by each side’s private key.

However, the controller may be subject to Denial of Service (DoS) and/or Man In the Middle
(MITM). Therefore, security practices implementation is necessary to prevent such attacks.

You might also like