SDN Across the WAN, part deux. Primitives.
I’ve been lamenting about the SDN WAN options for a while now. Having SDN/OpenFlow in a data center or campus is relatively well documented and already widely deployed. Google has been doing SDN across their private WAN in production. These pieces are easy. What isn’t easy is the ability to plumb SDN across many domains that are under disparate control. This part is hard. What is lacking is a fundamental framework, or set of primitives to build from. As an example, how does one build a SDN path across this:
First I think we need to define what we want out of the SDN path. A reserved bandwidth allocation? A Layer2 path? Flow instantiation across the entire path? The first two have a least common denominator. The third is hard, especially if the path transits a segment with no SDN capability.
This piece is making my brain hurt. There seems to be a lot of early work on this, Inder Monga from ESnet has been working at making this happen, and I think he’s the closest from what I’ve seen in my searching and researching. I want to know how to do this across all networks. I want to see the future of carrier WAN connectivity, to taste the unicorn milk.
The methodology so far has been to break this down into small black boxes. After doing that, I realized that there is going to have to be a common protocol. The least common denominator to all of this is the SDN. It doesn’t much matter what that SDN is as long as there is a central controller. It can be OpenFlow, OSCARS, GMPLS, Open LightPath Exchange, whatever. It doesn’t matter. They all need a controller. Within those controllers there needs to be “an energy field created by all SDN. It surrounds us and penetrates us; it binds the galaxy together”. Yes, I like Star Wars.
So, how would one do this? It would be ideal, to me at least, if there was a standard set of protocols that all of these controllers could speak. This standard communication could be as simple as how a BGP peering functions. Site A has a controller, it “peers” with it’s upstream and announces its capabilities.
For example,
All of these peers exchange capability information and pass it on with a standardized set of language and a location identifier (think ASN and route announcements). To me this appears to be the lowest hanging fruit. I’m not a developer but there doesn’t seem to be to be any reason that this couldn’t be built into any controller, commercial or opensource. That way, regardless of vendor, SDN implementation or capabilities everyone can create a SDN path based on the available implementations upstream. Of course, there would need to be a “multihop” option for those that have to upstream SDN paths. In this case something like a GRE tunnel could be the lowest common denominator. This would have to transcend OpenFlow and be a true “SDN” at the fundamental level to actually work, but it needs to take into account managing the flow table of networks outside of a given administrative domain. As a starting point, here is the framework I came up with:
- Reliable transport: TCP
- Authentication method: MD5 Capabilities exchanged:
- Number of circuits
- Types of SDN (MPLS, VLAN, DWDM Waves, OpenFlow Version, Flow manipulation)
- Bandwidth per circuit (if applicable)
- Duration of circuit or flow (path TTL, permanent?)
- Path validation (to ensure end to end connectivity over negotiated methodology)