One of the interesting things about SDN is that it may be getting clearer because of things going on elsewhere. We still have a lot of SDN-washing, more models of what people like to call “SDN” than most would like, but there’s some clarity emerging on just how SDN might end up deploying. I commented on SDN trends in connection with HP’s ConteXtream deal last week, and some of you wanted a more general discussion, so here goes!
There have been three distinct SDN models from the first. The most familiar to most is the ONF OpenFlow “purist” SDN, the one that seems to focus on SDN controllers and white box switches. The second is the overlay model, popularized by Nicira, which virtualizes networks by adding a layer on top that’s actually a superlayer of Level 3 not Level 4 as some would like to think. The final model is the “software-controlled routing/switching” model, represented in hardware by most vendors but in particular Cisco, and in software by virtual-router products like Vyatta from Brocade.
Virtual switching and routing, and overlay SDN, are all the result of a desire to virtualize networks just like we did with computing. In effect, these create a network-as-a-service framework. That can be done with ONF-flavored SDN too, but the white-box focus has tended to push this model to a data center switching role, and to a role providing for explicit forwarding control in the other models.
Too many recipes spoil the broth more decisively than too many chefs. Diversity of approach and even mission isn’t the sort of thing that creates market momentum. What I think is changing things for SDN is a pair of trends that are themselves related. The first is rapidly growing interest in explicit network-as-a-service, both for cloud computing and for inclusion in retail service offerings. The second is NFV, and it may be that NFV is why the NaaS interest was finally kindled in earnest.
NFV postulates infrastructure controlled by a “manager” of some sort. Initially this was limited to a virtual infrastructure manager, but many in the ISG are now accepting a “connection manager” responsible for internal VNF connectivity, and some are accepting that this might be extended to support connection to the user. The important notion here is the “manager” concept itself. You have to presume (the ISG isn’t completely clear here so “presuming” is a given) that a manager gets some abstract service model and converts it into a service. That’s a pretty good description of NaaS.
If a manager can turn an abstraction into connections under the control of MANO in NFV, it’s not rocket science to extend the notion to applications where there’s no NFV at all. I could use an NFV VIM, for example, to deploy cloud computing. I could use a “connection manager” to deploy NaaS as a broad retail and internal service.
In NFV, most would think of the connection manager as controlling SDN, meaning that there’s an SDN controller down below. That would likely be true for NFV inter-VNF connections, and it could also be true for edge connections to NFV services. But logically most “connections” beyond the NFVI in NFV would be made through legacy infrastructure, so connection managers should be able to control that too. Some would use OpenDaylight, and others might simply provide a “legacy connection manager” element.
It’s this that makes things so interesting, because if we can use connection managers to create NaaS and we can have legacy connection managers, we can then use legacy infrastructure for NaaS. The manager-NaaS model then becomes a general way of addressing infrastructure to coerce it into making a service that can be sold.
In TMF terms, this might mean that “managers” are providers of resource-facing services. If that’s true, then orchestration at the service level, meaning within OSS/BSS, might be able to do all of the higher-level orchestration involved in NFV. “Higher-level” here would mean above MANO, above the process of deploying and controlling virtual functions.
Oracle sort-of-positioned itself in this camp with their NFV strategy. I commented that it was the most operations-centric view, that it had TMF-style customer-facing and resource-facing services, and that it seemed to be positioned not as a limited implementation of VNF orchestration but as a broader approach, perhaps one “above” NFV.
I’ve been saying for quite a while that you need total cross-technology, vertically-integrated-with-OSS/BSS orchestration to make the service agility and operations efficiency business cases for NFV. There’s always been three options on getting to that. First, you could extend NFV and MANO principles upward. Second, you could extend OSS/BSS downward, and third you could put an orchestration stub between the two that did the heavy lifting and matching between the environments of OSS/BSS and NFV. How would an SDN-and-legacy NaaS model influence which of these options would be best, or most likely to prevail?
It might not change much, even if the NaaS story comes about. The NFV ISG has taken a very narrow position on its mission—it’s about VNFs. If you presume that the evolution to NFV comes about because services are converted from appliance/device-based to VNF-based, then the easiest way to orchestrate would likely be to extend MANO upward. If you presume that NFV deploys to improve service agility and operations efficiency, then orchestration has to provide those things, and even if you orchestrated VNF-based versions of current services you’d still have the same operations problems unless something attacked that area too.
There’s some pressure from operators conducting NFV trials to broaden the trial to include operations, and also some to demonstrate specific efficiency and agility benefits. However, these trials and PoCs are based on the ISG model of NFV and so they’ve been slow to advance out of the defined scope of that body. Operators haven’t told me of any useful SDN orchestration PoCs or trials, and most of the operations modernization work in operators is tied up in long-term transformation projects.
That’s what’s creating the race, IMHO. NFV could win it by growing “up”, literally, toward the higher operations levels and “out” to embrace legacy elements and broader connection-based services. SDN could win it by linking itself convincingly to an operations orchestration approach, and OSS/BSS could win it by defining strong SDN and NFV connections for itself.
Who will win is probably up to vendors. OSS/BSS has always moved at a pace that makes glaciers look like the classic roadrunner. NFV is making some progress on generating a usefully broad mission, but not very quickly. So I’m thinking that the question will come down to SDN. Can SDN embrace an orchestration-and-manager model? The competitive dynamic that might be emerging is what will answer that question.