MPLS: more interesting than you think

In a drafty warehouse south of the San Francisco Airport, the world's largest Multi-protocol Label Switching interoperability test just wrapped up. A joint project of the NetWorld+Interop's iLabs, the MPLS Forum and the University of New Hampshire Interoperability Lab, the testing brought together 22 vendors and 30 different MPLS platforms.

With more MPLS vendors in one room then ever before, more tests at the bleeding edge of MPLS standardization and the most sophisticated test plan for MPLS interoperability ever written, this was a one-of-a-kind event. More than $20 million worth of hardware, 50 MPLS engineers and testing speeds up to 10G bit/sec.

Advertisement:

In the iLabs area at NetWorld+Interop 2002 Las Vegas this week, attendees will be able to see some of the results of this testing, focusing on enterprise-oriented edge services, such as Layer 3 VPNs and Resource Reservation Protocol (RSVP) and Label Distribution Protocol (LDP) MPLS, and Layer 2 cross-connects. This may sound like alphabet soup, but these acronyms represent the value-added services such as private networking, resource reservation and multinetwork interconnect that MPLS service providers will be able to bring to corporations.

That said, most people in enterprise IT greet news of MPLS testing with a yawn. But really, there are four reasons why you should care.

1.) It's a trend. A testing commitment of this magnitude on the vendors' part demonstrates that MPLS is not just another buzzword, but represents a technology that carriers are buying and deploying today. As service providers start to push MPLS into their networks, network professionals will no longer have to build large WAN infrastructures.

Connecting up to the MPLS network can be as simple as another Ethernet drop.

One example of simpler connections for enterprises is spelled out in an Internet Engineering Task Force draft known as "Martini." Sixteen of the vendors in the iLabs test supported the Martini draft for Layer 2 cross-connect, the most likely candidate for enterprise Layer 2 MPLS connections. Eighty-five percent of these products interoperated with every other product in this particular test.

---

Additional iLabs analysis:

Down and dirty with Wireless LAN security
The skinny on iSCSI SANs

---

2.) It's safe. The danger with any new technology is that it will die because of lack of vendor support. More vendor involvement is a good thing, but more interoperable products from these vendors is even better. The results are more diverse product options, better prices and more differentiating features from which to choose.

The iLabs MPLS testing, in its seventh iteration, proves that MPLS is stable. New vendors come to learn and figure out whether they know what they're doing. Old vendors who claim to be market leaders show up to maintain their position in the industry.

Proven interoperability gives carriers the confidence to invest in MPLS. As more and more carriers build out their networks with MPLS services, enterprise managers know that it's safe to bet the company network on MPLS.

3.) It's good testing. The goal of the iLabs MPLS test is to make systems work better together. All the testing is multiproduct interoperability But pair-wise testing isn't enough. The iLabs team built a huge network with everyone's product talking to everyone else's product.

"We expected that if we tried to have all these vendors interoperate, we would have problems, " said Bill Jensen, an IT professional with the University of Wisconsin in Madison and the iLabs MPLS team leader. "But surprisingly, all the vendors managed to interoperate with at least half the other vendors -- and that was the worst case. No one had any blatant interoperability silliness," he said.

"I like to see issues, broken things. And I like to see them resolved," Jensen said. "The goal is not to post results; our goal is to improve the technology, the standards, the state of the industry."

One of the problems Jensen and his team found was differing interpretations of the value of an option called SENDER_TSPEC, which is used to specify bandwidth reservation. During the iLabs testing, vendors pinpointed the issue and solved it by agreeing on how to specify signaling values so they could interoperate. Another issue rising out of this exercise was the use of Address Messages in LDP, and the role of those messages play in some kinds of MPLS signaling. Before the iLabs testing, all vendors had not yet identified when to use Address Messages, which identify the two ends of an MPLS link. But because of this multivendor test bed, the participating companies gained a better understanding how and when to use Address Messages, which in turn increased interoperability.

In another connection test, some vendors used interface addresses (the address of the actual interface) and some used loopback addresses (an internal address used as a router identification in routing protocols). The testers discovered that using loopback addresses for router Ids is a powerful way to improve your odds of interoperability.

MPLS testing tally Testing goal: Test interoperability for Layer 2 cross-connect and Layer 3 VPN and RSVP services. Testing engineers: 10 Fact found: In the Layer 2 cross-connect test, 85% of the products tested were able to interoperate with the other products tested. Sport most resembling technology: Cricket -- a lot of flinging of balls around, and no one really understands the rules.

Testing at the iLabs in April focused on both resiliency of the network and handling failure cases. Resiliency testing looks at how network elements recover from problems. Within the core of an MPLS network, provisions in the protocols allow re-routing to occur if there are failures. This MPLS testing looked at how well products actually implemented both the standard protocols for rerouting and a new proposed-standard (usually called the Atlas draft, short for "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute") for fast rerouting in the case of failures. Failure testing looked at how well errors propagated so that end systems could make intelligent routing decisions.

As a simple example, one test verified that if a piece of the network between two MPLS switches goes down, that the end ports which are supported by that network also go down. That's important, because it shows that MPLS networks are able to signal network status information all the way from the core to the edge.

Of course, not every issue identified was resolved. For example, one MPLS signaling element called Reservation Style can be done in two ways, SE (Shared Explicit) or FF (Fixed Filter). Both are legal according to the standard. But the iLabs testing brought out different behaviors between these two implementations. "In this case, someone like the MPLS Forum or the IETF has to step in and put their foot down on just how to handle this," says Jensen.

It's cool. Most enterprise networks aren't going to need OC-192 links between data centers. But that doesn't mean the technology shouldn't exist. "You don't have to own a Ferrari to want to read about one," offers David Newman, a Network World Global Test Alliance member. Knowing these things exist offers a comfortable margin of error. If you have a 100 Mbps metropolitan Fast Ethernet connection between data centers, knowing that carriers could offer you something 100 times faster means that you won't have to worry about accommodating future growth.

MPLS at OC-48 (2.5 Gbps) and higher speeds also dramatically drops the price to connect to the network. Because the MPLS connection happens at Layer 2, much of the expense of the connection is pushed back onto the service provider. MPLS might make it possible to put in faster pipes at the same price---and that's indisputably cool.

MPLS testing is an on-going effort that will continue through this week's demonstration at Networld+Interop Las Vegas. More complete results will be available next month at www.ilabs.interop.net.

Hats off to supporting vendors

In general, the iLabs program depends on vendors stepping up to the plate, putting their products on the line to be tested in a public venue. But the unsung heroes are the vendors who offer their products and engineering expertise to provide the testing infrastructure.

Special thanks goes to Spirent Communications, which provided more than $1 million of network testing gear and analysis software; Fluke Networks, which donated its network connectivity analysis tools used in all three iLabs technology areas; and American Power Conversion, which basically powered the entire demonstration network.

You can find a complete list of supporting vendors at www.interop.net.

Snyder is a senior partner at Opus One, in Tucson, Ariz. He can be reached at joel.snyder@opus1.com.

Global Test Alliance

Snyder is also a member of the Network World Global Test Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Test Alliance information, including what it takes to become a member, go to www.nwfusion.com/alliance.

Variations on a VPN theme
A new breed of VPN based on Multi-protocol Label Switching is emerging as an alternative to traditional VPNs based on IP Security. Network World, 04/08/02.

The promised LAN
If you operate a private ATM campus network or metropolitan-area network, a Multi-protocol Label Switch Layer 2 VPN could be a cost-effective, high-speed alternative. Network World, 04/08/02.

Despite criticism, MPLS is here to stay
There has been a lot of discussion about whether Multi-protocol Label Switching is good or bad for the Internet. It's been called a social disease, something that should never be allowed on the 'Net, a disaster waiting to happen. Network World, 04/08/02.

MPLS Resource Center
The MPLS Resource Center provides a clearinghouse for information on Multiprotocol Label Switching.