A couple of questions I typically hear are, “What is SDN?” and “How does OpenFlow work”. To begin down the path of SDN enlightenment, it really helps to think about networking and “traffic” forwarding from a completely different perspective. I believe that most of us have been working with traditional Ethernet networks for a very long time and typically our views are etched into our minds based on this past experience. To answer these questions, it really helps to shift gears a bit and examine a basic network that can be built with OpenFlow. Please note the following examples are very basic and are not intended to showcase an actual solution, but rather highlight how OpenFlow works.
For the first example, let’s consider some very basis requirements – a research organization needs to map physical Ethernet ports to one another. For example, port 1 is mapped to port 3. All network traffic entering port 1 is forwarded out of port 3.
A simple web front end provides the user the ability to easily see existing mappings and add new mappings.
The second example simply builds on the first by adding in the concept of “global knowledge” or multi-device control. The same research organization needs to map physical Ethernet ports to one another. For example, port 5 on switch 1 is mapped to port 20 on switch 2. All network traffic that enters port 5 on switch 1 is forwarded out of port 20 on switch 2.
For the example assume the application has been "hard coded" with inter switch link information. This could easily be determined by the application with a routine that sends LLDP packets to be forwarded out all ports of all switches connected to the controller. A corresponding match all LLPD packets with an action to send to the controller would give the application enough information to determine the topology.
Let’s look how SDN in this example differs from classical Ethernet:
Network behavior is determined by software application
no network protocol (i.e. MPLS etc)
SDN application is a single instance
Traditional networking would require applications (control plane) on each switch
User would configure each switch OR allow a protocol to communicate between the applications running on each switch
Start thinking how this type of architecture solves traditional networking problems more efficiently. Also notice how abstraction of the control plane could potentially provide greater flexibility AND simplicity when compared to traditional networking protocols. Up next - an emulated network (mininet) that demonstrates implementation of the examples highlighted above.