This week, the ONF and the NFV ISG announced they would be entering a “strategic partnership” to define how NFV could use SDN to address the connectivity requirements of its use cases, and the ONF published a preliminary document to describe an example. That SDN and NFV have to cohabit has been clear from the first, but the announcement material offers some hints as to how both groups will have to evolve, and what might emerge at the end. As always, there’s good and bad news.
The ONF’s reference framework for SDN is a three-layer structure with the top layer being the Application Layer where “business applications” live, the middle layer the “Control Layer” where network services are presented, and the bottom layer the “Infrastructure Layer” where real hardware lives. Applications presumably call on network services that are then created (using OpenFlow) by the control layer.
NFV’s connectivity model is evolving, but what seems to be emerging is the notion of “network-as-a-service”, which would be some set of abstractions representing a connectivity model—VLAN, VPN, subnet…you get the picture. During orchestration, the MANO processes would call for a model and this model would be instantiated (through an infrastructure manager) on real hardware. The ISG seems to be evolving toward recognizing that some IMs would be managing “virtual” infrastructure and others might be managing real (eg. WAN) infrastructure.
It’s pretty obvious that NFV’s notion of NaaS models could map directly to the ONF Control Layer notion of a “network service”. That would mean that NFV (both the VNFs and MANO) would live in or parallel to the Application Layer. To be more detailed, MANO would be acting as a kind of network service broker for the VNFs being orchestrated, so that it creates the network services that the VNFs then consume. That’s not a big deviation from the SDN norm, since few network users would want their applications brokering their own network services without intermediation for security, stability, and cost control. And, in fact, the diagram provided by the ONF to illustrate a use case for the cooperation shows just that—NFV is a consumer of the Control Layer services.
Some may see this as deprecating NFV, but it’s a realistic picture of NFV’s relationship to the ONF model. However, I could draw my own diagram that would make NFV a three-layer structure and stick all of SDN as a plug-in on the bottom. It’s a “New Yorker’s Map of the US” all over again (if you’ve never seen this little item, you’d see all of Texas as being about the size of Central Park). If you look past the histrionics, the two views are really the same thing. SDN is just one possible way of generating a service/connection model fulfillment strategy for NFV.
Why, then, are we making a big thing of this? There should be no need for a strategic alliance to establish how SDN could fulfill the connection requirements of an NFV use case. Unless SDN is brain-dead it should be able to fulfill them in many ways out of the box, and in fact it could—at one level. I can construct nice SDN paths between VNFs for sure. The question is whether that does any good. If three VNFs think they’re on the same LAN subnet and reach each other through normal IP/LAN processes, then that’s what you’d better be creating with SDN. It’s not the use case or the workflow relationship between VNFs that matters, it’s the network model that the VNFs were written to live on. You can’t tunnel something to an interface that’s not a tunnel interface, software-wise. But this is something the NFV ISG still hasn’t glommed onto, and maybe the SDN connection will provide the insight.
The real value-add of this alliance (and of the ONF’s diagram) is that notion of a “network service” as the thing that links SDN and MANO. NFV has to consume connection models created by cooperative device behaviors (real or virtual device) down below. Orchestration at the VNF level (or higher) can’t get bogged down in the lower-level details because if that were the case then the “recipe” for a service would have to be revised for every infrastructure detail that changed. The world of MANO, in NFV, knows the world of NFVI through the intermediary of a series of models (at least two classes, one representing hosting models and the other representing connection models). Similarly, VNFs live in hosting/connection models that were created for them. What ties things together isn’t SDN specifically (as we’ll see) it’s the models.
Another interesting thing in the ONF diagram is the representation of the Control Layer as OpenDaylight. What I like about OpenDaylight is that 1) it makes the notion of “network services” explicit and 2) it has southbound plugins beyond just OpenFlow. The connection models used to connect VNFs are not all going to be based on SDN because SDN isn’t going to be universal when NFV deploys—if ever. However, OpenDaylight can control legacy networks, can map its network services to arbitrary infrastructure, which is what you need to be able to do if you ever expect to deploy NFV on a real-world network.
The key to whether this strategic alliance generates anything other than ink (media happiness at another story to write), is whether everybody in the alliance sees those “network services” as the key development. Every exchange in a world of virtualization and abstraction has to be virtual and abstract. We need to define connectivity to applications and to NFV not based on how it’s achieved but on what properties it asserts to its users. How that happens is just magic, the stuff inside that black-box abstraction. Everything should be about “service models” in both SDN and NFV. It’s not that way now, and that has to change for the good of all.
My final point on the alliance is its sin of omission. SDN doesn’t have squat for a management strategy. IMHO, neither does NFV. Two wrongs (or nothings) don’t make a right. Absent an effective way to build both SDN and NFV into networks as components (so that you don’t have to have a mass extinction that sweeps legacy away to replace it with what you want), service agility and operational efficiency gains are doomed. Yet it is those things that both SDN and NFV want to harness as benefits. You guys both need to ally with the TMF (if they can get their act together on the high-level orchestration problem), or with some responsible higher-layer management process body. Otherwise, benefit-wise, you’re holding hands in the sea beside the Titanic watching the lifeboats row away.