OAM

At the Packet Transport Networks Conference in Milan Italy in July 2010, an ITU-T delegate Huub van Helvoort, said that there had been no progress with the standardization of MPLS-TP since the April 2009 PTN meeting. No doubt many delegates were scratching their heads wondering why standardizing MPLS-TP has proven to be so complicated. The answer is OAM.

Packet Transport Networks move packet technologies into the transport domain. And transport and packet have traditionally focused on different network functions. The IETF has historically focused on layer 3 protocols like IP, and MPLS, a layer 2.5 technology. ITU-T has focused on technologies that operate at layer 1 and 2. Layering is a basic principle of the relationship between these protocols. A requirement of the transport network is transparency - the higher layer services that are transmitted over the transport infrastructure must arrive 'exactly' the same as they were when they were transmitted. Transparency includes both data and timing integrity.

This brings us back to OAM. OAM's function is to identify and isolate faults. More important its role is to continuously and proactively verify compliance. A transport person would say, "Isn't that the same thing?". And of course, in transport OAM the answer would be, "Yes - If there are no faults then the service is compliant."

Transport requires a level of OAM that has until now not been necessary in the packet layer. Packet OAM has relied on reactive tools like Ping and TraceRoute, and statistical monitoring like NetMon and SMon. This has been sufficient because the packet layer has been supported by the transport grade OAM provided by SONET, SDH or ATM. It's these lower layers that have reported physical network failures and supported protection switching. This difference is the cause of a lot of misunderstanding.

It's kind of obvious, but OAM should be capable of verifying the SLA commitments for the most stringent payload. When traffic is aggregated, the resulting aggregate inherits the most stringent client OAM requirement; and that therefore OAM will be more strict at the lower layers in the stack.

A related problem is that the performance and fault management OAM that is used in transport networking must be supported by sophisticated management tools (like Cyan's CyMS). These types of management and operations support tools have not been part of IP / MPLS networking solutions.

A true packet transport solution must be able to guarantee data transparency, including latency and loss. This requires monitoring of every packet. And to meet the scale requirements, the OAM must be implemented in hardware, backed up by sophisticated software. Properly functioning OAM allows you flexibility. You can ship the packet service anywhere, over any lower layer technology, including DWDM and OTN. If the OAM is good, then the packets are good too.

In a recent blog http://acgresearch.net/blogs/50.aspx, Eve Griliches of ACG Research expresses frustration that everyone can't just get along. It's not that easy. The IETF and ITU-T are trying to resolve a contradiction. Can a solution really be simple to implement and also scale to support granular parameters over tens of thousands services? Is it possible to verify performance without a management system that provides visibility and control?

It seems that eventually and inevitably the answer will be that there will be two MPLS OAM standards - one that follows the Ethernet and T-MPLS OAM standards, and one that follows the IP/MPLS view. There will be two alternative MPLS-TP implementations. Chip and system vendors may need to support both, adding to cost and to implementation complexity. And carriers and service providers will have to gamble on the long term market success of the variant they choose for their networks.

The good news is that the IEEE and ITU-T have standardized OAM for Ethernet services. These OAM protocols are supported by the MEF too, so Ethernet service delivery requires the use of these OAM protocols. There is no disagreement about these standards. Carriers and customers can rely on these OAM standards to not only find the faults, but to continuously and proactively verify compliance with the SLA. And these OAM standards are good both for individual services, and for transport aggregates that are multiplexed using Connection Oriented Ethernet. MEF compliant Ethernet services can be delivered using standard Ethernet technology today.