Through this (probably far too long) series on SDNs, we have looked at BGP, Fibbing, and Openflow. BGP and Fibbing would be described as augmented control planes; the distributed control plane is not replaced, but rather augmented with a controller that modifies the best path decisions of the control plane by interacting with the control itself in a somewhat “native” way.
The Blog Series
This is the fifth in a series of blogs on the topic of the evolving enterprise WAN that is based on a survey that was completed in May 2016 by 110 network professionals. The previous blogs were:
In 2012, an executive who worked for one of the largest European service providers shared his dream with the attendees of Layer123’s first software-defined networking (SDN) & OpenFlow World Congress in Darmstadt, Germany. According to him, the reason for all the misery in carrier-land were not permanent price battles, flat-rates, and cut-throat competition; it was us, the vendors.
Openflow is the “father of software defined networks” in the minds of many engineers. To understand Openflow, however, you cannot just look at the protocol itself; rather you must go back to the beginning, in the mists of old networking.
This is the fourth in a series of blogs on the topic of the evolving enterprise WAN that is based on a survey that was completed in May 2016 by 110 network professionals.
The SDN Controller concept was originally developed as the intelligent centralized point of network control and programmability in an SDN environment. However, the name was very quickly adopted by several vendors who claimed that their traditional NMS was a “controller” because it allowed network-wide management and point-and-click provisioning of their equipment. As a result, for many people the line between an NMS and a Controller is blurred, resulting in confusion across the industry.
The last post on the topic of SDNs discussed BGP as a southbound interface to control policy. This form of SDN was once common in hyperscale data centers (though not as common as it once was). In our pursuit of out of the way (and hence interestingly different) forms of SDNs (hopefully this series will help you understand the scope and meaning of the concept of SDNs by examining both common and uncommon cases), it’s time to look at another unusual form of policy injection—Fibbing. In fibbing, a centralized controller engineers traffic flow in a link state network by interacting with the control plane directly, rather than interacting with the forwarding plane or the RIB.
In the last post on SDNs, I spent a little time discussing just a bare minimum of some internal router architecture—specifically the difference between the RIB and the FIB, and thinking a little about management. In this post, I want to add one more dividing point to the mix, and then start thinking about how we can classify various “software defined” solutions in a way that makes more sense out of the field of options.
In my last blog post, I considered two questions: what does a control plane really do, and what does a forwarding device really look like? Before continuing to our final destination—a better understanding of what an SDN is, and what the fuss is all about—we need to back up to the first post in this series, and reexamine the question of centralization and decentralization.
Until recently, open source has had a relatively modest impact on networking. One of the many indications that open source is now having more of an impact on networking occurred at the 2016 Open Networking Summit in Santa Clara, CA. In past years, the focus on the ONS was SDN and NFV. While those were important topics at this year’s conference, the tag line for the conference was “A New Era of Open Source Networking”. The fact that this year’s ONS had such a strong focus on open source shouldn’t be surprising because in November 2015 the ONS became a Linux Foundation event.