Explore Software Defined Networking Fundamentals today by downloading the free sample. Download Now
Join us in this three-part weekly blog series to get a sneak peek at The Linux Foundation’s Software Defined Networking Fundamentals (LFS265) self-paced, online course.
Part 2 of this series discussed the architecture of a traditional data switch and the inherent limitations created when striving for the highest performance of wire speed switching. This inflexibility and resultant vendor lock-in spawned Software Defined Networking (SDN)
According to Wikipedia,
“Software Defined Networking (SDN) is an approach to computer networking that allows network administrators to manage network services through abstraction of higher-level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane).”
As we saw in the previous article, the TCAM (Ternary Content Addressable Memory) in a traditional networking switch is the cornerstone of the Data Plane’s operation.
The foundations of SDN lie in the following question: What if we could access or program these remotely? We will discuss the consequences and effects next.
Changes to Networking Components
Software Defined Networking introduces new components to traditional networking infrastructure, as well as adapts the functionality of the existing components to the software defined architecture. The most important changes are:
• The physical or virtual switch (generalized as network device) does not have to implement all the protocols or features. Instead, it provides access to the data plane through a standardized API (e.g. OpenFlow). The software defined switch needs less internal logic thereby reducing complexities and costs.
• The concept of the SDN controller is new. It represents the control plane logic to the connected switches, calculates the forwarding state and populates the tables. It will be discussed below.
• The applications that reside on top of the Services API provided by the controller are also new. It abstracts the differences in the switch hardware from the network applications (e.g. firewall, QoS, NaaS). Thus application programmers can program “the network” and they do not need to know the details and unique management interfaces of each and every switch in the network.
The SDN Switch
The fundamental difference between a traditional switch and an SDN switch is the separation of the switch (data plane) and the controller (Control Plane). Once separated the control function doesn’t need to be co-located with the switching function. Additionally, a single remote controller can manage/control multiple switches throughout the network. Once the controller is managing switches across the network these controller can glean more information about the state of the entire network and not just the state of switches or nodes of the network. This additional information can be used in a number of ways such as dynamically modifying flows. For example, if part of the network is highly congested the controller can re-program the forwarding tables to re-route sensitive traffic around the congested links and switches.
As illustrated in Figure 1, there is a split between the switch and the controller:
• The switch hardware will have a minimal abstraction layer, with some control and management functionality. This is needed for cold-start operation and configuration.
• The decisions are now made in the control plane, which is part of the controller. The controller offers a central management plane as well.
The SDN Controller and APIs
A key part of all of this is the Application Programming Interface (API). APIs enable people and different layers of the network to communication with underlying components using a common and simplified approach. Applications do not need to know the details of the underlying hardware, they only need to know how to talk to a switch using this common language, the API. You do not need to know the vendor specific details as long as the vendor has implemented the API. Thus, high layer functions can “program the network” and not individual hardware devices. This network-wide programmability is a fundamental of SDN.
SDN introduces a new component, the SDN Controller (Figure 2). The SDN Controller is connected to the switches and represents the control plane logic. It’s responsible for calculating the forwarding rules and populates the switch’s tables.
When the controller is separated from the individual switch, a single controller is able to manage multiple SDN-capable devices.
This capability has some important consequences:
• A controller can aggregate more data regarding the state of the network.
• More knowledge about the state of the network leads to improved decisions.
• The flows can be dynamically adapted by the controller.
Network Transformation
SDN will transform the network away from specialized hardware with protocols and applications implemented for each Switch/Router hardware/software combination (Figure 3). Instead, the functionality is implemented at a higher level, using the controllers’ APIs independent of the underlying hardware. Instead of programming individual devices, we can now program the network. This is referred to as the separation of the Data Plane from the Control Plane.
The Internet Research Task Force (IRTF) RFC 7426 standard was released in January 2015 and it introduced a number of SDN fundamental concepts in the form of “abstraction layers”. The first is that of the Network Services Abstraction Layer (NSAL). This layer “sits” between the higher level applications and network services and the SDN Controllers. It is the API for these controllers. It also introduced other abstraction layers including the Control Abstraction Layer (CAL), the Management Abstraction Layer (MAL) and the Device and resource Abstraction Layer (DAL). Each of these layers or APIs provide the higher layers with a common way to communicate their requirements to the layer or layers below them.
The terms “Northbound” and “Southbound” emanated from the way networks were illustrated. The hardware was typically shown on the bottom of the whiteboard or Powerpoint slide and the applications, services and management systems were shown at the top. In the middle is the network control logic. Thus, above, northbound, from the controller are the services and applications and below, southbound, are the actual network elements. Traditionally these interfaces were tightly coupled to the proprietary hardware-centric network elements resulting is the inflexibility previously discussed. The APIs between the control and applications (northbound) and between the control and hardware (southbound) create a common “language” to communicate and thereby eliminates the need for programmers to learn vendor-specific management interfaces. Today, any function or interface shown above a specific function is northbound and those below are southbound. Most functions have both northbound and southbound interfaces and data traffic flows East and West.
The northbound SDN layer architecture (Figure 4) includes:
-
The Network Services Abstraction Layer (NSAL), which represents the application API of the controller.
-
Network Services are provided by the controller (the control and management planes) as Service Interfaces.
The southbound SDN architecture (Figure 5) includes:
• The Control Abstraction Layer (CAL).
• The Management Abstraction Layer (MAL).
• The Device and resource Abstraction Layer (DAL).
This three-part series provides the history of how we got to where we are today and illustrates the fundamental difference with SDN: the separation of the control plane from the data plane. Once separated, network operators have new degrees of freedom in the design and management of large scale IP networks.
The incorporation of application programming interfaces (API) into SDN is shown to greatly simplify the operation of these networks. Network engineers and other professionals can both glean network-wide state and make network-wide programming changes without the need to understand the minute details of the features and functionalities above them (Northbound) or below them (Southbound). Lastly, IETF RFC 7426 (Figure 6) was introduced showing the creation of a number of “abstraction layers” which standardize the locations of the APIs. Each of these abstraction layers hides the complexity of logic on either side further simplifying the deployment and operation of large scale IP network.
After this course, you should understand the historical drivers that spawned SDN. It then introduced the concept of “planes” and illustrated the primary technical differences traditional hardware-centric switches with new software-centric switches, namely the separation of the control plane from the data plane. Once separated, network operators will benefit from flexibility and visibility. The control plane in SDN now has increased visibility to the entire network and not just each individual network devices. Then RFC 7426 was discussed highlighting a number of abstraction layers created to simplify the underlying complexities and to accelerate innovation in software defined networks.
The “Software Defined Networking Fundamentals” training course from The Linux Foundation is designed to provide system and network administrators and engineers with the skills necessary to maintain an SDN deployment in a virtual networking environment. Download the sample chapter today!
Read the previous articles in the series:
Software Defined Networking Fundamentals Part 1: Intro to Networking Planes
Software Defined Networking Fundamentals Part 2: Switches and Network Architecture
