One of the frustrations of SDN has always been the fact that if you ask six different people for a definition of SDN, you’ll get ten different answers, at least. This stems in part from the usual IT buzzword symptoms. When a system is used for competitive advantage, each company wants to define its own brand of “The Thing”—to try to “own” the thing and become the de facto standard for it. There is also a deeper issue with SDN, precisely because it is networking.
When we talk about “the network,” we often think of one thing: one set of interconnected computers. Sometimes we think of the internet: of many interconnected networks. In reality, there are many different networks that even the smallest of companies use every day now. Each of these has different needs, different solutions, and different flavours of SDN. Add into that public and hybrid cloud, and we have many, many networks in use. Some of these we have control over, but many of them we don’t. However, that doesn’t mean that SDN isn’t playing its part.
The data center network is usually the flagship SDN platform, be that an underlay/overlay system like NSX (often with Cisco ACI as the underlay) which gives us massive flexibility in our data centers, and massive scalability. For most IT administrators, the data center network is the one we think of as “the network.” It is the one where the business gets done, and most of the connecting networks are either outsourced or much, much simpler in design.
On the other hand, the WAN connection usually hits a service provider network that is massively multi-tenant and of a scale that dwarfs most data centers. It wouldn’t be wrong to say that SDN started in the WAN space, with MPLS offering many of the functions that we use today to define SDN. There is a group of network administrators who saw this and brought the MPLS network right into the network and even into the servers. This let them take advantage of the SDN network on their doorstep and gave them total freedom between DCs. However, virtualization made this much more clunky to implement, and it fell by the wayside.
Our mobile communications are almost always offloaded—again to service providers—but this time they have a number of extra constraints on shared media between different providers and the need to work worldwide. On top of this, encryption becomes a much more complex problem, but also much more obviously necessary. NFV finds a real home here.
Wireless networks often look very much like a mixture of WAN and data center networks, with traffic flowing on an overlay that needs to be routed both locally, within a campus building, and sometimes “globally,” between different parts of a campus. Having the intelligence to switch and route where appropriate can make a huge difference to our WANs.
Finally, we can see our campus network. Where traditionally the traffic would all flow from the campus buildings to the data center, now applications are often peer to peer; routing that traffic back to a central point is neither necessary nor efficient. Using SDN to inspect the flows and route based on the traffic type is a main goal here, on top of the usual campus network priorities.
So, when we look at SDN, it is important to understand which of these networks we need to consider. Is our SDN local or distributed? Does it handle more east/west or north/south traffic? Do we need to build NFV, or are we simply interested in quickly constructing ephemeral, short-lived, but efficient tunnels between wide-ranging sites (either internal to our network, or external over a service provider’s secure network)? At what point do these different SDNs interact? Can they interact at the protocol level, or do they need to be instantiated into a “router,” be that a server, container, or actual router.
Of course, the really exciting future is the one where all of these networks begin to interconnect and interoperate. Where the One SDN to Rule Them All will appear is an interesting question. With each of these different types of network having such different priorities, getting the protocols that will define them to interact is not an easy task. The providers, of course, will all claim it is here, now, and ready to go. Please sign on the dotted line.