SDxCentral
Join Log In
SD-WAN 1 5G 11 Edge 5 IoT 12 SDN 3 NFV 4 Containers 4 Cloud 11 Security 3 AI 5 Data Center 1 Storage 3 APM/NPM 1 Open Source

Log In to SDxCentral

Log in with your email? Forgot your password?
  • Newsletters
  • eBriefs
  • Podcasts
  • Webinars
  • Videos
  • Directory
  • White Papers
  • Resources
  • Use Cases
  • Support

Join SDxCentral and get information tailored to your particular interests everyday.

Join
Sponsored:
Dell EMC 3 Citrix Riverbed

Carriers Wonder if SDN Will End Up Like ISDN

Tata Communications James Walker VP for Managed Services
Craig Matsumoto
Craig MatsumotoAugust 14, 2014
12:24 pm MT
Email LinkedIn Facebook Twitter Reddit Hacker News

Some carriers still don’t see how software-defined networking (SDN) will fit into their networks — at least, not in its current state.

You can’t blame them for their skepticism, because they’ve been burned before. ISDN and ATM were supposed to simplify network operations, too, and neither one panned out, as industry veterans explained during a recent discussion hosted by the Metro Ethernet Forum (MEF).

Related Articles

Turkcell Launches Largest Virtualized Mobile Network In the Middle East
Turkcell Launches Largest Virtualized Mobile Network In EMEA Region
6WIND Snares Another Former Brocade vRouter Customer
6WIND Snares Another Former Brocade vRouter Customer
Ethernity ENET vRouter Aimed at a Programmable Network Bottleneck
Ethernity ENET vRouter Aimed at a Programmable Network Bottleneck
Telefónica Validates Wind River’s Cloud Platform for its Unica Project
Telefónica Validates Wind River’s Cloud Platform for its Unica Project
ONAP Casablanca Shows Up in ‘All the Gin Joints’
ONAP Casablanca Shows Up in ‘All the Gin Joints’

Moreover, SDN and network functions virtualization (NFV) are likely to bring more complexity to the network at first, because of the management and orchestration required, executives said.

Carriers like the promise of SDN and NFV. It’s the business model that worries them. ISDN and ATM failed to take over the network because, in the end, they “didn’t pass the dollar test,” said Bob Mandeville, president of testing consultancy Iometrix.

Exactly how SDN can change the carrier business model is “very hard to see,” said James Walker, vice president of managed networked services at Tata Communications. (That’s him in the photo above, with Mandeville in the background.)

Carrier SDN lacks an urgent, specific use case to propel it — as opposed to data-center SDN, which is being prodded by the increase in east-west traffic and the need to flexibly network all these virtualized functions.

One use case commonly discussed is the ability to dial up bandwidth on demand, giving customers a boost during peak times. But Walker, in a brief discussion with me at the MEF event, picked that apart.

The No. 1 reason why people request variable bandwidth is to use it for backup connections, he claimed. In other words, they want Tata to keep this extra chunk of bandwidth available for the rare instance when a connection goes down. And when that does happen, it’s probably down for everybody in that area because something happened — meaning all those customers need their backup bandwidth all at once. Keeping all that bandwidth on the ready just isn’t a good business plan.

“What this says to me is: ‘I don’t want to pay for a highway. But as soon as I get in my car, I want a highway.’ Well, someone has to pay for the highway,” he said.

Visibility: Cloudy With a Chance of SDN

Another factor of concern was network visibility. Carriers’ businesses ride on meeting service level agreements (SLAs), which are defined in terms of bit rates and connection uptimes. With SDN, it won’t always be easy to get those metrics.

In Tata’s case, it’s been a five-year effort just to be able to track an application through the network core and observe its performance. “You were talking about integrating something into a customers’ directory environment so you can identify a stream and all of that sort of thing,” Walker said. “I had to replace my entire global core, my MPLS network in order to be able to do that, because I couldn’t do it with my old vendor.”

The cloud is making that job even more difficult. Walker cited an example where a customer depends on being able to sign up accounts through Salesforce.com. The transaction time through Salesforce is 600 to 1,400 milliseconds. This customer can get packets to Salesforce in 10 milliseconds, but then the transaction faces an uncontrollable, unpredictable delay.

Granted, that’s not an SDN problem. But it exemplifies how difficult it’s becoming for carriers to keep application performance snappy.

It’s going to be a universal problem, because customers that previously sent traffic across MPLS networks are relying on the Internet more and more, said Andrew McFadzen, head of global marketing for networks at Orange Business Services. That leads to hybrid networks and the need for application-based routing to steer traffic to the appropriate part of the network.

“That starts as well when we’re looking at things like network functions virtualization. Can we start to look at application based routing as a cloud service? It’s quite fascinating,” McFadzen said.

(Photo courtesy of the MEF.)

SDxCentral Daily News

Join your Peers! Subscribe to SDxCentral's Newsletter

Article Tags:

Breaking News Metro Ethernet Forum NFV Orange SDN Tata Communications

Craig Matsumoto

About Craig Matsumoto

Craig Matsumoto is managing editor at SDxCentral.com, responsible for the site's content and for covering news. He is a "veteran" of the SDN scene, having started covering it way back in 2010, and his background in technology journalism goes back to 1994. Craig is based in Silicon Valley. He can be reached at craig@sdxcentral.com.

Subscribe to Get the Daily News!

About SDxCentral

  • Newsletters
  • About Us
  • Contact Us
  • Work With Us
  • Editorial Team
  • Careers
  • Legal
  • Support

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDxCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.

© 2012-2019 SDxCentral, LLC, All Rights Reserved. SDNCentral™, the SDNCentral logo, SDxCentral™, SDxCentral logo, SDxNews™, SDxTech™, SDx™, the SDx logo, and DemoFriday™ are trademarks of SDxCentral, LLC in the U.S. and other countries.

  • Terms of Service
  • Privacy