Hello! Welcome to part two in this series of blog posts dedicated to researching the use of software-defined networks (SDN) in video streaming services.

Last time, I talked about how a streaming service works and how traditional networking devices were limiting their potential in the age of high definition content. I then proposed that using software-defined networks could be a plausible solution to power up online multimedia streaming and enable it to satisfy the demands of modern Internet applications.

In this entry, I'll explain how SDNs came to be, what they are, what they aim to achieve, how they work and the benefits they bring to the data center.

The rise of SDNs: a brief examination

The emergence of software-defined networks happened as a direct response to the past and future of computer networks, as well as the technology that drives them.

It is often said that wars are the catalyst for many of mankind's biggest technological achievements, first used in the relentless pursuit of victory in and outside of the battlefield, then reintroduced into society as boons that signal the beginnings of new chapters in the history of humanity. And, of course, the Internet is no exception.

In warfare, communication technologies evolved, spurred by exigencies, leading to the creation of new methods and the refinement of existing ones. Early computers, initially for military use, laid the foundation for modern computing. Existing technologies like the telegraph were improved for wartime communication, with techniques such as frequency hopping and multiplexing enhancing speed and security.

These wartime innovations not only transformed communication but also influenced the development of computer science and networks. Engineers and scientists behind these technologies later shaped the field. Network devices were designed for reliability and durability, with each device capable of vital network functions. If one device failed, others could seamlessly take its place, ensuring network continuity.

The pioneers of these inventions likely couldn't have foreseen the internet's evolution into an indispensable aspect of daily life, where it now supports complex, data-intensive applications like streaming and cloud computing. Consequently, their original designs didn't anticipate such scenarios. Moreover, these designs haven't been fundamentally altered but rather adapted to meet the expanding requirements of modern internet applications.

Today, our daily lives are profoundly impacted by the internet, with an increasing number of services and activities transitioning to the digital realm through phone and web apps. This digital transformation has placed unprecedented demands on network and computing technology. For example, video streaming services operate at an enormous scale, handling data-heavy workloads that can increase exponentially in a matter of milliseconds.

As a result, traditional networking devices and technology have been outpaced by the services they aim to support. In recent years, efforts have been made to address this gap with solutions tailored to emerging networking needs, leading to the development of software-defined networks.

But, what exactly are software-defined networks?

Software-defined networks can be defined as a modern network paradigm that aims to achieve concern separation between the data, management and control layers.

In traditional network devices, each of these three layers are in charge of performing a variety of tasks necessary for the data exchange process. In short:

• The data plane is responsible for handling the actual transmission of data packets through the network by processes incoming packets, determining their next-hop destination, and forwarding them accordingly based on predetermined forwarding rules or forwarding tables.
• The control plane is responsible for network management functions such as routing, signaling, and resource allocation. It processes control messages exchanged between network devices to establish and maintain the network's operational state.
• The management plane is responsible for the configuration, monitoring, and maintenance of network devices and services. It provides interfaces and protocols for administrators to configure network devices, collect performance metrics, and troubleshoot network issues.

As we mentioned before, current network devices are built to operate under a high level of independence from one another, which means that every devices is able to perform these functions. But this autonomy comes at a cost.

In their book Software Defined Networks: A comprehensive approach, Göransson, et al. note that today's networking devices face the burden of managing complex control plane software, which increases hardware costs and places strain on processing power and storage capacity. Furthermore, the control plane of switches is inundated with control protocol traffic, with a significant portion of router capacity dedicated to tracking network topology.

Additionally, the complexity of autonomous networking devices has grown due to the need for extensive intelligence within each device, resulting in higher hardware component costs.

We could think of each one of these network devices as a one man band, managing multiple tasks simultaneously. Like network devices, a one-man band musician must skillfully coordinate various instruments and musical elements during a performance. Both scenarios require exceptional multitasking abilities and deep domain knowledge to execute tasks efficiently.

So then, how do software-defined networks aim to solve this?

These new types of networks posit that the solution to these problems is transferring the control capabilities of these devices to a central entity known as the controller. If our old network devices are a one-man band, SDN's are an orchestra.

The controller is like the conductor of an orchestra, and the network devices are the musicians. In an orchestra, the conductor provides sheet music to each musician and directs their performances during the show. Both parties share a common language for giving and receiving commands, which are the movements the conductor makes with the baton. The same applies to software-defined networking: the controller provides the information that devices need to deliver data to its destination and instructs them precisely how to do so through commands they both understand.

This controller has a complete view of the network and its activity and can use that information to make decisions about the network behavior, as well as the individual orders for each to device to accomplish it. In turn, network devices receive these specific instructions regarding their behavior and operations, which are tailored to optimize network performance based on real-time analysis of network activity and conditions.

And how do they work?

Now that I have described the basic gist of SDNs, I consider it is important to dissect their components and functionalities. To begin, a typical SDN looks like this:

All relevant activity to the functionality of an SDN happens mainly inside the controller and the SDN devices. Let's start by talking about the former.

The controller

The SDN controller is at the heart of the entire network operation. It is a piece of software executed on a high-performance computer responsible for issuing commands to every device to optimize packet flow between internal and external network devices. The controller maintains a complete view of the entire network, monitoring and gathering information about the state of the devices and any events occurring within the network. This information is then used to generate commands for the devices.

The controller is able to perform its designated tasks thanks to two very important elements of its design: the northbound and southbound APIs. These could be viewed as a bridge to carry information to and from the two other essential components of an SDN: the SDN applications and the SDN devices.

The northbound API is used to establish communication between the controller and the SDN applications. These apps are programs that provide much of the controller's essential functions, like constant network activity and device tracking, package flow managing, and more. SDN apps are characterized by their modularity and language-agnostic nature. This means that they can be written in any language since they interact with the controller through an API. They can also extend the functionality of the controller by operating under the concept of 'plug-and-play,' seamlessly integrating into the controller's app suite.

Conversely, the southbound API enables data exchange between the controller and the SDN devices. Using this API, the controller can send instructions to any device in the network, as well as receive relevant information from them. Occasionally, devices might send packets to the controller for further processing. The API provides an abstraction of the device's capabilities to the controller and vice versa, facilitating communication regardless of any particularities of either party."

Having these two APIs work together allows the SDN applications to define flows and manage them, as well as process any packets forwarded to it by the controller. When talking about SDNs, a flow can be defined as a sequence of packets of the same type that are processed by either the devices or the controller using a predefined set of rules. With these rules, flows can be manipulated as to optimize performance in the network.

When putting it all together, the controller provides information about the network topology and devices to the SDN applications, which use that information to make decisions and issue commands to the network devices.

SDN devices

SDN devices are inherently different from traditional network devices due to the decentralized nature of SDNs. An SDN device consists of two essential parts: an API for communicating with the controller, known as the southbound API, and a data structure called the flow table. This structure allows the device to assess incoming packets and respond to them with an appropriate, predefined action based on their type. Additionally, the controller can receive packets from an SDN device for further processing or evaluation.

As I have already explained the concept of a southbound API, let's now focus our attention on flow tables.

Flow tables

Flow tables are the essential to the operation of an SDN device.

Upon receiving a packet, the device consults the table. This table contains a certain number of entries for each packet type with two columns of information for each: match fields and actions. These entries are ordered by priority and contain information about each field of the incoming packet. The information in the match field is used to recognize the packet type. When a match is made with an entry, the action field is examined to determine what the device should do with the packet.

Like traditional network devices, SDN devices can be implemented using either software or hardware. Both implementations have advantages and disadvantages: a software-based implementationwill have fewer issues when interacting with different vendor devices at the cost of performance. On the other hand, a hardware-based SDN device offers better performance by leveraging hardware acceleration for processing, but special considerations must be taken to establish interoperability between devices.

How are SDNs changing the modern data center?

As I mentioned in my summary of the origin of SDNs, this technology was created in response to the myriad problems that afflict modern Internet services and applications. As these services and applications grow in complexity, so do the requirements of data centers or content delivery networks to adequately support their backend infrastructure.

In such intricate networks, the need for a tool that allows simplified, centralized, and highly programmable control and monitoring is evident. SDNs not only fulfill these requirements, but it is thanks to these features that they are able to help solve some of the most common problems faced by data centers today.

For example, multitenancy is increasingly demanded by data center users, serving various purposes such as efficient resource utilization, scalability, cost reduction, security, and flexibility. This approach allows multiple tenants to share infrastructure, optimizing resource usage, scaling resources based on demand, achieving cost savings, enhancing security through isolation, and providing customization flexibility. SDNs offer solutions to facilitate multitenancy implementation in existing data center networks by creating virtual networks atop conventional structures. By integrating SDN elements like a controller, seamless monitoring and control capabilities are provided, simplifying maintenance, management, and client space separation.

Another feature that many clients seek in a data center is failure recovery. In computer networks, it is crtical for maintaining uninterrupted operation, particularly in modern data center networks. As data center infrastructures become more complex and scalable, the likelihood of failures rises, underscoring the need for robust recovery mechanisms. These mechanisms entail redundancy, automated failover processes, and swift rerouting of traffic to healthy network paths. SDNs are particularly adept at aiding failure recovery due to their centralized monitoring capabilities and programmable network behavior. They facilitate rapid detection and mitigation of network failures by instructing devices on emergency recovery protocols.

Additionally, the inherent capabilities of SDNs empower them to address various network challenges effectively. Tasks such as network resource management, traffic engineering, and routing efficiency can be seamlessly managed by SDNs. With their centralized control and programmable nature, SDNs offer dynamic resource allocation, intelligent traffic routing, and optimization of network paths, thereby enhancing overall network performance and efficiency.

---

Now that we've covered the basics of software-defined networks, the next and final entry in this series will focus on detailing the research and testing phase of my project. I'll outline the specific objectives of this project, the methods employed to obtain results, and the interpretations drawn from them.

Stay tuned and thanks for reading!

References

Goransson, P., Culver, T., & Black, C. (2016). Software defined networks: A Comprehensive Approach. Morgan Kaufmann Publishers.

Kurose, J. F., & Ross, K. W. (2021). Computer networking: A Top-down Approach.

Azodolmolky, S. (2013). Software Defined Networking with OpenFlow. Packt Pub Limited.