What is SDN?
By definition, SDN is an approach to networking in which network logic is decoupled from hardware and given to a software application called a controller. In simpler terms SDN removes the network operating system from each individual device and moves it to a server. Switches are then given rules or “flows” by the controller which describe how to forward specific traffic across the network. This allows for more network speed, efficiency, and innovation.
Traditional network vs SDN network
Network efficiency and speed are improved with SDN in several ways…
- Network processing is handled by a much more able-bodied server
- Switches evaluate route packets at line speed since they only perform forwarding decisions
- Centralized network control
- Custom defined network behavior
- Virtualized and sliced networks
- Multi-vendor device interoperability
- The ability for pay for hardware alone, without the unnecessary added features
The need for innovation
Networks today are not evolving quickly enough to satisfy the growing needs of consumers. Networks are built using switches, routers, and other devices from various vendors that have become exceedingly complex because they implement protocols standardized by the IETF and use proprietary interfaces. Many network administrators need network features tailored for their needs, which is a request very difficult to fulfill using standardized protocols and proprietary features. SDN solves this problem by allowing network administrators to define a network behaviour that suits their needs.
Although SDN is in it’s early stages, research and development is already under way. One very popular and developer friendly controller is provided by the OpenFlow based startup, Big Switch Networks. Big Switch actively supports “Floodlight”, an entirely open source OpenFlow controller written in java and licensed under the Apache license. You can clone the project from Github and start programming your own custom network behaviour in a matter of minutes. Bringing an open source option to networking not only gives administrators choice, it gives anyone a platform to innovate with. On the other hand large companies like Google have already implemented their own private versions of OpenFlow in their own datacenters.
Marist, IBM, and OpenFlow
Here at the IBM/Marist Joint Study we are developing an OpenFlow testbed to evaluate the effectiveness of different OpenFlow devices and controllers. Our goal is to contribute our findings back to the community in hopes to progress the adaptiveness of OpenFlow in modern networks.
So where does the Mainframe come into play?
As an intern at the IBM/Marist Joint Study I have the privilege of working with other interns involved in various mainframe related projects. Consequently we share rack space in the same datacenter that holds our very own mainframe, used to support the research done by our fellow interns. After joking around about running an OpenFlow controller on the Z, we realized that we may have a very rare opportunity on our hands. After all, how many OpenFlow researchers have a z114 dedicated solely for research in the same datacenter as their own rack?
As a team we are now making steps towards researching the benefits of combining the two robust enterprise solutions. We imagine that the mainframe could be a favorable solution for a robust, scalable, and efficient enterprise software defined network. The mainframe would be able to handle a high volume of network processes, scale in the event of a network traffic spike, and maintain high availability, all while running as efficiently as possible.
We have already begun making steps towards evaluating the benefits of running OpenFlow controllers on the Z ensemble. We teamed up with our fellow intern Doug Rohde and started by configuring and running a tool called “CBench”, a controller benchmarking tool. We ran the tool on a zBX blade and managed to average a performance rating of nearly 3 million flows per second. Although there is no thoroughly documented research concerning the use of CBench with Floodlight, other researchers have been finding similar results on comparable systems.
Since our team’s primary goal is not really affiliated with the mainframe, we can only give the concept so much attention. For this reason progress is slow, but we have some more ideas that we think will yield valuable results. At this point our next step is to test and benchmark the controller on zLinux. The rest of our high level ideas will be presented next week in detail by my partner, Ryan Flaherty.
Jason Parraga
B.S. Computer Science, Marist College (In Progress)
Jason is currently a Junior doing OpenFlow research for the IBM/Marist College Joint Study. As an OpenFlow researcher Jason is a hybrid student with a passion for Computer Science as well as Information Technology. This allows him to apply his knowledge of networking concepts by programming modules and functions for open source OpenFlow controllers such as Floodlight.
Connect with Jason on LinkedIn