In Part 2 of this series we will look at how Software Defined Networking works and the components that are involved. If you haven't read Part 1 yet I suggest you read that first to get some background on why SDN is so important.
At the most basic level an Ethernet Switch consists of two main components, the switching hardware and some software, or firmware as it is often called. When a packet arrives at one of the ports the hardware asks the firmware what it should do with the packet. The firmware then looks up the destination address on a list (called a MAC table) which contains all the devices that are currently connected to the switch and then tells the hardware which port to send the packet out from. Obviously this is a greatly simplified explanation of what a Ethernet Switch does but from a SDN stand point this is all we really care about. Now the problem was that the way this process works was set in stone, it did what it did and not much else. It was really up to the manufacturer to decide which features they wanted to include in the firmware because they were the only ones who had access to the code. That's when the idea of an extensible switch was considered by a group of researchers at Stanford University. They proposed the concept of separating the brains of the switch (software), called the Control Plane from the switching hardware, or Data Plane. By placing this Control Plane onto a totally seperate server instead of inside the actual switch you can now modify that software to add additional functionality. This new Control Plane software became what is now known as a SDN Controller and the additional functionality is implemented as SDN application that "plug" into the controller.
To make this separation possible a new communication protocol was required which would allow the switch to talk to the SDN Controller, the first and most widely used of those protocols is called OpenFlow. Originally developed as part of the Stanford SDN research it is now maintained by the the Open Networking Foundation (ONF) and is currently supported by dozens of the hardware and software vendors. The digram below from the ONF website shows the separation between the different layers of an SDN deployment.
Ok, enough talk let's go and build our own SDN as see how it really works. In Part 3 I'm going to show you how to build a Software Defined Network using one of the many free, open source SDN Controllers and our very own Zodiac FX OpenFlow Switch.
Comments will be approved before showing up.