Federation is an important topic in both SDN and NFV for a number of reasons, but it’s not clear that the standards processes for either SDN or NFV are really moving to define a reasonable strategy. The issues of federation will eventually have to be faced—there are some indications that vendors are jumping out to address them even pre-standard—so it’s a good idea to look at the issues and also to try to outline an effective solution. Particularly since the best approach unites SDN and NFV in a way that’s not been discussed much.
“Federation” is a term that’s been applied loosely to service relationships among operators that allow for services to be created and deployed across administrative and technical boundaries. Where there’s a standard network-to-network interface that serves to connect services seamlessly, it’s not much of an issue (the Internet, based on IP, has BGP for this). Where there isn’t, you need some structure to determine how to create the link.
All federations expose operators who sell services and enterprises/consumers who buy them to a set of common issues. First, you have to be able to connect the service across the boundaries of the federation. That includes not only passing packets but also harmonizing any SLAs offered and dealing with any required financial settlement. Second, you have to be able to manage the service end-to-end and address problems/remediation wherever they occur, without compromising the independence of the federated partner domains.
Most federation today is based on the presumption of a series of interconnected service networks that offer comparable capabilities based on comparable technologies, and whose technical standards include one for network-to-network interconnect. The question that both SDN and NFV raise is how the concept would work when networks were virtual, meaning that they didn’t have a fixed capability set or service-layer standards.
The easiest thing to do is assume that you’re going to use virtual technology to duplicate current service-layer protocols like Ethernet or IP. If this is the case, then you can federate your offerings at the first or connection level. To make this approach work at all, you need to build virtual networks that exactly mimic L2/L3 service networks, including the NNIs. If you presume that SLAs and financial issues are related to the “service layer” then you can assume that duplicating service-level capabilities with virtual infrastructure would address all of the connection issues.
Not so the management, and this is the fact that opens the rest of the discussion on federation.
If you presume service-layer federation, then you are effectively drawing a service as a set of connected domain-specific sub-services of the same type. The constraints on protocols supported and features offered can be used to justify a position that these sub-services are intent models and so is the retail offering. In past blogs I’ve asserted that a network service abstraction expressed as an intent model has a functionality, endpoints, and an SLA. That would be true of our sub-services, and if we say that a sub-service implemented using SDN or NFV meets the functional requirements and SLA and serves the endpoints, then it realizes the intent model as well as legacy devices could.
The first issue this raises is one of out-of-the-legacy-box service functionality. Where we have accepted boundary interfaces and features and SLAs, we can map SDN/NFV to service models inherited from the legacy world. Where we don’t, meaning where we elect to extend today’s L2/L3 connection services, the question that arises is whether constraining SDN/NFV to legacy service models is a suitable strategy given the goal of revenue augmentation. If such constraint isn’t optimal, then what has to happen for federation to work?
To start with, it should be clear that the SLA properties of intent models might be enforced by something like policy control inside the model, but structuring and federating a management view based on them is probably forever outside the scope of SDN. NFV, on the other hand, pretty much has to create derived management views just to present a virtual-function implementation of something in a way equivalent to a native-device implementation. My conclusion here is that NFV is a natural partner to SDN in management and federation, and that we shouldn’t bother to try to augment SDN to address management federation.
What about connection federation? The issue here, if we look at our sub-services as intent models, relates to the question of what the “functionality” of an intent model is, and how it’s expressed. If we were to see an IP sub-service, for example, we could define the function as “IP Domain” and offer two broad classes of interfaces—UNI and NNI. If we presumed that there was a general model for OpenFlow forwarding, we could define a function as “OpenFlow Domain”, but our “Ports” would now be of one class and we’d have to address the question of how forwarding decisions could be made across multiple OpenFlow Domains.
The ONF, in OpenFlow, has taken a protocol-and-interface approach to things, which is inherently more limited than what I’ll call a “software-process” approach—the approach NFV explicitly supports. It’s hard to see how you could define a simple protocol/interface to accommodate the sharing of forwarding-decision-support data for a generalized service, but easy to see how a software process could offer that. Thus, it would seem that connection federation would be more easily supported by NFV, which could then drive SDN.
This creates a model of NGN where NFV sits on top to manage agile operations and management, and which then drives a series of lower-layer intent-modeled NaaS abstractions realized using whatever technology is optimal. The decisions on forwarding in this lower layer could be met through the SDN Controller, and higher-layer multi-domain federation would then be managed by NFV. This model seems appropriate if we assume that selection of NaaS domains would take place based on something other than traditional topology and traffic metrics, because NFV has to be able to make that kind of selection already.
The model wouldn’t foreclose using inter-SDN-controller links to exchange information among control domains. If this were supported, then a lower-layer NaaS abstraction could actually be made up of multiple SDN-implemented domains. The problem with this is that if metrics other than forwarding efficiency were needed to select implementations for a given NaaS, SDN isn’t equipped for it and it makes no sense in my view to augment SDN to creep into space NFV already occupies.
All of this suggests to me that carrier SDN might well depend on NFV for deployment, and that the relationship between SDN and NFV might be more complicated than either the SDN or NFV communities are currently envisioning it to be. I’ve always believed that many, perhaps most, of the NFV benefits were tied to a more organized NaaS vision than either SDN or NFV currently presents, which would mean that evolving both SDN and NFV toward such a vision could be a prerequisite for the success of both.