THE CONTROVERSY OVER THE MULTIPROTOCOL LABEL SWITCHING (MPLS) STANDARD

In 2011, a major controversy developed between the ITU and the IETF over the MPLS standard. According to the Internet Society, the MPLS standard:

[...] assigns labels to data packets, which can then operate across multiple different protocols.

In 2007, the IETF and the ITU had agreed to base the next-generation transport network of the Internet on MPLS technology that had been developed within the IETF and they had agreed to work together to extend MPLS functionality to the network. In announcing this agreement, the Internet Society noted that, ‘The work will move forward with the recognitions that the sole design authority for MPLS resides within the IETF and that expertise for Transport Network Infrastructure resides within the ITU-T Study Group (SG) 15’ (Andersson and Bryant, 2008). It also quoted the Director, ITU Telecommunication Standardization Bureau, as saying:

Given the complexity of today’s networks, it is inevitable that we will, from time to time, see conflicts in approaches. This is natural. Quickly agreeing on a common way forward is impera­tive. And that we have done so is an indication of the great spirit of cooperation between IETF and ITU that has been built over many years of collaboration.³³

Notwithstanding this ‘great spirit of cooperation’, according to the Internet Society, the ITU-T Study Group 15:

[...] determined a Recommendation that defines operations, administration, and management (OAM) for MPLS transport networks.

According to the Internet Society, this ‘sets the stage for a divergence of MPLS develop­ment; it creates a situation where some vendors will use the IETF standard for MPLS OAM while other vendors implement the ITU-T Recommendation for OAM. This situa­tion ensures that the two product groups will not work together’ (Internet Society, 2011).

According to the Counselor for SG15:

Packet/optical transport network management requires carrier-grade protocols that can ensure fault detection and repair within strict time limits. It is also important that the OAM solution fits into the existing operational model to minimize the need for staff retraining. The ITU OAM protocol clearly addresses these strict requirements. The IETF OAM tools are still under development.³⁴

Thus, in this view, the choice by the ITU reflects its judgment that the IETF process is not currently meeting the requirements of telecommunications carriers. An earlier IETF document had made a similar point: ‘not all of MPLS’s capabilities and mechanisms are needed and/or consistent with transport network operations. There are also transport technology characteristics that are not currently reflected in MPLS’ (IETF, 2009).³⁵ Van Beijnum summarized the situation as follows:

Two groups of vendors had proposed two different protocols for Transport MPLS/MPLS Transport Profile (T-MPLS/MPLS-TP), and especially its network management (NM), also known as Operations, Administration, and Management (OAM)... The IETF adopted that protocol that is closer aligned with the way it normally does things, much to the dismay of the ITU, which has a proposal that fits better within the traditional telecom environment. After failing to get any traction in the IETF, the second group of vendors petitioned the ITU-T to adopt its protocol in addition to the one being worked on in the IETF...

Although these descriptions suggest that technical differences, or at least a delay in resolving them, led to the split between the IETF and the ITU, other forces may also have been at work. For example, some carriers, most notably China Mobile, and some equipment manufacturers, most notably Alcatel Lucent and Huawei, had already adopted a different standard from the one being developed by the IETF and, as a result, they may have been reluctant to incur the costs of switching to a different standard.³⁷ At the same time, other vendors may have made significant investments in the approach being taken by the IETF and may also have been reluctant to incur the costs of adapting that standard to the needs of the telecom carriers. For example, one author noted that: ‘Cisco and Juniper Networks, the largest providers of network devices, chose to work with and extend an IETF standardized protocol, RSVP, rather than develop a new label distribu­tion protocol. Developing a new protocol involves huge efforts in designing, standard­izing, developing, deploying and debugging’ (Goyal, n.d.). Similarly, Juniper noted that, ‘One of the design goals of MPLS-TP is to keep the MPLS architecture intact and reuse as many of the existing components of MPLS as possible’ (Juniper Networks, 2011, p. 7).

Finally, a possible source of disagreement involved differences in the procedures that are used to set standards. The Chair of the IETF described the differences as follows: ‘The IETF believes strongly in technical excellence, so a single solution is adopted when rough consensus emerges... In the ITU, optional extensions are added until nobody objects anymore’ (Housley in Van Beijnum, 2011a). In this interpretation, the ‘rough consensus’ approach of the IETF is in conflict with the more formal international treaty­based approach of the ITU.³⁸

Subsequently, at the 2012 meeting of the World Telecommunication Standardization Assembly (WTSA), participants ‘approved key standards...

Notwithstanding this development, the controversy over the two MPLS standards, and the disagreement between the two standards institutions, is likely to persist for some time. That is because the standards are incompatible so that, for example, packets that travel through routers that implement only the IETF version of MPLS will not be able to travel seamlessly through routers that implement the ITU version. This raises several possibilities.

First, as the IETF Chair noted, some router manufacturers may develop ‘dual-mode’ products, ones that implement both standards, so that their users will be able to com­municate with others regardless of the standard that they have implemented (Housley in Lawson and Ricknas, 2011). However, we understand that this would be costly and time consuming, so that manufacturers may be reluctant to pursue this approach. Second, manufacturers or network operators may develop ‘translators’ in order to facilitate transmissions between networks using incompatible MPLS standards. Finally, packets may continue to flow between networks that have implemented different standards but they may not benefit from the additional functionality that MPLS would have otherwise provided.

The two incompatible MPLS standards may coexist, perhaps for a long time, especially if each of them is strongly preferred by a different user group. That is, the situation just described could persist, with label-based routing capability on the Internet fragmented between two camps, each using a different standard. Alternatively, one of the MPLS standards could come to dominate either because its technical superiority is generally recognized or because it develops a sufficient lead for the market to ‘tip’ through the type of process described by Arthur (1989).⁴¹ If that were to occur, users that had employed the losing standard would be ‘stranded’ with the ‘wrong’ technology.

10.7