SDN came along well before NFV, and there are many SDN implementations compared with “real” (meaning actually complete and useful) NFV. Despite this, SDN became a bit of a junior partner to NFV at least among network operators. Even in my own deployment models, it’s clear that the easiest path to SDN deployment would be in support of an NFV-driven transformation. But suppose NFV doesn’t keep pace? Is there a path to SDN success that bypasses NFV success? Yes, there is—there are several, in fact.
To start off, there’s the cloud. There’s a relationship between NFV and the cloud, in two dimensions. NFV requires cloud hosting in almost all its large-scale success scenarios. The cloud could benefit from NFV’s ability to manage dynamic application configuration and resource changes and simplify operations overall. But the cloud is also different. It’s a framework for operators to sell application/IT services and a new revenue source.
Virtualization at the network level is absolutely critical for cloud infrastructure, whether you’re using it for yourself or selling services from it. Google and Amazon both have developed sophisticated network virtualization capabilities as part of their cloud offering, and even NFV demands much more power in network virtualization than either vendors or operators admit. SDN could be driven by cloud virtualization faster than NFV advances.
The cloud lesson of Google and Amazon is important because it demonstrates that in the cloud, virtual networking has different properties than standard networks do. The further SDN features are advanced beyond the traditional, presuming those advances are valuable or critical, the more likely it is to justify itself. And we know that cloud virtual networking is very different. For example, it deals with inside-outside address space differences and endpoints that reside in multiple address spaces. Those aren’t common features for IP or Ethernet.
The strongest proof point for the potential of the cloud to drive SDN is that it’s had funding. Cloud computing was for several years the leading project for operators. It led mobile enhancement and content distribution, largely because the path to monetization seemed clear. The biggest argument against it is that the cloud doesn’t lead any longer; monetization has been more difficult than operators had expected. Still, SDN that grows out of cloud data centers could drive a major SDN commitment by operators.
Cloud SDN is primarily aimed at user application tenancy control, and the interesting thing about that mission is that application-specific networks take a step toward what could be called application networking versus the site networking of today. That would lead to a big potential growth driver for SDN as a carrier service.
If applications each live on their own partitioned virtual network, then you can give users access to the application by giving them access to that network. The sum of a user’s application rights defines their network connectivity. A user “tunnels” from wherever they are in geography or client address space terms to reach the on-ramp of the application virtual network structure. This model is more secure, more stable, more profitable for the operator because it’s more valuable to the user. In theory any form of SDN that allows for explicit forwarding control could do this, but some vendors (Alcatel-Lucent’s Nuage for example) have made more of a point of highlighting the features needed.
When you look at this kind of network model, you can see another point of leverage that leads to yet another expansion of SDN opportunity. If the user’s “access tunnels” jump onto a virtual network that extends outward near to their location, we’ve created a series of parallel virtual networks that have a large geographic scope and yet don’t touch each other. They’re effectively partitioned at a lower layer than IP or Ethernet, by the “virtual network structure” whatever it is—the thing SDN created.
Well, if we’re partitioning everybody, every service, every application and user, then we’ve got a lot of small address spaces and not one big one. Traditional switching/routing services demand big boxes because they involve large amounts of users and traffic. It’s unrealistic to think that even a big company network could be hosted using virtual routers and servers, and certainly not a service provider network. But if we partition, we have little networks that fit very nicely into virtual switch/routing services.
Think about that. We build VPNs and VLANs today largely by segmenting the connection space of big networks. We could build the same thing by simply building a private IP or Ethernet network within an SDN physical partition. And with that step, we could significantly reduce the investment in switches and routers and further extend the utility of SDN. We push down a lot of the aggregation and basic network connectivity features, along with resilience and SLA management, to a lower layer based on SDN and cheaper to build and operate.
This can be very ad hoc, too. Think of “Network-for-a-Day” as a service. Define a community of interest and a task to be performed. Link the people and resources into an ad-hoc NfaD configuration that’s independent, secure, and has its own SLA. When you’re done, it goes away. Nobody has to worry about persistence of connectivity when the project is over, about someone from the project still having access rights. The network and rights have disappeared together, at day’s end.
IoT could be revolutionized by this. Think of a sensor-community, a control-community. Each of these is made up of sub-communities with their own policies, and each feeds a big-data repository that enforces policy-based access. We now have process-communities that can be linked to these other communities and their repositories, persistently or for a short period. We can charge for the linkage because there is no presumptive access, because networks are now partitioned and if somebody’s not in yours they are invisible, and vice versa.
Same with content. A CDN is now a virtual structure. Users can watch videos and interact with others, in their own narrow community as they define it or in some predefined community. Different classes of users, or even different users, can have different cache sources and partnerships during viewing. Same for wireless or wireline, your own wireless or roaming.
For a lot of vendors, this evolution would be a major problem (Cisco or even Alcatel-Lucent might find it pretty destructive of their router business). For others like Brocade or Plexxi or Big Switch it could be a real windfall, though they might have to do some extra positioning or even product enhancement to get all the benefits on the table.
For operators, SDN has that same “maybe-or-maybe-not” flavor. Virtual networks, like all things virtual, add a dimension of operations complexity that if left unchecked might compromise not only the SDN business case but the whole service framework. This makes yet again a point I’ve often made; you need an operations framework for next-gen services or your gains will at best be illusory and at worst could be proven to be losses.
Like NFV, SDN is something that gets better the more of it you do, and that means that it can be a challenge to start small and get anywhere. The good news for SDN is that there are plenty of places to start, and some of them aren’t all that small. With a little help from the cloud, SDN could actually overtake NFV in deployments at least for a time, which could perhaps mean SDN principles would influence NFV planning and not the other way around. Turnabout is fair play!
