What can SDN learn from a twenty-five year old Standard?

What did we learn from IN? And how will this help us foresee what lies in store for SDN?

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:

  • A few applications with big success will make the business case for SDN. They will account for most of the SDN deployments.
  • In the long run, network agility and time-to-market will drive SDN adoption more than cost savings.  It’s been said by many analysts, and IN confirms the prophecy.
  • Standardizing SDN will be a long and bumpy road as vendor and service provider interests diverge.  Vendors will give their own interpretations to the standards.  Open source will make a difference, but should not be confused with standardization.
  • Orchestration less straightforward than vendors will admit, and not always fully automatable.  It implies complex analysis and scheduling of features to ensure that they interact in the ways intended.
  • APIs never made it to fame in IN, but they will be a vital component of SDN. SDN has its roots in information technology, unlike IN, which came from the telecommunications world. As a result SDN will draw much more than IN upon APIs, open source and state-of-the-art programming techniques.

What will be the main challenges for SDN in the coming years?

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

Featured Report

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.


Featured Events 

Communications 2020
July 18 - 20, 2017
Las Vegas, NV


M2M Zone Pavilion @ MWC Americas 2017
September 12-14, 2017
San Francisco, Calif.