End-to-end Ethernet testing matures

0801lwe Fuller

As you might expect from a predominantly LAN-based technology that has migrated into the WAN, Ethernet has suffered from a relative lack of standardisation when it comes to test approaches in carrier networks. Until recently, vendors and service providers used proprietary test methods to monitor network performance and verify service-level agreements (SLAs). In an attempt to solidify Ethernet as a carrier-grade transport technology—i.e., to render its reliability more easily quantifiable, à la SONET/SDH and TDM—a number of standards and de facto standards have emerged, and this has opened up new opportunities for test equipment vendors. There’s even talk of integrating some of these test capabilities into the network interface device (NID), though there appears to be a lack of consensus on the wisdom of this level of integration.

The demarcation point between a customer and a service provider or between two service providers is “just another way of enabling Ethernet to act like SONET or TDM,” in the words of Mirna Mekic, product line manager of metro Ethernet at JDSU (www.jdsu.com). This demarcation point provides a definite separation between end-user and provider networks, and it is here that such test methodologies as the IETF’s 2544, the IEEE’s 802.1ag, and the ITU-T’s Y.1731 come into play.

The IETF’s RFC 2544 is not a standard—it is a request for comment—nor is it new. Nine years in the making, the series of performance tests that compose RFC 2544 was completed in 1999, but its popularity has recently grown.

Peter Schweiger, business development engineer in Agilent Technologies’ (www.agilent.com) Photonic Measurement Division, cites three key reasons why his company’s customers have embraced RFC 2544 as of late. First, he says, there is simply more Ethernet out there than there had been just a few years ago. Second, speeds are increasing, which means there’s a bit more at stake. A T1 is easy to quantify and readily understood, but an Ethernet service is best effort—and more expensive to boot.

“People want to know, ‘Are you really giving me what you say you’re giving me?’” explains Schweiger. “And the third thing is customers now have access to this information, understand this type of testing, and are now demanding it.”

Michael Stoos, director of business development in Spirent’s (www.spirent.com) Service Assurance Division, confirms that he too has seen an increase in the use of RFC 2544 in the field. Actually, he says, today it is “asked for quite readily. What’s happening now is during some provisioning testing, they are requiring 2544 not to the level of the whole line but to the level of the individual services.”

There are four tests within RFC 2544 that are most applicable to the field. The first measures throughput or the bandwidth capacity of the pipe. The second measures the delay or latency of the link, which is critical for the delivery of VoIP and IPTV services. The third test measures frame loss to determine if a given Ethernet frame arrived at its destination or if it was dropped. And the fourth test—which is a bit more “exotic,” says Schweiger—is known as back-to-back. This test entails “sending frames as fast as you can possibly send them to see when the network hiccoughs,” he explains.

Both the IEEE’s 802.1ag and the ITU-T’s Y.1731 fall under the category of Ethernet operations, administration, and maintenance (E-OAM). Commonly referred to as “Ethernet Connectivity Fault Management (E-CFM),” 802.1ag is used to isolate the point of failure in multiple-carrier networks. A subset of 802.1ag, Y.1731 provides all the E-CFM capabilities, plus performance monitoring features, including frame loss measurement, frame loss delay, and throughput measurement.

The Metro Ethernet Forum (www.metroethernetforum.org) also has defined a series of tests. “The MEF is kind of coming in between [the IEEE and ITU-T] and trying to bring things together to provide, in a sense, a best-practices recommendation or guideline for what should be used and how it should be used,” adds Stoos.

Hand-in-hand with the implementation of the standards mentioned and de facto standards is the maturation of the demarcation device market. “We have seen incredible growth in this space,” says Stoos. “Every place you see a provider-to-provider handoff, you’re seeing either UNI [user network interface] or NNI [network-to-network interface] devices becoming more apparent.” Although the market is awaiting the NNI standard, he says, “You’re seeing vendors like Spirent interacting with the NID or UNI/NNI provider to enable them to isolate issues as quickly as possible.”

JDSU also reports interaction with the NID vendor community. Mekic points to an existing partnership with Accedian Networks (www.accedian.com) as proof that test vendors and network element manufacturers (NEMs) can develop mutually beneficial relationships. Accedian’s EtherNID creates a demarcation point up to which Ethernet services can be performance-tested and verified. Per the agreement, the EtherNID interoperates with JDSU’s metro Ethernet testing portfolio, which has a two-fold benefit: The interoperability lowers overall deployment costs and ensures that SLA parameters, such as latency, jitter, and packet loss, are met.

Some advocate taking that relationship beyond simply interoperating. In an article written for Lightwave Online, Manu Kaycee, vice president of product technology and strategy at Telco Systems (www.telco.com), argues that intrusive, external test heads “simply aren’t up to the challenge.” Instead, he advocates embedding test-head functions into the access devices themselves. “RFC 2544-compliant embedded test functions could supply the clear and accurate view needed for effective Ethernet services that cross multiple networks and use multiple protocols and transport methods via equipment supplied by multiple vendors,” he says. (See Kaycee’s article, “Establishing Edge-to-edge Ethernet Service-level Verification,” in the Features section at www.lightwaveonline.com.)

Schweiger confirms that network equipment manufacturers (NEMs) have talked to Agilent about this level of integration. “I think that’s certainly the future,” he contends. “It’s very expensive to dispatch test equipment and people to do testing. If you can put a product in a loopback mode or get diagnostics out of it—network equipment manufacturers have promised this ever since they made network equipment. ‘You won’t need test equipment if you buy our product.’” But, he adds, “Agilent still exists.”

Mekic says none of JDSU’s customers have yet undertaken this level of integration. She surmises their hesitation could be “the fact that they want to keep the costs separate or they realise that the test and measurement piece is usually only about 2% of all the network element spending.” She also believes NEMs may want to continue external testing because it affords them the opportunity to ask the test vendor for customisation. Test and measurement is not an NEM’s core competency, “so they may deprioritise it or not prioritise it correctly,” she says.

That said, Mekic says she can see the potential benefit of integrating, say, 802.1ag testing into a NID. “If the link goes down between the NIU [network interface unit or NID] and the service providers’ network element, [the NIUs] should be able to send alarms upstream to the elements to let them know that the link has been broken, that an issue has occurred, and a technician should be dispatched to fix this,” she explains.

Meghan Fuller Hanna is senior editor at Lightwave.

More in Packet Transport