• United States

Mind the Agility Gap

Sep 16, 20144 mins

mind the gap
Credit: Courtesy of Shutterstock

If you have ever spent time in London, you’ve probably heard or seen the ubiquitous instruction to “mind the gap” when exiting the tube or train. First introduced in 1969, this utilitarian safety warning urges passengers to take caution and be aware of the large distance between the train and the platform.

As technologists, we now have to “mind the gap” that is beginning to appear on the Internet as content and cloud providers move more data around. Single transactions for individual users can easily consume a significant amount of network resources. What users want and what the network, originally designed to handle just voice traffic and, more recently basic Internet access, can deliver is a challenge. Frankly, today’s networks — built with a mix of legacy hardware and software advancements — are not designed to provide what today’s application-centric user needs in real time.

So, how do we mind the gap? Software-Defined Network (SDN) technologies can provide that bridge.

With new intelligent, software-driven networks, we are able to move away from relying on physical resources alone to meet user requirements, moving to a model that allows networks to deliver service and capacity as needed, “on-demand.”

For example, cloud providers and streaming video service providers are trying to stay ahead of the curve, creating new applications and over-the-top services, which in turn are creating unpredictable traffic patterns. Cloud providers may have strict Service Level Agreements that essentially offer an “always on” level of connectivity and service, and globalization of these cloud based providers, such as Google, Azure, Dropbox, Salesforce, and Workday, means that there is a shift from predictable peak usage hours to unpredictability spikes that can happen anytime.

Infrastructure needs to support sudden, unpredictable traffic spikes, and subscribers want and expect on-demand connectivity and services, and they don’t want to have to worry about how it happens. It’s a fair request, and one that would make the online and networked world, in theory, a smoother place to operate. But, as we know, the networks of today just aren’t suited for it.

Yes, there are protocol-based networks available now that use a specific set of rules and recipes to determine how and where data and services are delivered. However, it can take weeks to months for an individual customer service to be connected or modified to meet a new applications needs. In some instances, it can take over a year for a new service framework to be created and deployed. This will not satisfy today’s “on-demand” expectations. The ability to deliver or modify an existing service on the fly – and the network being able to deliver it – is still a long way off for many a network operator.

To mind this “agility gap,” equipment vendors and service providers need to make the network more dynamic, open, and programmable to enable all of the potential applications their customers utilize on a minute-by-minute basis.

Openness leverages the principles of software-defined networking to free the network from the constraints of protocol-based operations and to put the intelligence and agility of software (and the power of modern IT) in the driver’s seat. It makes the network more adaptable, programmable, and flexible – key requirements in today’s “always on” world.

A truly open network means creating a network platform that is programmable through open interfaces. It means using a control engine that is software-based. And it also means using network application software that leverages real-time data analytics.

How will this change the way services are delivered? With programmability, operators can enable a virtual testing ground for new service types, which can be designed and deployed far quicker than in a fixed-protocol, static network. Changes are much easier to deploy when changes can be made with the click of a mouse, rather than digging up a street.

“Demand” can be better served by the “supply” when those selling connectivity and capacity on networks can easily and readily adapt to changes in user demands for connectivity and capacity, on the fly. But it’s only when we open the network that we can unlock the means to bridge the gap between what users want and what we can give them.

With this blog, I hope to highlight milestones in the transformation of the network from providing basic connectivity to an open and programmable platform that allows providers to deliver the new, game-changing enterprise and consumer applications. Watch this space!


With more than 20 years of telecom experience, Mr. Alexander is currently serving as Ciena’s Senior Vice President and Chief Technology Officer. Mr. Alexander has held a number of positions since joining the Company in 1994, including General Manager of Ciena's Transport & Switching and Data Networking business units, Vice President of Transport Products and Director of Lightwave Systems.

From 1982 until joining Ciena, Mr. Alexander was employed at MIT Lincoln Laboratory, where he last held the position of Assistant Leader of the Optical Communications Technology Group. Mr. Alexander is an IEEE Fellow and was the recipient of the IEEE Communications Society Industrial Innovation Award in 2012. He is currently an Associate Editor for the IEEE / OSA Journal of Optical Communications and Networking. He has served as a member of the Federal Communications Commission Technological Advisory Council, as an Associate Editor for the Journal of Lightwave Technology, as a member of the IEEE / LEOS Board of Governors, and was a General Chair of the conference on Optical Fiber Communication (OFC) in 1997.

Mr. Alexander received both his B.S. and M.S. degrees in electrical engineering from the Georgia Institute of Technology. He has been granted 18 patents and has authored a text on Optical Communication Receiver Design as well as numerous conference and journal articles.

The opinions expressed in this blog are those of Steve Alexander and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.