The industry regards SDN as a simple but powerful concept that will reform data networking. But the idea behind SDN is not brand-new. Twenty-five years ago, telephone networks underwent a similar revolution called "intelligent networks" (IN).
IN separated service control from circuit switching and enabled fast provisioning of well known services such as call forwarding, call waiting, three-way calling, reverse charging and number portability. IN was at the top of its hype in the mid nineties and has been put to the test for decades.
SDN promises to do for data networking what IN did for telephony. What did we learn from IN? And how will this help us foresee what lies in store for SDN? Here are a few lessons we learned from SDN’s circuit-switched ancestor:
A few successful applications make the business
IN aimed to ease the creation of services for the telephony network. With IN came a promise of new business from hundreds of services that end-users could activate directly from their handsets.
Twenty-five years on we find that only a handful of compelling services made the business case for IN. The dream of countless new services never materialized. But services such as number portability and prepaid mobile secured the role of IN in telephony networks.
We’ll see something similar happening in SDN. A few big applications such as bandwidth self- provisioning, service chaining, load balancing and virtual firewalls will make the SDN business case. They are what service providers and vendors will capitalize on. All other things possible with SDN will have less significance.
Agility compels more than cost saving
IN enabled capital expenditure savings as service control logic runs on general purpose computing equipment. But IN offered more compelling benefits by cutting operating costs and bringing services faster to market.
Service providers now experience the same with SDN. Better network programmability, faster service provisioning and lower operational cost outweigh the savings in capital expenditure.
Who follows the standard?
Many consider SDN to be defined by the separation of the control and data plane and by the OpenFlow protocol between them. In a similar way, IN started from a conceptual model and a standard protocol called INAP.
As IN won momentum in the mid nineties, vendors each gave their own interpretation to IN and a wide range of products and solutions emerged. Most of them loosely followed the protocol specification but none of them fully complied with the standard. The European Telecommunications Standards Institute (ETSI) eventually standardized a reduced version of the protocol hoping that this would lower the bar for vendors to comply. Its success was limited.
SDN follows a similar path. Vendors define SDN to suit their product lines, which often include legacy equipment. Almost as many definitions of SDN exist as there are vendors. Certain vendors insist that OpenFlow is just one of the possible standard protocols between the data plane and control plane. Some will tell you that Open Daylight is the reference model for SDN controllers, others will point to the Open Network Operating System instead.
One important difference is the adoption of open source, which was not prominent in the days of IN. Open source initiatives can make a difference in SDN, as they did in operating systems. But take care not to confuse open source software with standardization. They are different things, with different benefits.
Programming the network remains hard
IN promised fast service creation by specifying coarse-grained, modular features to build services from. Even non experts in networks and programming could create new services from predefined building blocks. We’re hearing similar promises for SDN. Service providers expect to automate configuration tasks that could previously be done only by experts. End-users will self-provision services that previously required operator assistance.
But IN taught us the there is no such thing as a free lunch in service creation. Even simple IN services need careful planning, design and testing by experts, and involve hundreds of software components to catch all human machine interaction dialogs, exceptions and error handling. SDN users be warned. Network control needs planning, design and testing no matter how you well disguise it behind nice user interfaces.
IN brought with it a new problem too: unintended and unwanted interactions between services. This has not yet surfaced as a big issue in SDN, but as the number of SDN deployments and applications grows, so will the number of incidents due to unexpected interactions between network applications. The SDN community argues that orchestration takes care of this, but IN has also taught us that orchestration is notoriously hard. Orchestration is not a magic wand, it requires complex algorithms and often relies on heuristics to schedule services in the way intended.
The importance of APIs
APIs are where the destinies of SDN and IN diverge. APIs never caught on in telephony. The Parlay Group specified its first network APIs in 1998 which were standardized by 3GPP a few years later. Many network operators did pilots with APIs, a few use APIs internally to support service development, but hardly any (if any at all) commercially offer network APIs to third parties. The culprit is not immature technology but the gap between the telecommunications and information technology. Up until the first decade of the twenty-first century, programmers worked with APIs, telecommunications engineers with protocols.
Things will be different for SDN because - in spite of “N” for “networking”- SDN comes from information technology. APIs have been part of the SDN mindset since the early days. And APIs go hand in hand with the open source approach widely followed in SDN. APIs will play a defining role in SDN and its standardization.
Key Learning Areas
SDN can learn much from a twenty-five year old technology called IN. The history of IN gives important clues as to where SDN is heading:
Are you an expert on SDN and NFV in your organization? We'd like to hear your opinion on the status and the future of SDN. Click here to take the survey
Understanding and Capitalizing Upon Telecom APIs for Communications Enabled Applications
Single User License: $495
Provides analysis of the Telecom API ecosystem, market, and opportunities for carriers, infrastructure providers and app/service developers.
A must read for anyone involved in architecture strategy, application development, network planning, operations, and anyone with a vested interest in the future of service delivery, virtualization, and cloud-based market opportunities.
Connected vehicle technology is rapidly evolving to encompass Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Device (V2D), and Vehicle-to-Pedestrian (V2P) signaling and communications. This research examines the V2V and V2X market including technologies, solutions, and major players.
The report evaluates market opportunities and challenges for IoT Device Management solutions across various industry verticals. The report includes forecasting for global and regional markets as well as potential across deployment types and sectors including automotive, manufacturing, smart cities, and more.
Analysis of the DAS market, including carrier WiFi, small cells, and SON, and the leading companies in the DAS ecosystem and their solutions. The report also includes evaluation of market drivers, challenges, and provides forecasts for 2016 to 2021.
Comprehensive coverage of NGN OSS/BSS including opportunities within Big Data and IoT, analysis of the drivers and issues related to the technical and business aspects of OSS/BSS, deployments and operations issues, and quantitative analysis with forecasts for anticipated growth through 2021.