MPLS Gets the Management Blues
Equipment vendors were slow to answer carriers' calls for OAM, and the Internet Engineering Task Force (IETF) even rejected early proposals to work on MPLS OAM. So the carriers took matters into their own hands last year, drafting standards with the International Telecommunication Union, Standardization Sector (ITU-T).
News of the ITU standards jolted equipment vendors into action, and they've begun submitting proposals with the IETF. But these standards are not using the ITU work as a base, so the schism persists between what carriers want and what vendors are planning.
"The work is pretty much done on the ITU side. Unfortunately, the IETF and the ITU don't see eye to eye on this," says Yaakov Stein, chief scientist for RAD Data Communications Ltd. "Carriers want carrier-grade operation, which means a lot of strong OAM. The IETF is not doing that."
The disparity stems from carriers' and vendors' differing goals for MPLS. "The major routing manufacturers don't see this as their major thrust," Stein says. "They still see [MPLS] as IP. Cisco still sees MPLS as an accelerator for IP."
The difference is critical, because the combination of IP and MPLS will play a major role in future networks. As noted in the report Resilience, Reliability, and OAM in Converged Networks: A Heavy Reading Competitive Analysis –- published in February by Heavy Reading, Light Reading's paid research group –- carriers and equipment vendors are preparing for a network that retains multiple protocols at the edge but transports them all over an IP/MPLS core (see Survey Explodes MPLS VPN Myths and Incumbents Converge on Convergence).
What the model lacks, according to carriers, is the management tools to track down problems quickly. An MPLS network could run just fine without OAM, but it could be harder to isolate faults, leading to higher operating expenses. "Without its own OAM protocols, the MPLS cloud simply looks opaque to any attempts to locate or debug a fault," says Geoff Bennett, chief technologist at Heavy Reading and author of the report.
One alternative is to build a parallel OAM "network that runs separately to the IP 'bearer channels' and usually emerges in the POPs on a terminal server," Bennett adds. This has its obvious disadvantages: "Terminal servers cost money, and you need to run a complex, parallel network just to manage the routers."
In fact, the IETF ignored OAM on its first pass at MPLS standards, although the issue was raised. That led carriers to take their case to ITU Study Group 13, resulting in the Y.1710 and Y.1711 standards, which set the OAM requirements and define the protocols, respectively. Another recommendation, Y.1712, deals with interworking between ATM OAM and MPLS OAM.
Seeing the ITU work emerge, multiple IETF factions took a swipe at MPLS OAM, drafting proposals such as LSP-PING, a descendant of the "ping" function in IP, and LSR Self Test, for detecting network failures.
Why didn't the vendors just do what the carriers asked in the first place? Stein, who has attended OAM meetings on the ITU and IETF sides, thinks it's a matter of following the money: Carriers remain slow to spend on new networks, making carrier requirements a less urgent investment.
"Carriers are saying, 'This is what we want, but we're not going to buy anything.' So, they're not being listened to," Stein says.
It would probably be best if the ITU and IETF efforts could be combined at this point, but it's anyone's guess as to whether that will happen.
"I'm seeing the IETF try to move, and I hope the ITU tries to move, too," says Sue Hares, chief technology officer of routing-software vendor NextHop Technologies Inc. "If we continue to squabble, the ISPs won't get their solution in time."
Bennett thinks a converged effort would be good, particularly since "some really good stuff" is coming from the IETF side. "The stupid thing was for a split to happen in the first place," he says. "I think vendors really need to listen more to their customers (the carriers). And carriers need to start getting together and speaking with one (or at least fewer) voices, so that their message is loud and clear."
— Craig Matsumoto, Senior Editor, Light Reading
For more about the challenges of building IP/MPLS networks, see these Webinars: