Taking a Harder Look at Cloud, SDN, and NFV Federation

In a previous blog, I talked about two models of “SDN federation”, one that was at the service level and one that was at the “SDN” or controller level.  One obvious difference between the two is that the former requires some specific service, whose interworking features then drive the federation process.  If you wanted to federate on a more general level, you’d need a more general approach, and I think there’s value in looking at how that might work.

The thing is, SDN isn’t the only thing that requires federation.  You also need to federate NFV and the cloud, or at least there’s a high value in doing so.  It’s helpful to look at the deeper level of SDN federation, but at a broader scale so that we address NFV and the cloud as well, and that’s what I propose to do here.

First, I’m using the term “federation” to describe a relationship between two or more administrative domains wherein the two domains retain their autonomy with respect to some customers and services, but agree to cooperate within specific limits to serve another group of customers and another service set.  There are a lot of reasons why federation is important, but historically the big driver has been that not all service providers operate globally and some customers need services on a geographic scale wider than a given provider supports.  Hence, partnership—federation.

Modern services can be visualized as being built at three layers.  At the bottom there’s infrastructure, or the pool of resources needed.  Above infrastructure is the structural orchestration of cooperative resource combinations, and above that is the service framework as it appears to a retail (or wholesale) customer.  It follows that we have to accommodate this layering in the federation process, because we could create federation utilizing any of these layers.

The easiest form of federation to imagine is infrastructure-level federation.  With this level of federation, the partners agree on a means of cross-sharing of their pool of resources.  All of the partners can compose services at the next two levels using a combination of their own resources and the federated infrastructure resources of partners (subject to whatever the restrictions might be).  The partner is not aware of the services being created, only that resources have been committed, and in general the ceding of resources to a federation partner would cede the management of those resources (again subject to potential constraints both technical and commercial).

In SDN, NFV, and the cloud, infrastructure federation would mean sharing the underlying resources (OpenFlow switches, NFV infrastructure, servers or containers) so that they are placed under the control of the structural orchestration of the partner who’s creating the retail service.  In SDN, Carrier “A” uses their SDN controller to control switches in Carrier “B”’s domain.  What makes it simple is that it’s almost purely a matter of making the resources accessible to the partner.  What complicates it is that you have to assume the federating partners have protected themselves against collisions of demand that might impact the services of all involved.

Next up the latter is structural federation, which means that the two parties involved retain structural orchestration of their own infrastructure but link these orchestration processes so they cooperate in some way.  An SDN controller pair might exchange filtered route information so one controller can “see” paths in another domain, but a request for one would then be actioned by the other controller.  This requires creating some structural interworking interface, but it reduces the risk of a partner going maverick and doing something bad to your resource pool and the services it supports.

Structural federation interworking requires some knowledge of how the structuring happens.  We have examples of it in some of the old routing protocols, where a header contained an abstract route stack that described how a packet got through a partner network in a general sense (ingress to egress) but this was popped on entry by the receiving network and replaced with its own specific by-hop instructions.  The same sort of thing could be done in SDN or NFV.  For the cloud, structural federation would mean taking a service model and offering pieces of it to multiple OpenStack instances, for example.

At the top of the list is service federation.  Here each of the federating providers creates a portion of a service, and commands partners to create symbiotic pieces of that same services, connecting them at some physical gateway point.  The service components are “black boxes” that assert their own service-level properties but keep everything else opaque.  The interconnection point doesn’t have to be service-specific as NNIs typically are, but it does have to be service-compatible, meaning you have to be able to pass the service across it.

The work of the IPsphere Forum (now a group in the TMF) was focused on service federation, and this is the type of federation that network operators are probably most comfortable with overall.  It dodges questions of management visibility, though there may still be a need to coordinate remediation across a boundary and offering some drill-down to partners may be a way of doing that.

All federation strategies need to have a combination of a commercial agreement on what’s to be done and a set of technical policy elements to enforce those constraints.  The constraints could be load-related, time-related, location-related, security-based, and management-visibility-based.  In general, the policies would be applied during the activation or modification of a federated service but also during management or control events in general.  That means that you’d likely have to apply policies to the channel that carries federation requests but also at the gateway points where federation traffic connected among the partners.

There are going to be use cases for all the kinds of federation I’ve listed here; there are already, in fact.  These use cases exist in the cloud, SDN, and NFV too.  For all the interest, though, there has been little done in creating an effective template for federation in a complete sense.  In IPsphere, for example, the internetwork gateway point specifications never caught up with the times.  We all know that SDN federation is in its embryonic stages, and cloud federation is almost case-by-case.  I think that this is going to change quickly, though, because carrier interconnect is a way of life and just as we’ve had to accommodate a shift from service-specific networks to converged IP, we’ll have to accommodate the shift to SDN, NFV, and the cloud, in our interconnect plans.

Leave a Reply