The Future of Cloud Data Center Networking

Jason Corollary: “Impossible” exists only because we haven’t stated or re-factored the problem so it is “possible.”

I have thought for the last few years that in virtualized and larger density data centers (a PDF link) there has to be a better solution than MAC and IP.

IP is challenged by having location embedded in the address. Not good for a world that wants to be able to move “cloudy” workloads across compute nodes, PODs, and data centers. One solution I’ve seen is to late binding on this IP layer but session state becomes tied and unable to migrate without loss. And let’s not mention the oversubscription issues happening in most of these topologies today.

I’ve also (see my earlier posts) never liked the complexity of managing switches. With SDN we basically could take a switch out of the box and configure a couple things and be good to go. Now companies are linking virtualization management with switch management, dealing with some complexity around this aspect but still route configuration in a non-layer 2 “flat” network is managed by admins.

Today, I enjoyed listing to a talk about PortLand (targeting 100,000 nodes and 1m VMs, full BW to each node), a UCSD project (with a great Itunes U talk) to provide a self-managing, scale out networking layer 2 design. The build in parallel from some of work happening on TRILL and others around some of these issues. But I like their design a bit better — don’t assume global host address space, assume a multi-routed tree (see corollary above.) It assumes a level of backwards compatibility — critical for widespread adoption.

They have created a simple protocol that seems to make well to the modular world of the data center future. — Location Discovery Protocol implemented in the rather simple layer 2 switching fabric. There’s also a fabric manager — necessary to maintain some level of backwards compatibility and management of the MAC mappings without changing protocols. Forwarding in the topology is done completely at this “pseudo” mac layer. This is created dynamically, hierarchically, addressing the global addressing (l2) and memory constraints that some of the other solutions in this space seem to be facing.

Looks promising!! Would like to see more work around latency, without the assumption of internet connected services. The PortLand work does address dynamic hierarchy, where as if more intelligent proximity (or P2P) based data stores etc could be used it might address the latency within POD vs outside, etc. All that is stored at the pMAC level.

Even love some of the “self-integrity” monitoring by neighboring switches like we thought about for Project OpenSolarisDSC. Wonder how we can help them with their fabric manager?? Hmm…thinking…

Advertisements

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: