The CloudEthernet Forum wants to develop standards for cloud services, but it’s not going to do it the usual way. Rather than wait for years-long standards tracks, the CEF wants to take a software approach of iterative development: Throw something in the pond, and tweak it (or apply CPR) if it sinks.
It’s a very DevOps alternative to the standards process, and the reason for it is obvious: It’s the norm for the cloud providers that the CEF purports to serve.
Those operators’ change cycles are quick and fluid. “There is no reason why you couldn’t do standards in a similar way,” says James Walker, president of the CEF and vice president of managed networked services at service provider Tata Communications.
The CEF isn’t trying to define the entire cloud ecosystem. It’s focusing on the interfaces between networks, the junctures where one provider might have to hand off a service to another provider.
These handoffs happen because networks’ reaches are limited; even Tata, which has a fiber-optic network that literally spans the globe, can’t be everywhere. To deliver a service, carriers often have to hand off traffic to one another.
The CEF has been working on this for about a year. This week, it’s announcing that a reference architecture for cloud services — mapping the different interfaces that need standardizing — is just about ready for a formal vote, which should occur in November. Meanwhile, the CEF and the like-minded Metro Ethernet Forum (MEF) have created the OpenCloud Project to build a test bed for these standards.
All three were approached last year. “They said, ‘Do you know how many people ask us to join their club every year?'” Walker says. The big cloud providers wanted the CEF to show heft and presence. With Cisco having joined two months ago, the group might have reached the right thresholds; ninety percent of the switching market is now represented in the CEF’s member ranks, Walker says.
The cloud providers’ other criterion: The CEF had to match the rapid product cycles of the cloud. Hence, the iterative approach, rather than formal standards.
Don’t Fragment the Cloud
The concern of CEF members — a group that includes vendors as well as major service providers such as Tata and Verizon — is that if none of this work gets done, cloud services will fragment. It’s better for the market if all networks know how to handle all cloud services — if there’s a common language, in other words, that lets these services merge onto the same roads.
That was the logic behind creating the MEF. Carrier Ethernet services often have to traverse multiple networks to get to their destinations, and service providers had been negotiating agreements for those connections one by one. By standardizing those interfaces and setting definitions for types of Ethernet services, the MEF saved the industry a lot of work and, the group claims, helped foster the growth of Carrier Ethernet.
That’s what the CloudEthernet Forum wants to do with cloud services. The group’s scope does extend beyond purely Ethernet — IP networking is definitely in its sights, for instance — but Ethernet seemed the right place to start, due to its ubiquity, Walker says.
The interfaces the CEF aims to standardize would cover the connections between networks and/or data centers. Access network to cloud, enterprise to data center, data center to data center — all the combinations you can stand to type. “What we’re looking to do is standardize and therefore simplify all of these various interfaces,” Walker says.
The CEF’s work might also make it easier for enterprises to deal with their cloud providers. Enterprises “just want to buy services from us programmatically,” Walker says, in the context of his job at Tata. “How you talk to a service provider, as an enterprise is already a complicated task” and gets more complex in cases where services traverse multiple providers’ networks.
The CEF faces a harder job than the MEF did. Whereas the MEF could borrow from IEEE standards, the CEF is exploring terra incognita, a landscape that’s going to be defined by SDN and NFV in ways that can’t yet be anticipated.
The OpenCloud Project’s test bed will be hosted in South San Francisco, with tendrils reaching into some members’ facilities, running traffic on combinations of real and emulated data centers. All of the networks involved will be live, production networks. The test bed is still in the design phase; no physical gear has been hooked up for it yet, but that’s coming soon, says Bob Mandeville, president of testing and certification company Iometrix and the head of the OpenCloud test lab.