Article originally posted on Linux.com, see original post here:
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.
Virtualization, which includes Software Defined Networking (SDN) and Network Function Virtualization (NFV) is changing the entire networking ecosystem. Virtualization is an innovation wave that cannot be ignored. The value proposition is too compelling for anyone operating a network (Enterprises and Service Providers) to ignore. All participants in this ecosystem must adapt, or they’ll be left behind.
This tutorial series, taken from the second session of the course, will provide the fundamental concepts of an SDN switch. This first part covers a short history of networking and the driving forces of innovation behind SDN. It also introduces the concept of planes and gives an overview of the three planes of networking.
The second part shows the architecture and operations of a traditional switch and how the planes are implemented therein. Then part three illustrates the architectural differences of a software defined switch and introduces the concept of an SDN Controller. It then covers RFC 7426 and how it introduced a number of abstraction layers to simplify the programming of complex networks.
Get all three parts and test questions by downloading a free sample chapter from the course today!
A Short History of Networking
The networks that drive today’s world, and the information technology industry in particular, are built on the concepts introduced by ALOHA and the U.S. Defense Advanced Research Project Agency (DARPA) initiative called ARPANET (Advanced Research Projects Agency Network).
What we now refer to as the “Internet” is the evolution of Arpanet. Created in the early 1960s, Arpanet was a packet-based network, as opposed to the widespread circuit switched Public Switched Telephone Network (PSTN). The resilience, we now assume, was created to ensure survivability of a nuclear attack. If a node (in this macabre case, a city) was removed from the network, the remaining nodes would adapt and route around the missing node.
In the 1980s, the Internet Protocol Suite (TCP/IP) was introduced, and the U.S. National Science Foundation funded numerous supercomputing centers at select universities and then funded connectivity to these sites to other research institutions. It was the advent of the web browser by Tim Berners-Lee of CERN that gave us a simple interface to the Internet and its resources and became the World Wide Web that’s become integrated in our lives.
The techniques and methods used in packet networking, as well as the hardware and the software, evolved over time. However, the actual network building blocks are the same, and we enhance them on top of the existing infrastructure.
With the advent of virtual machines (VMs) and virtualized data centers, the landscape changed in the compute domain. Despite that, the networks have been slower to adapt. Networks are geographically large systems with dozens of purpose-built hardware devices connected with miles of fiber optic cables. For an enterprise the network is critical infrastructure, and for service providers the network is their business. Upgrading these mission-critical systems while they are in use is wrought with challenges. Additionally, these purpose-built hardware devices are not only proprietary vendor-specific implementations, they are also rigid and inflexible. Thus, network operators are at the mercy of each vendor’s upgrade cycle and roadmaps. This is often referred to as “vendor lock-in.” To make it more challenging, services are often tightly coupled to hardware devices. If you want to add a new network service, you need to qualify, test, and then integrate a new hardware device to your installed base. As an illustration of this point, AT&T has noted that their average central office has more than 300 unique hardware devices. This alone is an operational nightmare.
As the web skyrocketed, the number of Internet Service Providers (ISPs) did too, creating a large market for companies that made switches and routers. Based on the technology at the time and subsequent technical and market forces, these hardware-centric systems grew in physical size, performance, power consumption, and price.
To achieve the levels of performance required, vendors were often forced to create custom application-specific integrated circuits (ASICS). These complexities led to numerous vendor-specific (proprietary) implementations and management systems. As a result, the services that ran on the network were tightly coupled to the specific pieces of hardware. If a service provider, or enterprise, wanted to add a new service (e.g., VPNs, residential firewalls, etc.), this became a multi-year effort requiring both new hardware and new expensive integration efforts.
At the same time, aggressive cash-rich and nimble web or cloud companies (e.g., Google, Amazon, et al.) were introducing new services seemingly weekly. They accomplished this using Commercial Off-The-Shelf (COTS) hardware and open source software. In networking, the inflexibility, growing costs and services-hardware lock-in ignited the global innovation engine. Research projects led to the paradigm of a programmable network infrastructure, which we now know under the name of Software Defined Networking (SDN). Some of the research projects which led to SDN were:
SDN will transform the network away from specialized hardware with protocols and applications implemented for each switch/router hardware/software combination. 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.
Intro to Networking Planes
On a whiteboard, networks may be drawn as a cloud or a number of straight lines between nodes. In reality, there are three dimensions, called “planes,” of a network: the Data Plane, the Control Plane, and the Management Plane. It is important to understand these planes and how each of them is treated in a software-defined network.
• Data Plane
The data plane is responsible for handling the data packets and applying actions to them, based on rules that we program into lookup tables. The actions must happen at line speed, therefore we must be fast enough (e.g., 40Gbit/sec per port). Also called the data path or the forwarding plane, the data plane takes packets in one port of a switch and sends them out another port.
Knowing what port to send them out requires input from the control plane. Once configured, packets come and go at “wire speed” (e.g., 10Gbps). So the switch has .0000000001 second (at 10Gbps) to figure out which port to forward the packet to. If it can’t match the packet to a pre-programmed rule, it sends the packet to the control plane.
• Control Plane
The control plane is tasked with calculating and programming actions for the data plane. This is where the forwarding decisions are made and where other functions (e.g., Quality of Service, Virtual Local Area Networks, etc.) are implemented. The control plane is operating at a lower speed than the data plane. It does not operate — or need to operate — at wire speed.
• Management Plane
The management plane is where we can configure and monitor the network device (e.g., switch or router). The network device can be a shell, command-line interface (CLI) or web interface. The management plane usually runs on the same processor as the control plane.
In part 2 of this series, we’ll explain the architecture and operations of a traditional switch and how these planes are implemented in this environment.
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!
