The Internet's leading standards bodies have joined forces to clarify a set of next-generation network transport specifications that critics warned could cause massive interoperability problems for service providers.

The Internet Engineering Task Force (IETF) and the International Telecommunication Union (ITU) formed a joint working group in February to reconsider a special transport network architecture the ITU is developing for MPLS traffic.

Dubbed T-MPLS, the ITU specification would allow MPLS to run over an Ethernet backbone. It would work as an interim layer between Ethernet and MPLS, and carry only MPLS traffic.

The joint working group - the first ever formed by the IETF and ITU - hopes to settle a rare, public spat that developed between the two standards bodies last year after the IETF charged that T-MPLS was incompatible with the existing MPLS standards.

IETF experts warned the ITU that its T-MPLS specification would not work with the billions of dollars in routers and switches that carriers have installed in recent years based on the IETF's MPLS standards.

If left unchanged, T-MPLS would cause "a major train wreck" with MPLS, said Stewart Bryant, IETF liaison to the ITU-T on MPLS issues and a technical leader at Cisco. At an IETF meeting last July, Bryant called the T-MPLS situation "catastrophic."

Now the IETF and ITU are formally teaming up to try to avert this.

"The T-MPLS train is still rolling, and it's yet to be determined whether or not the train wreck is averted. But to keep the analogy going, we've found the train's controls: the gas pedal and the brake pedal. Before, we didn't know where the brakes were," says David Ward, one of the directors of the IETF's routing area who will serve as co-chair of the Ad Hoc Group on T-MPLS. Ward is a Fellow with Cisco.

The ITU's Telecommunication Standardization Sector, known as ITU-T, established the Ad Hoc Group on T-MPLS on February 11 at the plenary meeting of its Study Group 15. The joint working group is the formalization of a plan that the IETF and ITU-T announced last September to try to work together on T-MPLS.

The Ad Hoc Group on T-MPLS consists of around 70 network engineers from leading network equipment vendors including Cisco, Nortel, Alcatel-Lucent, Fujitsu, Huawei, Zte and Ericsson.

"The goal of the group is to clarify the differences and similarities between MPLS and T-MPLS and to make a recommendation to the ITU-T management about whether to go with Option 1, which is to make the two technologies completely consistent and compatible, or to go with Option 2, which is to declare them different and therefore change the name of T-MPLS and have different codepoints," explains Malcolm Betts, chairman of the ITU working group developing T-MPLS and the other co-chair of the Ad Hoc Group on T-MPLS. Betts is a network engineer with Nortel Networks.

Betts says the Ad Hoc Group on T-MPLS will make a recommendation to the ITU-T to go with Option 1 or Option 2 by the end of April.

Both Betts and Ward say members of the Ad Hoc Group are optimistic that they can make T-MPLS and MPLS interoperable.

"The group is leaning toward Option 1," Betts says. "It would be a technical roadblock that forced us into Option 2, and so far we haven't found one."

"As of this week, everybody is working to Option 1, and we haven't found any showstoppers," Ward says.

Whether it goes with Option 1 or Option 2, the Ad Hoc Group on T-MPLS is expected to complete its work by September 2009.

"The IETF and the ITU have worked quite extensively in the past, but this is the first time things got so publicly heated that we needed to have a special group to focus on it," Betts admits.

The ITU-T has been developing T-MPLS for two years, and it was almost done with the specification last year when the IETF sent a strongly worded letter to the director of the ITU outlining its concerns about T-MPLS.

The IETF says the problem is that T-MPLS uses the same EtherType as MPLS, which will lead to confusion in operational networks. An EtherType is a field in the Ethernet networking standard that indicates which protocol is being transported.