History as a guide to SDN’s coming evolution
I developed Intelligent Network (IN) services and platforms during the early 1990s. With IN, Unix based controllers were connected to traditional telephone switches to perform both obscure as well as massively deployed phone services. Some of these services had very large centralized routing databases controlling the ultimate trunk/path selection of calls.
What is not widely remembered about IN is that it consisted of many types of independent control programs connected via an SS7 packet network to the data plane (i.e., legacy phone switches). Toll free calling, Calling Card, Local Number Portability and other services were all built this way. Some of these control programs maintained topology databases and allocated traffic across specific backbone links. None of these control programs needed to communicate with each other. Application independence was central to both end-user service reliability and the elimination of interactions and dependencies between application code. It is interesting to note that basic routing and forwarding remained in the phone switches for the vast majority of services.
Flash forward to SDN and 2012. One thing which is new for clean-slate SDN versus 1980s/1990s IN is that a full “global view of the network” is being proposed. But what value can a global view be leveraged to provide? There are many IN lessons from the PSTN which can be applied. History suggests very large continually updated central database-centric applications would be first to leverage this value (e.g., Mobility/HLR). Where will SDN run into some challenges? Anytime it is applied to deliver a function more efficiently provided between locally peering network elements (e.g., IP Fast ReRoute, LACP type load balancing across bundled physical links, or micro-flow steering across long haul networks where the speed of light comes into play). Frank’s blog entry provides more detail on the overall debate.
One other lesson from IN: don’t look for applications and even some types of controller based network abstractions to even be aware of each other. Eliminating such inter-dependencies speeds and simplifies deployments.
Since there is value in both centralized and distributed topology control, it is logical to conclude that hybrid control plane approaches to topology management will exist in the majority of network deployments.
Returning back to ~2003, general policy servers such from companies such as Tazz Networks were positioned as controllers for Wireline broadband aggregation. The majority of these policy server companies no longer exist or have morphed to serve mobile networks. Why? Vendors assumed there would be a need to handle subscriber access control along with control of ephemeral state (QoS, packet filtering, per flow accounting) for a subscriber session. It turned out there was no demand for controlling ephemeral state in the existing/stable wireline market. What turned out to be interesting were application specific controllers in emerging mobility markets. And this is where many controllers moved.
Flash forward to SDN and 2012. There will be opportunities for central applications and/or controllers. But look for them to grow from an initial use case, not as a roll-out of a revolutionary infrastructure for an existing market. Also, look for traction in market segments which are in flux or periods of high growth.
Summary: The idea that one generic controller will be able to control every forwarding decision on a plethora of network types is seductive, but in the end unlikely. The idea that many applications on many types of controllers can integrate and optimize local forwarding decisions is compelling and well grounded in history.Tags: