The topic which I have come across in recent meetings across a wide spectrum of industry representatives is “Software Defined Networks” or SDN. Across Service Providers, Equipment Vendors, Software Vendors and System Integrators, and from East Asia to California, the most happening stuff seems to be SDN.
The more I hear about it the more I get a sense of Déjà Vu! Taking me back to the nighties and the promise held out by Intelligent Networks to the then PSTN world… There could be a lesson or two that can be applied to SDN based on the IN experience.
Intelligent Network – a recap
Right from the beginning, telephone exchanges have supported a stateful operation. Every phone call put through manual and automatic exchanges involved signalling from end-stations (commonly known as telephones) to an intelligence that could look up and take decisions on what should be done.
The signalling was partially electrical and partially human speech and the intelligence was entirely human in manual exchanges. In electromechanical exchanges, speech was substituted by tones for the purposes of signalling and intelligence was substituted by a set of relays and/or hard wiring. This evolved, in the all-digital era to signalling with messages as per established protocol and lookup tables for decision making.
However, the significant points in the call when the intelligence was required to “act” continued to be roughly the same, as shown in figure below.
Someone had a bright idea of creating a trigger point at the points in call to consult an external logic – which can be anything ranging from frequently manipulated lookup tables to extensive logic – and then deciding on how to handle the call further, thus, giving birth to Intelligent Networks.
IN had defined interfaces between the exchange (switch & router) and external logic through SS7 based messaging protocols. The platform running the external logic has been improved further by industry initiatives for providing APIs and SDKs through which new applications could be quickly developed.
Software Defined Networks
The Internet, on the other hand, belongs to the digital era, born with lookup tables and protocols. Routing and switching decisions are taken in a software functionality. Typically, layer2 and layer3 functions take a decision about the next node to direct a packet and base it on one or more of the following parameters at the most basic level:
- Port numbers
- VLAN Identifiers
- Ethernet Identifiers
- IP Addresses
- Protocol type
SDN, thus, is a principle like IN that deals with the flow of packets through nodes of a packet switched data network. A major difference is the speed of switching required in data networks – something that has forced the lookup tables to remain on the switch, while a protocol called OpenFlow has been defined through which an external controller could manipulate the table in realtime.
While the initial versions will support the set of simple identifiers listed above, it is expected that complex nodes will evolve, which will have additional capability to rewrite portions of packets, manipulate QoS for packets and have the ability to “act” based on information carried in the packets, besides the above simple headers.
Learnings From IN
So, what would I warn the SDN world about based on my experience with IN?
- There will be resistance from major vendors to open up their network nodes to external intelligence. They may find the thought of reducing their switches & routers to dumb responders unacceptable, especially after years of polishing their products and adding new features.
- Initially, whatever is being considered as an application to be developed in the external logic, the big vendors will try to offer those as in-built features and at unbeatable prices. Operators should refuse such offers and press for standard implementations in their own long term interests.
- There would also be variants from standards that would be built by vendors, ostensibly under the guise of giving a “little more” than what their competition provides. This could lead to a lock-in with the vendor and should be avoided at all cost. Such vendors should be asked to demonstrate their commitment to standards process by proposing their “little more” for future editions of the standards.
- In order to ensure that there are no non-competitive practices & barriers, an open-source community should be created for the controller. Since the vendors may not support such an initiative without a vested interest, it will be good if operators fund and support the open-source movement.
- Last but not, as the cliché goes, the least – Despite the rich set of possibilities, IN did not succeed in bringing more than three major applications – prepaid, number portability and toll-free services. Tablet environments have enabled a far greater number of apps by creating a robust developer ecosystem, an approach that I would strongly recommend for SDN too.