Some of you emailed me after my last blog to ask about the notion of “SDN domains” so I thought this would be a good time to take them up. First let me say that this is simply my own way of looking at SDN evolution; to my knowledge it’s not sanctioned officially by ONF or other bodies.
Data centers, especially cloud data centers, are logical examples of SDN domains. In fact, anything that could look like a Level 2 LAN is a logical example because these “subnetworks” are typically connected to the larger IP world through a default gateway. LAN addressing works inside them, but IP addressing works overall. This model could fit SDN handling nicely too. In fact, any Level-2-like network could be an SDN domain, and that offers what I think are the most significant expansions of the SDN opportunity space. There are two such areas; metro and branch office.
In the metro space, we have a classic example of a domain because the goal of metro networking is aggregation and not connection. Users don’t usually talk to each other, they talk with a point of presence for a higher-layer service. Their traffic is just backhauled/aggregated to those POPs. Since metro demands optical and electrical handling to complete a service connection, a logical goal for SDN is to smoosh them down into a single logical layer that can be managed at the path/route level and not by media type. Operators are enthralled with this mission and groping for a path to realize it.
In the branch space we see what might be the logical enterprise extension of the data-center-cloud concept of SDNs. Branches are also Level 2 networks in most case, and so the basic model of a domain with a default gateway fits there. But if you think about it, SDNs could partition branches into “functional domains”, by class of employee. That would align the domains with the applications each class of worker needs. If data centers (clouds) were similarly partitioned by application, you could then use a simple forwarding rule to link each application to the branches’ worker class domains. It changes the whole notion of security and networking.
Even in the Internet, as Google has shown, we can create SDN domains inside BGP routers as long as we can produce the edge conditions needed to interface with the rest of the IP world. That, in fact, is the most general of the SDN domain’s “general rules”. You have to fit an SDN domain into a service context, and so while inside the domain you can do what you like with SDN principles, at the border you have to look like an element in the service network you’re supporting.
I think that the SDN domain concept is critical for another reason; we need to make the cloud SDN-aware if SDNs are going to mean anything other than a way to commoditize hardware and reduce cost. Central control can bring service awareness and value, but only if you can link the “service” to the thing that’s being served, which is always going to be the application. My branch domain example illustrates that, I think. The OpenStack Quantum interface is “domain-aware” in a limited sense, and we need to expand the Quantum notion to embrace application and service domains. I don’t think that would be difficult to do at the technical level; somebody just has to publish some models and take some thought leadership positions.
So what could SDN domains do? They could create a “network”, including the Internet, that was made up of SDN domains acting as virtual devices. They could open the door to adopting SDN traffic handling and connection management on a wide scale. They could support today’s network protocols like IP, and also support future internetworking and network addressing mechanisms. It might be very smart to think about what SDN domains could now, as we’re on the cusp of moving the Internet to IPv6 and as we struggle to address some of the commercial issues arising from the evolution of OTT services, especially content.
Could SDN domains undermine current network vendors? Sure, but I think no more than any standards do. Operators’ Network Functions Virtualization initiatives are far more likely to impact network vendor sales/profits because they have the explicit goal of unloading network features from devices to servers to reduce costs. SDN goals of central control don’t necessarily demand that the devices are totally dumb, or that the central logic is open-source. There are still many paths to differentiate inside SDN domains…if vendors will look past their incumbencies to see them.