SDN is the senior partner in the reformation of the network, and this week’s ONF event makes it certain that SDN will be getting more attention. There’s no question that operators are working hard on applying SDN to address their problems and opportunities, but it should be clear to everyone that SDN is also a work in progress. It shares the management challenges I’ve pointed out as NFV issues, for example. It also shares NFV’s dependence on a reasonable approach to federation.
There have been many discussions and even some announcements on the topic of SDN federation, but like SDN itself, SDN federation is one of those multi-level things, and it’s also clearly going to have to accommodate which of the multiple (three, at the minimum) SDN models we have. This is likely a good time to step back and explore the issues of SDN federation so we can assess products and standards as they emerge.
In “classic” SDN, a central controller is linked to a set of SDN-enabled switches and this establishes forwarding tables in those switches, which is what creates the “service”. The controller could pre-configure switches with forwarding rules, or it could (at least with OpenFlow) wait until a switch reported a packet for which it had no rule, then supply the rule on demand. Clearly the second of these mechanisms could be process-intensive but few believe that a single, “flat” SDN network based on classic OpenFlow would scale to even the scope of some large private networks today. However, you could divide a network into “zones” and give each zone a controller, then let the controllers connect upward in some structured hierarchy to build a larger network. This is the primary objective of SDN federation, though there are also some who are interested in applying controller-level coordination to services that cross administrative boundaries—user to carrier or between carriers.
It’s important to note here that not all SDN concepts involve central control, and that some SDN architectures that do provide central control also provide a means of federation. This is a good way to start our discussion, in fact, because if we were to view each of the SDN “zones” as “areas” or “subnets” of an IP network, it’s clear that we could make SDN federation work simply by applying the mechanisms for inter-area routing we already have in IP. BGP, for example, is used by a number of SDN providers (Alcatel-Lucent, Juniper) as at least one means of exchanging addressing information among what I’ve been calling SDN “zones”. That demonstrates the first of the options for SDN federation, which is what I’ll call functional federation.
In functional federation, SDN zones are black boxes that obey SDN rules inside but that present a traditional IP (or Ethernet, or in theory any established L2/L3 protocol) sub-area structure at their boundary. The goal of functional federation is to interconnect the service that SDN creates not the technology that creates that service. No SDN controller in functional federation would need to know anything about its neighbors, and in fact it wouldn’t know its neighbors were even implemented via SDN—they could be legacy enclaves of devices.
This is the big benefit of functional federation, in fact. We tend to build IP and Ethernet networks today by connecting functional enclaves or zones, and if we use the mechanisms now being used to connect these zones to connect SDN zones, we can transition to SDN in a gradual way based on local benefits. Also, the largest current application of SDN is in data center networking, and most data center SDN applications create one or more Ethernet subnets that can then be connected to the rest of the network through traditional IP gateways. This means that functional federation resolves most of the federation needs of enterprises.
Not all of them, of course. If SDN “zones” interconnect in many places, if they involve complex optimization of traffic or QoS, or both, then it may be necessary to adopt SDN principles end to end across multiple zones. This requires another level of federation, what I’ll call structural federation because it connects how a service is built and not how a service works. NEC’s recent announcement of hierarchical SDN control is an example of structural federation.
In structural federation, controllers interact with each other to participate in the creation of routes. When a packet has to be routed from point A to B, the goal of structural federation is to get a complete picture of how that route has to be threaded across multiple zones so that it can be set up by instantiating each of the segments in each of the zones at one time. Otherwise, the first packet in the flow has to activate controller intervention in every successive zone if “stimulus” route creation is used.
Structural federation is clearly an “SDN” approach where functional federation is a legacy approach, so for SDN it should be important to get structural federation to work. There are some barriers, though; issues we need to watch for as vendors announce their approaches. One is service model coordination. Logically speaking, structural federation has to either work independent of the L2/L3 service that SDN is creating, or it has to “know” the constraints of the service to insure that its federation processes are compatible. Another is the security of the processes; federation is a good way of leaking bad information into SDN just like it is into IP. A third is performance and availability. The more layers of controller we have, the more have to be operating efficiently (and simply operating) in order for new flows to be accommodated.
Functional federation will likely serve the needs of SDN for some time, particularly because vendors are creating hybrid approaches of BGP, MPLS, and SDN to exploit the model. For SDN to meet its full potential in building new services with new forwarding rules, though, we’ll need a good structural approach. I think we’re making progress in that direction, but there’s still plenty of useful work that should, and could, be done.