Like most industry organizations, the Metro Ethernet Forum (www.metroethernetforum.org) was established to educate the industry on the benefits of its technology-in this case, Carrier Ethernet-and accelerate its adoption worldwide. But unlike other industry associations, the MEF is almost fanatical about testing. Its current test specifications, MEF 9 and 14, comprise 414 separate test cases that follow the standard line by line. More important, however, is the increased sophistication of MEF 14, in which the forum moves beyond simply testing function to testing actual service quality.
The MEF Certification Program was launched in April 2005, with Iometrix (www.iometrix.com) serving as the forum’s official certification lab. Vendor certification to MEF 9 began in September 2005, followed by service provider certification in April 2006. Vendor certification to MEF 14 was announced in June of this year, with service providers eligible in October. At press time, the MEF had certified 33 equipment manufacturers (representing more than 320 systems) and 14 service providers worldwide.
So why has the MEF plotted so aggressive a timeline, and why does Ethernet require more stringent testing than, say, legacy protocols? The MEF says it has several reasons for its bullishness on testing, not the least of which is to combat misconceptions in the industry.
Unlike Frame Relay or ATM, Ethernet had its beginnings in the LAN, explains Michael Tighe, chairman of the MEF and director of strategy and positioning for Verizon Business (www.verizonbusiness.com). “There was a perception in the industry that Ethernet was a best-effort service,” he says, “and we really wanted to change that perception because we felt like [Ethernet] was absolutely carrier-class and capable of running mission-critical applications.”
Iometrix president Robert Mandeville points to the MEF’s successful interoperability demonstrations as the genesis of the certification program. Interoperability demonstrations run only for a given length of time and typically do not cover all the special scenarios and exceptions inherent in any network installation.
“The thinking was, ‘We’ve worked really hard on our technical specifications. Why don’t we use those as a basis for developing a test suite and a test plan approved by the technical committee?’” he recalls, adding that the MEF took almost 2 years to complete the MEF 9 test requirements. “It really goes line by line through the specification and comes up with a requirement statement every time the specification lends itself to, ‘Therefore, this is required, this is required, and this is required,’” he explains. “Once we have the requirements in place, then we generate the test case to verify that this requirement is satisfied by the service in question.”In addition, says Tighe, standards often leave room for interpretation, which can account for as much as 10% to 20% of someone’s understanding of the standard, resulting in two or more vendors implementing different versions of the same standard. All the vendors may claim to be compliant, but they aren’t interoperable. “What we’ve done in the MEF by doing this testing is ensure a high level of interoperability from an equipment perspective,” he explains. “It gives us better capability to run a multivendor-type Ethernet network.”
Whereas the earlier MEF 9 Test Services Suite verified the function of equipment and services, the forum broke new ground with this year’s release of the MEF 14 Traffic Management specification, which tests service quality to ensure that Carrier Ethernet networks can support converged voice, video, and data services. “The MEF has really gone very, very far here by not only saying, ‘We have a certification program to verify the functionality of the services but also the quality of the service,’” explains Mandeville. “This is just straight out a revolution for the industry. I know of no other forum that has gone beyond function, and MEF takes it all the way through to verifying performance levels of services.”
In fact, vendors who take their equipment to the Iometrix lab for testing do not walk away with a certificate declaring the equipment certified, per se. “What it says, for example, is that we certify that an EPL [Ethernet Private Line] service, as delivered on such and such piece of equipment, complies with MEF specifications,” Mandeville explains. “We are, in fact, testing and certifying a service, and we’re doing that as delivered by equipment or as delivered commercially by a service provider.”
Developing the test cases for service testing hasn’t been easy, admits Mandeville. “MEF 14 raises the ante from a testing point of view because we have to shift from traditional ping-based measurements to one-way measurements with very high accuracy.” MEF 14 includes 183 test cases that can be applied to three different services: EPL and Ethernet Virtual Private Line (EVPL) point-to-point services and E-LAN multipoint-to-multipoint services. The test metrics themselves should look familiar, he says, as they include frame delay, frame delay variation, and frame loss ratio measurements.
What is new-and even revolutionary, to use Mandeville’s word-is the ability to conduct one-way measurements. Such measurements are more difficult to achieve because they require clock synchronization at both ends and more sophisticated time-stamping techniques. In fact, says Mandeville, they require “a measurement infrastructure. Because of the requirements for synchronization, the measurement points have to know each other, so there’s an underlying protocol at work.”
But such measurements are required to test real-time applications in the converged services world. For example, say a carrier is streaming IPTV traffic from its server to subscribers, and a subscriber complains of a delay. The carrier must be able to determine that the delay is, in fact, occurring on the downstream portion of the network; delay in the opposite direction is far less important. But, says Mandeville, “if you only had two-way measurements, there is no way you could ever nail that down. Real-time applications require one-to-one measurements, and that’s built into MEF 14.”
Despite all of its work on MEF 14, the forum’s test efforts are far from over. On the contrary, Mandeville says the amount of work yet to be done is “kind of scary.” The user-to-network interface (UNI), for example, is becoming increasingly more sophisticated. Technical specifications for UNI Type 1, which Mandeville says is the starting point in a relatively simple version of the UNI, are expected to go to letter ballot in January. UNI Type 2, by contrast, includes IEEE 802.3ah link layer operations, administration, and maintenance (OAM), as well as MEF 16, or ELMI, a specification that allows the service provider to remotely configure and run diagnostics on the customer box. “All of those specifications go into the UNI Type 2 specification, which is a strong candidate for certification,” says Mandeville.
However, he believes the “crowning achievement” of next year’s efforts will be a test specification for the external network-to-network interface (ENNI). In the Frame Relay or ATM worlds, carriers will purchase last-mile TDM circuits from each other to complete long-distance transmission links. But no such standard exists for Ethernet networks, says Tighe, who says that such a specification is “vital to grow the market.” The ENNI specification enables carriers to understand, recognize, and exchange information about the class of service associated with each service instance.
From a testing perspective, the ENNI presents several challenges. It includes information about OAM drawn from other specifications. And it addresses the issue of reliability. For example, if a main link between two providers goes down, what mechanism will be used to restore that link? “All of those elements are in the ENNI specification,” reports Mandeville, “so there is a requirement to develop test cases for all of those. Then it would be natural to suspect that they would become the object of a future extension of the certification program. So the roadmap is full.”
Meghan Fuller is senior editor at Lightwave.