Can “Federation” Accelerate NFV Toward a Business Case?

Vice presidents of operations at the network operators, especially the telcos, think that the solution to NFV silo risk is to do a better job of “federation”.  That term is one often used to describe the interconnection of elements across administrative or technical boundaries.  If a network isn’t built in a truly homogeneous way, then you connect the domains using some kind of federation.  That’s worked in the past, the VPOs think it could work here, so let’s take a deeper look.

The big question with federation is what you federate.  Federation is a relationship between things, so you have to be able to identify specific things to work with.  In classic networking we’ve tended to link domains, divided by technology or whatever, based on one of three things.  First, OSI layers.  You can link “routing” and “transport” by laying IP on top of optics.  Second, network-network interfaces.  You can use BGP boundaries or even IS-IS boundaries to create federation points.  Finally, APIs.  In the cloud (in OpenStack, for example) you can federate at a point where a “model” is passed to an API for realization.

In most cases, federation points are naturally suggested by technology practices, which may be the defining challenge for NFV.  Like operations, federation was declared out of scope by the ISG early on (in the same meeting, in fact).  There has been some work done by the ISG on federation, but the ISG work tends to focus on “interfaces” and functional blocks and it doesn’t define NNI points explicitly.  That doesn’t mean federation wouldn’t work with NFV, only that we’d have to define where we wanted it and then work out how it could be done.

The beauty of the model approach is that a model is a kind of agile “thing”, meaning that the model approach lets you define a wide range of items that can then be federated.  It’s the only approach to federation that lets you preserve the agility of software-driven implementations of functionality, and so it should be a requirement for any SDN or NFV implementation.

You all probably know my view of how a “service” should be defined—as a structured model that starts with a retail entity and works downward like an upside-down tree to the resource tendrils.  This is what I laid out for both CloudNFV and ExperiaSphere.  If you presumed that we had such a structured model for NFV overall, you could declare a useful and fundamental rule of NFV federation; federation should allow any piece of a structured service model to be sourced from within the owning provider or from a partner.  Further, either of these two options should look the same to the higher-level elements that referenced them.  Federation should be an outcome of a resource-abstraction process.

If we start with this approach, it’s easy to take the next step and say that federation is based on “outsourcing” the resolution of an intent model.  An intent model is a black box that’s defined by its interfaces (ports/trunks), its functionality, and its SLA.  A “LINE” intent model has two interfaces, the functionality of bidirectional open connectivity, and an SLA of whatever can be delivered or is needed.  If the LINE connects two points inside the service owner’s network, then it’s resolved on the owner’s infrastructure.  If not, then it’s resolved at least in part by a third party.

The “how” is interesting here.  If we had a partner providing us with a connection to a single customer site that happens to be on their network, we could visualize the LINE as decomposing into two LINEs, one of which is “partner-to-NNI” and the other “NNI-to-my-own”.  One thing this demonstrates is that if you use intent modeling of service elements, you can make the NNI points part of the resolution of an intent model, meaning that you don’t have to define explicit NNIs in the specifications.  That means that as long as we could use intent-modeling principles with ETSI NFV we could make it work without NFV having specific federation specifications and interfaces.

In order to make something like this work, we’d need to build a bridge between the two implementations, so that when the owning operator decomposed the LINE, it would result in the dispatch of a kind of virtual order into the partner.  We’d also need to be sure that lifecycle management and event handling passed across this bridge.

You can’t have bridges if everyone wades across on the periphery.  The bridge has to isolate the two environments—one is a customer to the other—without disconnecting lifecycle management.  The key requirement to make this work is that the intent model has to send parameters to the realization partner, and receive management state from that partner, within the model.  The model is the in-two-worlds binding that couples lifecycle processes.

The interesting thing about this approach is that it would work between operators or within one.  This means that federation processes would support partnership, but also (as VPOs suggest) would be a path to eliminating silos.  To make it work, though, you would need to have an intent-model structure for services in all of the implementations.  Since the ETSI ISG is looking hard at intent models, that means that it might be possible to address the silo and federation issues at the same time and with something already in the works.

Intent modeling of this sort could make it unnecessary to extend federation beyond service modeling, because resources are typically going to be federated as collections of behaviors within an intent model.  However, the NFV specifications call for another level of abstraction, the VIM abstraction of infrastructure (NFVI).  You can model infrastructure as an intent model too, and you can use the same bridging concepts noted above to allow any implementation of a resource to assert the same functional/intent behaviors.  Same with management variables.  This would mean that an operator could publish a portal into their NFVI to another, as long as there was a VIM to represent the NFVI in both worlds and a model that provided the bridge.

How many business-case issues could federation fix?  That’s hard to say, but I think that if we had a structured service and a VIM/NFVI implementation based on intent modeling we could harmonize differences in NFV implementations to prevent service silos.  That would allow operators to develop business cases that were more service-specific and still be assured we could harmonize them down the line.

The weak spot, as always, lies in the operations model.  In theory you could manage a federated service element in its own way, but unlike NFVI whose economies of scale can be preserved by federation, there’s no assurance that separated operations processes would be compatible, much less efficient.  What this means is that federation is a step toward an NFV business case, but by itself it doesn’t guarantee you’ll arrive.