Trying to put its stamp on the new world of virtualized networks, the Metro Ethernet Forum (MEF) is launching a new project to solidify network-as-a-service (NaaS) specifications between carriers.

The NaaS initiative, being announced today, gives the MEF a new mission that's not coincidentally infused with the hipness of software-defined networking (SDN) and network virtualization. One major difference from most efforts is that the MEF will be targeting the wide-area network rather than the data center.

That fits the organization's character. The MEF was founded in 2001 to standardize Carrier Ethernet services — specifically, to formalize the ways in which carriers connect to one another's networks. That way, carriers could use each other's networks to reach customers around the globe, and each carrier had the same vocabulary when it comes to types of Ethernet services and to specifics such as bandwidth levels and quality-of-service.

In a sense, Carrier Ethernet isn't about the network. It's about being able to arbitrarily combine networks to create Ethernet connections between arbitrary points. And much of the MEF's work focused on ironing out the business details behind those connections.

The NaaS initiative plays in the same wide-area milieu, but it's more about spinning up a spontaneous virtual network, one that's too ephemeral for Carrier Ethernet to accommodate. A simple example is an enterprise where some employees work remotely and some are traveling. To get them all onto a videoconferencing call, you'd have to have many of them connect through best-effort VPNs across the Internet. The NaaS alternative has all of them plugging into a network that looks and performs like a private LAN (and gets paid for, of course).

“You can do some of this stuff in the data center today, but outside the data center, it's more than one vendor. And once you go multivendor, all bets are off,” says Ralph Santitoro, a longtime MEF board member from Fujistu Network Communications.

“NaaS” isn't a term unique to the MEF, and the services it refers to are already being sold by companies like Pertino. But as it did with Carrier Ethernet, the MEF is taking a global view, in a literal sense. The goal is to make it easier for carriers to deliver these ad-hoc networks anywhere, preferably using one another's networks rather than the Internet (because otherwise, customers wouldn't have much reason to pay for the results).

As with Carrier Ethernet, the work will lie in picking through the nuts and bolts that make it possible — and in specifying the business relationships among the carriers involved.

“SDN handles a lot of these things, but you can't just rip out everything, put in an SDN controller, and hope for miracles,” Santitoro says.

There's another, more limiting, similarity to Carrier Ethernet: The MEF's NaaSes will be Ethernet-based at first. While the MEF acknowledges that IP and optical networks could also benefit from ubiquitous NaaS standards, the group is going to stick to the familiar ground of Ethernet services first.

Still, the MEF's move into NaaS isn't that far-fetched. Carrier Ethernet services are nearly ubiquitous but lack flexibility; they still take time to set up and have to fit within the MEF's parameters. The NaaS project aims for networks that are more immediate and ephemeral. You could interpret it as a bid to keep Carrier Ethernet relevant as the best-effort Internet continues to improve.

The NaaS initiative is being aided by one particular carrier that's trying to implement these ideas. That carrier didn't initiate the MEF's NaaS plan, but it's contributing its work-in-progress to the cause. “They want to get it standardized across the board, because it makes their life easier with all the carriers they have to deal with,” Santitoro says.

A central element of the MEF's NaaS will be a life-cycle orchestration layer that would use APIs to talk to the element management systems (EMS) in WAN equipment. This layer would tell networks how to react in order to create the NaaS service.

The key is that this orchestration layer would work across multiple service providers' networks. What makes this NaaS idea difficult today is the lack of an abstraction layer that works across multiple operators or even across silos within on service provider's network, MEF chairman Nan Chen says.

This could also work in a network functions virtualization (NFV) environment. The orchestration layer could talk to a virtual network function (VNF) manager or orchestrator, which could build the necessary service chains.

The most important piece of all this, in a sense, is that the orchestration instructions would also be communicated to a billing system, so it could start and stop charging as the NaaS gets created and destroyed.

To get all this done, the MEF will have to develop an information model to represent the services. The work here has begun, and the group hopes that the results can be used as a common starting point for any other NaaS efforts that emerge in the industry.

MEF intends to work with pretty much every standards organization in SDN, NFV, and telecom networking — not just to enlist help, but to double-check that no one else is already doing it, Chen says. Talks with the ETSI NFV group have already started, Chen says, but collaborations with SDN-focused groups — the OpenDaylight Project and the Open Networking Foundation (ONF) in particular — are still at the “Hi, how are you?” stage.

Some of the APIs have been developed, and one carrier is even deploying them into its network, Santitoro says. But that's only a start; in terms of the journey toward an MEF NaaS, it's the equivalent of opening the front door before stepping outside.