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
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.)
While there is undoubtedly an SDN and NFV equivalent of the ATM cell tax (especially in NFV where even accelerated cloud deployments of VNF’s will see a performance hit over bare metal) I think the problem here is that people tend to view SDN (and NFV) as ‘all or nothing’. If we take a systematic approach to implementing both in a logical manner, then the cost savings and benefits are more readily realized. The quintessential ‘low hanging fruit’. For NFV, we know that it’s areas such as the EPC. In SDN – as you say – it is point-applications such as providing a dirt-cheap alternative to BGP provider edge routers (for east-west traffic offload) or powerful but cost-effective MPLS label edge routers – capable of network-wide path computation and steering traffic without a forklift replacement of the existing core.
While perhaps not the programmable nirvana people think, these applications are the essence of SDN – control and forwarding plane separation – either at the point level (i.e. the first application) or network-wide (the second). Neither requires all SDN-aware elements, but simply provides obvious cost advantages over the current options.
I could even extend a different perspective on the bandwidth-on-demand argument – that is I don’t see it as having bucket-loads of bandwidth waiting to be used – quite the opposite. Carrier SDN is all about bin packing – implementing a technology that makes more efficient use of the available network resources. As bandwidth and paths are so static in nature, today, both are almost always over-provisioned.
The simple view of BoD provided by Tata assumes that the controller is not capable of dynamic re-allocation of resources which, quite frankly, they will be if we assume techniques such as active PCE are employed – which is the direction most are adopting for application layer traffic optimization (ALTO) and application-based network operation (ABNO). Now, are those frighteningly complex? I my world, yes – but with expensive (L1-L2.5) transport and switching resources at stake, it’s tough to argue the potential cost benefits.
These people who make up the MEF seem to be living in alternate reality.
I guess SDN doesn’t fit into their agenda or maybe it’s too complicated for them to understand.
Also, conflating Tata’s problem with every other carrier in the world is disingenuous because that network is quite unique and not even a true carrier. It’s a bunch of managed services that share a common backbone, barely even that.
There was a service in ISDN. What is it for SDN?