CYB 301 System Defined Network
CYB 301 System Defined Network
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
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 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:
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:
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.
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.
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.
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.
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:
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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
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:
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
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:
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.