I’ve done a couple of blogs on SDN topics, but one of the important questions facing everyone who’s considering SDN is how it would fit in the context of NFV. For network operators, NFV may well be the senior partner issue-wise, since NFV is explicitly aimed at improving capital efficiency, service agility, and operations efficiency and (at least for now) it doesn’t seem to be advocating a fork-lift for the network overall. But what is the relationship? It’s complicated.
The NFV ISG is at this point largely silent about the role of SDN in support of NFV. In large part, this is because the ISG made a decision to contain the scope of its activities to the specifics of deploying virtual functions. At some point this will have to spread into how these virtual functions are connected, but the details on that particular process haven’t been released by the body. Still, we may be able to draw some useful parallels between the way that NFV MANO exercises virtual function deployment processes and how it might exercise SDN.
In the current spec, MANO drives changes to the NFV Infrastructure through the agency of a Virtual Infrastructure Manager or VIM. In a sense, the VIM is a handler, a manager, that would presumably harmonize different cloud deployment APIs with a standard interface to MANO so that orchestration wouldn’t have to know about the details of the underlying resource pool. Presumably OpenStack would be one of these options, and presumably things like Neutron would be exercised through a VIM.
The first question here is how the capabilities of resources as cooperative behaviors of functional systems can be represented. What is it that a network of any sort uses to describe something like a VPN or a VLAN? In OpenStack, this would be done by referencing a “model” that (while the implementation has evolved from the old Quantum networking to Neutron) is a logical structure with known properties that through custom plugins can be realized on a given infrastructure. The Neutron approach, then, is to have some high-level abstraction set representing network behaviors, and then provide a plugin to implement them on specific gear using specific interfaces or APIs.
My view is that these models are the key to creating a useful representation of SDN for NFV. If we assume that a “model” is anything for which we have at least one plugin available and which has some utility at the MANO level, then this approach allows us to define any arbitrary set of network behaviors as models, which unfetters SDN from the current limitations—we think of it as another way of creating Ethernet or IP networks.
The question is where to apply it. NFV has an explicit requirement for inter-VNF connectivity, just as any cloud deployment architecture does. If we think of SDN at the most basic NFV level we’d think of it as a way of connecting the VNFs, which would make SDN logically subordinate to the VIM, just as Nova and Neutron are subordinate to OpenStack. I think many in the ISG (perhaps most) think this way, but in my view there are two problems with the notion. One is that it doesn’t offer a solution to end-to-end networking and so can’t address the full benefit case operators are tagging as an NFV target. The other is that applying it would tend to make NFV into nothing more than OpenStack, in which case the effort to date wouldn’t really move the ball much.
The alternative is to presume that there’s a handler, like a VIM, that handles network services. A VIM could be a specific case of a general Infrastructure Manager (IM) that is responsible for harmonizing various APIs that control resources with a common interface or model that’s manipulated by MANO. This approach has been suggested in the ISG already, though not fully finalized. We could still invoke the “Network-as-a-Service” IM from inside a VIM for connectivity among VNFs, but we could also orchestrate the non-NFV service elements likely to surround NFV features in a real network.
This defines a challenge for the ISG, one that has existed from the very first. There is logically a need to automate service deployment and management overall. That need has to be filled by something that can orchestrate any service elements into a cooperative relationship, not just VNFs. If the ISG defines, in its approach to MANO, something that can be generalized to support this high-level super-MANO, then it defines a total solution to service agility and operations efficiency. It also defines the IM and the model(s) that IM represents as the way that SDN and NFV relate. If the ISG doesn’t take that bold step, then it cannot define an NFV/SDN role because it doesn’t cover all the places the two technologies have to complement each other.
All this implies that there may be two levels of MANO, one aimed at combining logical service elements and one aimed at coordinating the resources associated with deploying each of those elements. The same technology could be used for both—the same modeling and object structure could define MANO at all levels—or you could define a different model “below” the boundary between logical service elements and service resource control. I’m sure you realize that I’m an advocate of a single model, something that works for NFV but works so independently of infrastructure (through the model abstractions of IMs) that it could deploy and manage a service that contained no VNFs at all.
You probably see the dilemma here, and also the fact that this particular ISG dilemma is one that’s shared with other bodies, including the ONF. There’s a tremendous tendency to use scope control as a means of assuring that the specific needs of a process can be met, but that can create a situation where you know how to do something limited, but can’t address enough of the problem set to develop a compelling benefit case. No standard is helpful if it solves a problem but can’t develop a business case to justify its own deployment. Sometimes you have to think bigger or think “irrelevant”.
The ISG contributed what might well be the seminal concept of NGN, which is MANO. It also contributed the notion of a “Manager” that represents infrastructure behaviors at the service level and allows service architects to build services without pulling infrastructure details into their composition. What it now has to do is to fully exploit its own contributions. Unlike SDN work, NFV work is arguably already above the network where services are focused. If NFV can grow down, via generalizing its handlers and exploiting its notion of models fully, then it could not only drive its own business case, it could drive SDN deployment too.
At the end of the day, there’s only one network. Somebody has to orchestrate and manage it.