The thing about revolutions is that they’re…well…revolutionary. Out-with-the-old-in-with-the-new is a popular concept (especially if you’re not among the “old”). They’re exciting because the shake things up, create new media fodder, all sorts of good stuff. But they’re expensive and tiring, and so it’s hard to have more than one of them in the same market area at the same time.
SDN is supposed to be a revolution. So is NFV. Which of the two might have the most impact were it alone in the revolutionary stratosphere is hard to say, but they’re not alone. It’s likely that if there aren’t harmonizing moves, common steps, to be taken to unify the execution if not the technology, both will suffer.
To SDN, most of NFV is north of those northbound APIs, an area that’s not likely to be defined. To NFV, SDN is south of those Virtual Infrastructure Managers, and the fact is that this area must be defined if NFV is going to work. Thus, while NFV may be no more important than SDN, NFV will have to accommodate SDN quickly, or lose relevance. Not because SDN is critical but because it represents something critical.
SDN provides the service of connectivity to its users. That means that within NFV, SDN has to be viewed as a connection option, a connection service element. Our first challenge in alignment is that NFV doesn’t really focus on connections to users. An early decision in NFV was to focus on the specific service elements that were based on software and deployed on servers—the VNFs. The “end-to-end architecture” for NFV doesn’t actually encompass the ends at all. It starts inside the service, where NFV hosting starts. No access, no transport.
This focus is critical because a decision to include everything that’s part of the user’s end-to-end service view would have induced the ISG to address how to model and orchestrate legacy network elements that will surely be part of any NFV service. Since SDN is intended to displace legacy switch/routing in some or all of these legacy missions, the approach taken for legacy could have been applied to SDN as a baseline. But don’t despair. We can extrapolate a bit.
There are two kinds of connections in NFV. One addresses the data paths that are visible to the user of the service, and the other the data paths that are needed within the structure of virtual functions NFV builds in order to connect the pieces. In today’s world, it’s likely that almost all the visible, external-to-NFV, data paths would be supported using legacy technology. It’s also likely that if VNF hosting points were distributed in any way, the internal data paths would today contain some legacy elements.
Over time, internal paths could be connected via SDN fairly quickly because it would be possible to incorporate SDN-based networking in the “cloud networking” part of NFV. Substitution of SDN for external paths would be more complicated from a justification perspective and also take longer.
The implication of NFV architecture today is that NFV Infrastructure would include both hosting and cloud-like connection services. This appears to be supported by the PoCs to date, which tend to supply connectivity among VNFs by using something like Neutron or vSwitches. I suggested in a prior blog that the logical approach to SDN within NFV is to generalize the VIM into an Infrastructure Manager (IM) and assign the connection function to such an element. This would be compatible with either the internal or external connection missions, so NFV models and MANO could be extended to the true service edge. But there are also some issues to consider.
The first issue is whether there is such a thing as a “legacy IM” and “SDN IM” or whether SDN and legacy are choices that an IM makes down below. This might seem like one of those “how-many-angels-can-dance-on-the-head-of-a-pin” arguments, but it’s not. If we have to segregate IMs by the underlying technology, then the details of network domains that use multiple technologies or even multiple vendors might have to be exposed upward into MANO so it could call the correct IM. That makes service models very infrastructure-specific and means any change to the network would demand corresponding changes to all the models. I think that’s outlandishly inefficient and error-prone.
But that makes the second issue even more important. If we want MANO to ask for a connection service at a generic level, how do we define it? This is one of the many reasons I’ve rejected the Yang vision, which proposes to model services at a nodal level. We should not be asking for IMs to build services by handing them the topology; MANO should be opaque to those details. So what do we hand it? In both CloudNFV and ExperiaSphere I proposed we define “service models” that describe a service as the connection relationship of the endpoints. The classic example is LINE, LAN, and TREE for point-to-point, multi-point, and multicast. If I know the OSI layer (meaning the header component) associated with a service and the connection model I want, I can build it no matter what my underlying infrastructure might look like.
If you take this approach, then SDN becomes an option to support connectivity in any part of any network domain represented by an IM. What’s required is that the IM itself understand the topology of the network it supports, in terms of the nodes, paths, and protocol choices. It’s hard to see how you could control something without that knowledge, so I don’t think this is a heavy burden. In simple terms, a service model would be decomposed into a set of relationships built via NMS (for legacy services) or SDN Controllers for SDN.
You can also see an example of what I previously called “functional” versus “structural” orchestration here. The service model at the functional level is decomposed into IM-jurisdictional atoms that passes sub-models to the appropriate IMs. These IMs then perform a structural level decomposition, creating the requested connectivity (or whatever) by marshaling resources based on topology, capability, connectivity, and policy.
My point here should be clear by now. If you do NFV right, then making it work with SDN is an automatic byproduct of the approach. SDN gurus can address the structural processes that build resource commitments (forwarding rules and paths) based on the service models. NFV gurus can worry about the functional modeling that supports decomposition, which as I said in a prior blog is done by binding functional objects to the resource pools responsible for fulfilling them. We don’t need two revolutions.
However, as I’ve also noted, we don’t need to call the top-level revolution in modeling “NFV”. The fact is that this kind of functional model could reside in an NFV implementation, or above it in some operations-to-resource boundary layer, or even in the OSS/BSS. It’s the model that matters, so what we’re saying is that this is a virtualization revolution, using virtualization-framed modeling and decomposition principles. NFV is a carrier, a vehicle for driving this change because it can link it to some near-term benefits. Both that concept and that linkage to benefits are critical.