Software Defined Networking – Introduction

Software Defined Networking means many things to many people, but there are three principle schools of thought that can be distilled from all the commentary: the Purists, the Architects and the Establishment.  Each has distinct goals, which may or may not solve the needs of particular markets. These groups each have a distinct vision of how each of the fundamental technology building blocks develop over time and how this impacts the various telecom markets.  Of course reality is never quite so neat and clean.  In practice the many participants in the SDN discussion exhibit trends from more than one each of these schools of thought.  Distilling the argument into the fundamentals helps one understand the motivations and end goals of they principle antagonists.

The Purists are arguably the originators of the SDN movement, with ONRC founded by faculty from Stanford and later Berkley.  Initially the premise was to define an environment which enabled researchers the flexibility to experiment with novel networking approaches on “real” hardware.  The Architects realized that this flexibility could be exploited for commercial means and could ultimately enable them to chart their own course unconstrained by the roadmaps of the dominant market players.  Reading between the lines, one can see that the Architects became the driving force that actually brought SDN technologies to the pinnacle of hype and adoption within the industry.  Finally we have the Establishment, representing the mainstream market players, who reluctantly adopted some of the SDN messaging.  Fundamentally, the Establishment seeks to preserve revenue and profitability while bringing sustaining innovation to the operation of the network.  In future posts I will explore each of these camps in detail.

It is generally accepted that there are three major technological domains within SDN, each dependent on the one “below” it and interconnected through well-known API’s.  The switching hardware (including both wired and wireless; LAN and WAN implementations),  the SDN controllers and the IT-administrator-facing applications.  In practice, several additional important dimensions need to be considered, including the embedded software running on the switching hardware (of various types), the scalability and distributed nature of the controllers (as well as exactly what roles the controller fulfills), and the orchestration framework which enables the delivery of the administrator-facing applications.  Finally, much has been made of the API’s which facilitate the interaction of these domains, both the “southbound” (switch to controller) and “northbound” (controller to application framework) interfaces.  These concepts will be expanded on in future posts.