Fabric: a retrospective on evolving SDN

Reviewer: John S. Edwards

The story of software-defined networking (SDN) is truly epic. Many of the premises supporting SDN go back to the late 1980s and the collection of telephone operating companies of that time. They were captive to a small number of equipment vendors who had created the digital revolution and were engaged in a "feature war" with each other. After the divestiture of the Bell System in the US and the eventual spinoff of Bell Labs into a separate company, the remaining major US telephone operators, under the influence of Bellcore, mandated vendor-neutral hardware (and its attendant software feature set). The operators claimed they wanted a dual supply chain, but wanted transparency across platforms. They also insisted they could deliver new services much more effectively themselves if they had a more aggressive hand in system design features. Thus, the SDN was born. One instance of the SDN was embodied in the so-called next-generation network (NGN). Unfortunately, none of the telephone savants (except for a few on the fringe) anticipated the eclipse of the classic telephone network by the Internet. As the Internet architecture (an oxymoron of the highest order!) evolved, the telephone folks, both operators and vendors, strove to rescue their interests from the Internet folks. The tension between these camps (exacerbated by the academic community) led to two decades of standards debates and obfuscation among the parties. (A Web search for "software defined networks" yields 6,430,000 results. Go figure!) The goal of all this debate is simplicity itself: create a network fabric and user interface where the requirements of both the user and operator communities are met without either community being much aware of the other. This paper is a sincere attempt to make sense of the current state of affairs. Several relatively simple concepts are introduced and described lucidly. Some bias is alluded to at the outset. The authors assert that "it is widely agreed that current networks are too expensive, too complicated to manage, too prone to vendor-lockin, and too hard to change." If true, then a simple solution must be very difficult and very expensive, not to mention having to account for the effects of transition strategies and timing. The authors go on to say that "an ideal network design would involve hardware that is: Simple: The hardware should be inexpensive to build and operate. Vendor-neutral: Users should be able to easily switch between hardware vendors without forklift upgrades. Future-proof: The hardware should, as much as possible, accommodate future innovation, so users need not upgrade their hardware unnecessarily." Nirvana indeed. As it is, the demise of several large vendors has already shown the results of these three axioms. Taken together, they remove the vendor value added and eliminate profit margins. Nevertheless, the near- to medium-term goals of the operators may be met by studying the insights developed herein. (Someday, there may only be one or two such operators, because there would be no differentiation among the surviving players.) One last point: the authors suggest that "network requirements come from two sources: hosts and operators." The actual customers have always been taken for granted by the vendor and operator community. This probably goes back to the folks at the old Bell System in the US and the government post offices in Europe. One could wish the actual needs of the customer could be given equal status. (For example, if there is no differentiation among the operators, how can the customer choose a service__ __) Online Computing Reviews Service