Despite the fact that the Software-Defined Networking (SDN) concept has been around for quite a while now–developed by Stanford around 2005–the hype is just growing. We strongly felt this when we attended the–HPSR2013 conference–where many research papers and 2 out of 3 tutorials discussed about SDN. Other highlights of the conference are presented in another post.
We would not say that SDN is the new ATM, which some might say was too over engineered to just work in practice. However, as with any new technology searching for its final course there were many promises which have to prove their usefulness and practicality. Here our takeaways for SDN:
What is Software-Defined Networking? Quoting the Open Networking Foundation: “Software-Defined Networking (SDN) is an emerging architecture that is dynamic, manageable, cost-effective, and adaptable, making it ideal for the high-bandwidth, dynamic nature of today’s applications”. That is promising a lot and is what every networking engineer wants to hear. But is it really true? Well, the first steps were already made once with the appearance of OpenFlow, which is a foundational element for SDN. OpenFlow is a standard which basically allows any network operator to have an extended control over its networking equipment, in an abstracted manner. The word extended here is key: it promises an unheard level of tuning of the networking infrastructure which becomes able to achieve the highest performance. The abstractization is also very important as it allows the network operator to use any networking hardware from any vendor, without having to know the specifics of that hardware. Acquiring an OpenFlow-enabled equipment means that no new hardware-specific details need to be learned by an operator in order to integrate the new equipment with the existing infrastructure.
How does OpenFlow work? OpenFlow is a master-slave protocol. The master is the Controller which connects to all the network switches available in the operator’s infrastructure. Through this connection, commands can be dynamically issued to control various networking aspects such as changing or adding routing entries based on pattern matching*, or retrieving advanced network statistics. The slaves are “dumb” network switches that obey the Controller in every aspect, unless the connectivity is lost, in which case the switch reverts to the old plain routing table solution.
What are the other benefits of OpenFlow?
- Moving the intelligence: A plain switch decides what to do with a packet based on its routing table, and this decision is agnostic of the full scale of the network topology. Traditionally, scalability concerns have dictated this mode of operation to minimize the routing traffic overhead. Instead of letting every switch decide what to do with a packet, the OpenFlow Controller takes control over deciding upon routing, based on a global view of the network. This is a great advantage over plain routing, as this is a direct solution for load balancing, policing, QoS provisioning, or re-routing in case of failure of collateral routing elements.
- Centralization: the network operator has the control of all switches in one place, allowing a better perspective of the network. Centralized control has always been a well seated belief in the operator’s mind – probably one reason why SDN is receiving some liking from operators and network equipment providers, alike. Any centralization solution raises scalability issues. In our opinion, OpenFlow scales pretty well; thousands of switches can be managed by a single OpenFlow Controller, assuming the Controller runs on a powerful server. More details about scalability figures here.
- Programmable: the logic of the routing can be programmed into the Controller using various popular programming languages, like C/C++, python, ruby, etc. This gives agility to the logic to perform more complex tasks than plain routing tables. Again, this raises the specter of intelligent networks, an example an epic failure of a wonderful (in academics eyes) networking concept.
- Flows: OpenFlow works at the flow level rather than a packet level granularity. This helps when trying to move a stream of packets belonging to the same application on another route, for example to make “space” for a more important flow. Logically the flow concept is more appropriate to use when thinking of network routing. Typically humans think about the network traffic in “flows”. However the higher complexity of implementing flow management discouraged its adoption back in the days when networking equipment had bad performance/price ratio. Only recently the ratio allowed the flow-based concept to thrive.
Who is using OpenFlow? It may be enough to say that Google has adopted the SDN/OpenFlow solution to interconnect their data centres, but the list is longer: Cisco, Ericsson, HP, NEC and many other have joined the hype. To anyone interested in the routing topic, SDN/OpenFlow seems to be the future of routing.
How can be OpenFlow used in CarMesh? OpenFlow’s capabilities can be directly leveraged in the CarMesh project with regards to deploying a mesh infrastructure able to deliver various automotive applications that need access to external digital services. How is that? Well, the routing could be managed much more easily by programming various solutions to tackle different scenarios and use cases that might face the Carmesh system:
- Hand-over due to high mobility: thanks to the centralized architecture of OpenFlow, the handling of breaking-and-making of new connections can be done much more quickly with the aid of the bird’s eye view, delivering a seamless connection to the end-user. However, since the controller has to be permanently in touch with the switches, this can not be done in-band with the other traffic, as the control messages themselves could face congestion and packet loss. As such, the obvious solution is to equip every mesh router with a dedicated interface able to cover a very large area at low transfer speed. Hence, the communication with the Controller is done out-of-band and is guaranteed not to suffer from congestion caused by other traffic or other network issues such as signal interference. The drawback of this solution is the cost of the extra interface, but that cost has gone down a lot nowadays.
- Prioritize sensitive traffic: in the event of QoS-sensitive traffic being transported over the CarMesh network–such as VoIP–the corresponding packet flow can be prioritized and the other traffic can be “shoved” away on alternative paths to leave the shortest path free of congestion.
- Load balancing: the OpenFlow controller would be aware of the over-utilized and under-utilized resources in the network. As such, some flows can be re-routed on alternative but longer paths, resulting in better QoS outcomes.
- Location Based Services (LBS): the Controller has the bird’s eye view over the network and this enables various mechanisms to be programmed/coded in order to deliver the content only at specific geographical locations.
The takeaway message of this post is the following: OpenFlow is a very powerful framework which helps tackle many of the problems caused by the legacy, old, plain routing-table solution.
Note: *best student paper award at HPSR 2013 – Rasmussen, A., Kragelund, A., Berger, M., Wessing, H., & Ruepp, S. (2013). TCAM-based High Speed Longest Prefix Matching with Fast Incremental Table Updates. In IEEE Conference on High Performance Switching and Routing (pp. 43–48).