Although SDN proponents are most known for advocating separate Control (C) and Data (D) planes as an abstraction layer, and some have referred to it as a revolutionary, novel paradigm, this bifurcation concept actually goes back to 1975, with the development of SS7 by the original AT&T, which resulted in distinct signaling and transmission networks. This common control mechanism itself turned out to be a great success in due course because it did not upset the offshoots of the legacy Bell System, neither technically/operationally, nor culturally. In contrast, ISDN was a big failure, even though a CCITT recommendation in 1988, exactly discussed the notion of such C and D planes, because it did require a major transition for these carriers, such as in moving away from voice, as well as the heavy amount of resistance at the operators in converging that service with data. Actually, Verizon, for example, did not even become truly data-centric, especially from a sales perspective, until it merged with MCI in early 2006. Following ISDN were IN/AIN (Advanced Intelligent Network), and even initial work on a next-gen concept, called Intelligent Network Architecture (INA), all of which never really got off the ground. Afterwards, there were a number of other ideas to take advantage of software intelligence remotely, including soft switches (which, once again, divided control and transport functions) and IMS (which emerged from those switching devices), but the notion of replacing gear, such as a cross-connect, would have been sufficiently scary in a lot of cases, let alone a CO (not to mention having to share the cutting-edge capability in many situations with other service providers). The list of the decoupling methods of the two planes over the decades is lengthy, encompassing solutions developed by individual suppliers or by standards bodies. Moreover, there was quite a bit of ambitious work on novel, advanced interfaces for network management purposes, such as CMIP, which itself failed to take hold meaningfully in the public network space. The market is bound to come up with another, supposedly surefire, universal, distributed-computing, software concept, like SDN, which will also join the timeline parade, but will also likely fall way short of the initial goals of its supporters.
SDN has certainly been an important enabler for cloud-based services, and it took off in the large enterprise space because it was driven by hyperscale users, like Google, which originally had simple, flat, greenfield types of networks, along with deep pockets, allowing for tremendous flexibility for adoption. However, in public networks generally, one or more of the following five factors, resulted in a lack of promised success for the bulk of the solutions mentioned or inferred above: 1) antiquated, unadaptable, legacy OSSs; 2) large system vendors protecting their product lines; 3) resistance to movement in unfamiliar directions; 4) government-enforced unbundling; and 5) inherent conflicts between existing technologies and/or service groups within users. For instance, on this last point, an important barrier for SDN has been the inherent tension between the transport side, which has depended on a big EMS to control the network, and the router-centric portion, which has a very distributed setup.
Re-examining AIN is particularly instructive, because it was a similar type of effort to SDN in order to commoditize the network gear with general-purpose software, trying to eliminate the hook from the main equipment vendors. Despite the effort of the former lasting for about 10 years, the overwhelming tendency is to totally ignore its past consideration at trade shows in any discussions of SDN, unless we are moderating the panel. Of course, if ATM had become dominant (a GSMP provided for plane partition), with frame relay (also, included C/D plane separation) neatly interfacing into those switches, and with the possibility of SS7 also integrating with them, perhaps there would have eventually been a place for next-gen AIN.
Somewhat paradoxically, even the term, “Software Defined Network” goes back to the 1980s, as AT&T offered a private line, virtual service to various enterprises under that rubric. Concerning modern SDN, with the increasing amount of customer-specificity on solving practical, straight-forward problems, which was inevitable, given that the conventional marketplace has always been about incremental, evolutionary improvements rather than revolutionary alterations, an overriding response to an entire operations quagmire, was never in the cards. Therefore, the exact meaning of SDN is progressively becoming more nebulous – albeit, still useful for marketing purposes.
Despite having a state-of-the-art network, Verizon has heavily focused initially on the fundamental benefits of using an effective analytics tool, so that it can have an accurate database, which is not surprising, given that the ancient TIRKS inventory system had a tendency to be as much as 50% inaccurate on the status of circuits, as well as on migration of its TDM circuits (even older), potentially with orchestration software, which “Tellabs” (owned by Infinera) started developing at least seven years ago. Putting its grand rhetoric aside, Telefónica really appears to just be targeting a “small gap,” which requires a “workaround.” For all of its hype when it comes to its ability to adapt to leading-edge technology, in relationship to VNFs, AT&T has farmed out much, if not all of the management, to NCR.
SDN has also steadily become a moving target for the hyperscalers, most conspicuously, Microsoft, which makes it extremely clear that the company has its own internal, rather secretive version, no doubt made more challenging with a network that has been around for quite a while. In addition, Google is mostly finding open-source SDN controllers and some of the other architectures truly difficult to embrace in adjusting to the scale as well as to its deployment and operational models, which it desires in many cases, and so, the company ends up using its relatively big development teams to build the stacks out.
As it relates to the traditional ISPs, Ciena’s experience has demonstrated the most optimistic scenario, with the exception of the very small percentage of greenfield opportunities for access suppliers, involving anything resembling “SDN.” There will be more controllable hardware, gradually happening over a long period of time. Furthermore, there will be distinct software opportunities for automation and other apps.
As always, fibeReality does not recommend any securities, and this writer does not invest in any companies being analyzed by us.
To follow us on our totally separate, quick update company blog, which is exclusively on fibeReality’s LinkedIn page, please click here.
[written by Mark Lutkowitz]
SHARE THIS