Getting SDN and NFV to Be Truly Symbiotic

Datetime:2016-08-23 00:21:20         Topic: SDN          Share        Original >>
Here to See The Original Article!!!

The relationship between SDN and NFV has always been complicated and often a bit competitive.  SDN had an early lead for mindshare and vendor support but NFV captured the media’s attention quickly and today it seems to be leading in the field of strategic interest to operators.  However, nearly all the operators I’ve talked with believe that it’s not an either/or a “this-first” approach at all, but a struggle to find a useful symbiosis.

SDN is a connection technology, a way of controlling forwarding and route determination explicitly through centralized control.  In theory it would be usable at any level in networking, though it’s always been my view that SDN isn’t particularly useful at the optical layer.  Since service agility and operations efficiencies are the driving benefits needed for any new technology, and since those benefits are highest at the top of the stack where most services are created, it would make sense to adopt SDN there.  The problem is that operators aren’t convinced that central control scales to large networks where efficiency and agility are the most useful.

NFV is a function hosting technology.  While it makes clear sense if you presume that hosting functions on commodity servers would eliminate expensive proprietary gear, the capex-benefit paradigm has long been discredited as a prime driver because savings aren’t large enough and there are concerns that the additional complexity associated with function hosting would raise opex more than it would lower capex.  In addition, servers are simply not powerful enough to replace all network devices—optical transport and even big switches/routers would require specialized hardware that would probably end up looking like the very proprietary devices NFV is supposed to displace.

There is a clear point of symbiosis between SDN and NFV, or more accurately between cloud hosting of anything that’s multi-tenant and SDN.  The utility of SDN to create multi-tenant data center connections is well established, and if we were to see a major operator commitment to carrier cloud (including NFV) we’d surely see SDN use expand.  However, this mission isn’t really going to move the ball a lot for SDN, in part because we’re still struggling to make a large-scale carrier-cloud-and-NFV business case and in part because SDN inside the data center isn’t a major technology shift.  For that, we need SDN to get into the WAN.

There are two possible approaches to creating an SDN/NFV symbiosis beyond the obvious in-data-center one just noted.  One is to use SDN to address the big-box limitations of NFV by building “virtual-wire” networks that partition connectivity so that at least VPN/VLAN services and possibly other non-Internet services could be built using hosted switch/router instances.  The other is to use NFV to host control/signaling plane functions and let SDN do the data-plane lifting.

I’ve blogged in the past about using SDN to partition private networks by creating per-tenant “virtual wires” that would then be combined with SD-WAN-like edge forwarding rules and hosted-router-instance nodes to create VPNs.  This approach could meld SDN and NFV nicely, with NFV deploying edge and nodal elements and SDN doing the connectivity, but operators say that it has the usual disadvantage—too much first-cost and early risk because it requires fairly wide deployment of both SDN devices and NFV hosting points.

It seems to me that the SD-WAN evolution approach would be the easiest way to get to the virtual-wire-partition model of symbiosis.  You could build an overlay network based on today’s infrastructure and services, including the Internet, and use NFV to deploy both edge features and interior nodes.  SDN could be used to control the connectivity, and if white-box electrical-layer technology expanded to further groom agile optics, this could then create virtual wires that could gradually displace the legacy elements.

The second place where the control/data symbiosis has been demonstrated is in mobile infrastructure.  Anyone who’s followed mobile standards knows that there’s a lot of buzz around the use of SDN and NFV in the IP Multimedia Subsystem (IMS) and Evolved Packet Core (EPC) and that SDN and NFV are also routinely linked to 5G and VoLTE.  If you look at the functional diagram of IMS/EPC you see something that seems to be of mind-boggling complexity, and since mobile infrastructure is about the only place where rapid changes are being funded these days it would be easy to introduce something new at the next point of investment.

IMS and EPC are really signaling-plane activities that rely on a virtual-network overlay even with today’s technology.  There are a dozen functional elements that are there to register devices and associate them with accounts for charging purposes, and another half-dozen that are there to control a set of moving tunnels that link a user in any of a collection of cells with a fixed point of access to services.  IMS and EPC were designed before either SDN or NFV came along, and they are happily running today without any support from SDN or NFV.  The question is whether they could run better.

At the signaling level, the big advantage that NFV could bring is support for the placement of IMS/EPC functional elements in the optimum places, and at the optimum numbers, needed for current traffic and activity.  You can spin up a piece of virtual IMS or EPC as needed, and then decommission it if traffic/activity declines.  Since mobile services are unusually signaling-intensive because of mobility management, the elasticity of control-plane topology and capacity would be especially valuable.

SDN could in theory be used to create the kind of tunnels used in EPC to link the Packet Gateway with the cell sites (via the Serving Gateway).  Since mobile infrastructure, as I’ve noted, is a major target for investment (and backhaul is likely to be more demanding as we evolve to 5G) there’s a good opportunity to drive change.  The question is the business case.  It’s easier to validate NFV for hosting signaling-plane elements in an agile way than to substitute SDN for a traditional tunneling technology.  Not impossible, but it would demand a lot of work be done on operational efficiency, resiliency, etc.  Right now we don’t have the story in complete form.

I think that finding a symbiotic mission for SDN and NFV is rendered more difficult by the fact that any network technology change tends to pose a problem of scope, risk, and benefit.  You can do a little of the new stuff at a low cost and risk, and accomplish little in return.  You can do a lot of the new stuff, which poses high first costs and probably unacceptable risk, but would deliver a significant benefit.  Since this is true of both SDN and NFV, getting the two to dance when you can’t teach either of them the steps is doubly challenging.

The cloud is probably the only solution here.  Widespread use of cloud services could create a marriage of SDN in the data center, NFV to deploy agile components of applications, and SD-WAN to deliver tenant-segmented network connectivity into VPNs.  The only rub is that it would be far easier to drive symbiotic SDN/NFV deployment with the cloud if it were the network operators deploying that cloud.  Operators, while they were initially bullish on cloud offerings, have found it to be a very difficult business.  Some think that relying on the cloud to unify SDN and NFV is just adding another point of difficulty to a situation that’s already hard enough to stymie experts.

I don’t know where this is going, but operators tell me that neither SDN nor NFV can reach full potential without the other.  It may be that the real unifier, if there is one, is the operationalization and service automation revolution that could provide a starting point for all SDN, NFV, and carrier cloud alike.  The question is whether that revolution can get past the inertia of OSS/BSS, which has proved at least as problematic as the inertia of long-lived capital infrastructure.

About List