At its quarterly meeting this month in Portland, OR, the Metro Ethernet Forum (MEF) expects to put its first test specification to letter ballot; once approved, it should become official in 30 days. While the test specification represents a significant step forward in metro Ethernet services testing, the real work has only just begun.
"There's a veritable revolution going on, because never before has Ethernet been bought or sold as a service," explains Bob Mandeville, president of Iometrix and editor of the MEF's test specification. "That's the new challenge. No one knows how to test services; that's a whole new ballgame. What elements are you looking for? How do you put the tests together? And what is a service, anyway?"
These are the questions the MEF seeks to answer. In its first technical specification, MEF 1, the forum members defined Ethernet services (see Standards Watch, p. 14). The new test specification follows MEF 1 paragraph by paragraph, sentence by sentence, and creates a new paradigm for service testing.
The old test paradigm "of sending an Ethernet packet at a device and then counting that packet to determine the delay or if the packet is lost" is no longer sufficient for testing complex metro networks, reports Rick Pearson, marketing manager of the computer and networking solutions group at Agilent Technologies (Palo Alto, CA). "That doesn't really correlate to 'How do I know if my Ethernet QoS [quality of service] is meeting the SLA [service-level agreement]?' Just knowing that the device dropped a packet—it's hard to turn that into 'In the field, you can build a whole metro network of services out of this and satisfy your customers,'" he contends.
Compounding the problem is the fact that Ethernet in the LAN has always been best effort, which is fine for enterprise customers, but service providers require five-nines availability and always-on service for voice and eventually data. "In order to provide reliable service from the service provider to the enterprise, the network must protect itself from failure," explains Mark Fishburn, chairman of the MEF and vice president of technical strategy at Spirent Communications (Rockville, MD). "It must be able to handle fail-over, to reconfigure itself in a manner that is seamless to the user, and it must be manageable. None of these functions is native or inherent to Ethernet."
What makes Ethernet so attractive is its flexibility; it can be made to resemble existing legacy WAN services. There's an Ethernet version of leased-line services, transparent LAN services, Frame Relay services, and ATM services. But how do you test the Ethernet version to ensure that it meets the same QoS as its legacy counterpart?
The answer is a new class of test standards and equipment that will "enable you to do complex traffic shaping and simulate the use of thousands of users on the same network interface," asserts Fishburn. What is required, he says, is a shift away from testing boxes to testing systems that likely include several different vendors' equipment. "You need to represent the way in which the users are going to use the system. It's different than testing the bits and bytes," he notes. "It's really testing how the performance of one user and its demands on the system may affect the other users and how a consistent service can be provided."
As MEF members draft their test specifications, they must also take into account the unique architecture of metro networks. In a recent study, "Service Provider Plans for Metro Optical and Ethernet," analysts at Infonetics Research (San Jose, CA) interviewed 27 service providers in North America, Europe, and Asia-Pacific about their plans to deliver Ethernet services. They discovered that the majority of service providers plan to deliver Ethernet services over more than one architecture. Next year, for example, 74% plan to deliver services over CWDM/DWDM, 67% over IP/MPLS, 63% over SONET/SDH, and 44% over resilient packet ring—and 52% say they will deploy a separate metro Ethernet overlay network. "The key message here," says Pearson, "is that service providers are going to deliver Ethernet services, and they're going to deliver them in different ways. From a test perspective, the underlying physical structure is now an independent variable."
The MEF recently ratified technical specification MEF 4: Metro Ethernet Network Architectures Framework, and a test specification should follow.
According to Mandeville, it's "highly likely" that one of the next test specifications will closely follow MEF 5: Ethernet Traffic Management Specifications, "which is essentially QoS, or how can we get nice clean voice over the same lines and interfaces through which we're driving huge amounts of data?" Other specifications will follow.
For now, test equipment vendors "are at the mercy of whatever the different kinds of users are doing today," admits Fishburn. "Every service provider that comes to us is going to have different requirements. We will put together a system that either maps onto their existing legacy systems, or we will provide a pure Ethernet testbed for them. They may want to test conformance to the new standards, which they are now specifying in their RFIs, or they may want to do performance testing."
At SuperComm in June, Agilent unveiled a new test platform designed to suit the myriad requirements of its service-provider customers. Dubbed the N2X, the multiservice tester emulates an end-to-end connection from an enterprise through the metro to the core network to determine the network's ability to deliver service per the MEF standard. According to Agilent, the N2X represents the kind of next-generation equipment required to test QoS in the metro Ethernet network.
"Before now, the state-of-the-art in testing was 'I leave Ethernet alone and I test SONET. I leave SONET alone and I test Ethernet,'" explains Pearson. "And when I'm testing SONET and I'm looking at Ethernet traffic, I generally walk over and pull the fiber connector out, drop the service, and then I plug it back in. But what a Ciena CoreDirector or a Cisco 15454 does with the transport structures is so much more sophisticated that if all you're doing is breaking the fiber and seeing if it works, you're missing all the detail of the protection and restoration schemes."