A Private Extranet for Cloud Computing

The Automobile Network Exchange Provides a Good Example of the Networking Needed for Cloud Computing

Over the last few weeks I discussed some of the network issues I foresee dealing with Cloud Computing:

• Networking in the (Storm) Clouds
• Networking in the (Thunder) Clouds
• It's Really Only Partly Cloudy Out There

The underlying cause of many of these problems in the expected transport network most enterprises will use to reach cloud services: the Internet. It lacks QoS, there are bandwidth constraints, inefficient routing, and it requires public IPv4 space. Oh, and there's that whole security thing to deal with.

What Cloud Computing needs is an alternative (note, not a "replacement") for Internet transport. As a service differentiator, Cloud Computing companies could offer private network connectivity to their services which would have QoS, private addressing, and enhanced security.

When I worked years ago in network operations at AT&T, my team managed General Motors' (GM) global WAN (a heck of a great experience...it saddens me to see what has happened to GM....but that's a story for another time). Part of this outsourcing arrangement included managing GM's connection to the Automobile Network Exchange (ANX) extranet. According to Wikipedia, ANX is a...private network or extranet...built as a private network for the auto industry in 1995 to provide consistent, reliable speed and guaranteed security for data transmissions between the automakers and their suppliers. Today, there are over 4,000 companies connected to ANX. This connection allowed GM to privately and securely exchange orders with suppliers.

This same concept could be extended to Cloud Computing (let's call this new network "CCNX" for now). An industry consortium of MPLS providers would setup a cloud environment that would allow individual VPN customers to directly access the CCNX. This would allow cloud computing providers to exist as just another site on the enterprise's VPN regardless of the MPLS carrier they use (Verizon, AT&T, BT, or any of the smaller providers). There would be no need to bring all traffic back to a hub site and then out another circuit to the CCNX; it would be a natural part of a customer's VPN.

I won't try to delve into all the MPLS details, but essentially exchanging route-targets along with unique route-distinguishers should do it (I'm sure someone will reply telling me I'm wrong, but that general concept should get us there). IP address differentiation at the cloud provider will be a tough part when MPLS tags are stripped by the carriers, but perhaps a CSC concept could be employed? This is not something that a few smart engineers couldn't figure out.

With this model enterprise customers get a fast connection directly off their private MPLS VPN to their cloud provider. MPLS providers and Cloud Computing companies can own the CCNX as a consortium or sell it to a third party to manage. With a standard QoS model, a bandwidth charging mechanism, and sufficient global peering points between partner carriers and the CCNX, we would have a great private extranet for cloud services that could be a huge service differentiator.

Now, were is that phone number for that venture capitalist I met last month????

More >From the Field blog entries:

It's Really Only Partly Cloudy Out There

Networking in the (Thunder) Clouds

Networking in the (Storm) Clouds

How to Save Some $$$s - Keep Competition in Your Network

You Knew I Had to Comment on the Cisco Certified Architect Program

Happy 2-Year Anniversary - A Reminder to Focus on What's Really Important in Network Engineering

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

• ANX
• carriers
• cloud computing
• MPLS
• VPN