What is MPLS?
Multiprotocol Label Switching (MPLS) is a networking standard, created by the IETF, that assigns labels to data packets, which can then operate across multiple different protocols. Forwarding or switching decisions for MPLS packets from one network node to another are made on the basis of the label (i.e., without requiring equipment to examine the packet’s content) facilitating easy to create end-to-end circuits. MPLS is commonly used to create Virtual Private Networks (VPNs), and it can be used to deliver different levels of quality of service (QoS) for different types of data. It is also gives service providers flexibility in routing; for example, to avoid broken links or failures.
What is the IETF’s role with respect to MPLS?
The IETF defined the MPLS specification, as part of the overall Internet technology specifications, which include the Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6).
What is OAM?
OAM stands for Operations, Administration, and Maintenance; it is essentially the set of tools that assist an operator in managing and troubleshooting a network. This includes everything from ping and traceroute to SNMP, NetConf, and a variety of other management tools.
What has happened recently?
At a meeting that ran late into the evening on Friday 25th February 2011 in Geneva, one of the ITU’s technology focused study groups, the ITU-T Study Group 15, determined a Recommendation that defines operations, administration and management (OAM) for MPLS transport networks. The determined Recommendation is at odds with an IETF standard, in spite of an agreement put in place by the ITU and the IETF two years ago to avoid such an outcome.
Why does this action matter?
By deciding to initiate its own non-interoperable MPLS technology development, the ITU has created a situation where, in the future there will be two groups of MPLS products that will not work together. While the impact may not be immediate, ongoing evolution along this path will jeopardize the globally interconnected Internet.
Haven’t these international organizations worked together to develop MPLS standards and technologies?
Yes. Over the last few years, the ITU and the IETF have successfully collaborated on work in this field. Several years ago, both organizations created a joint working team (JWT) to examine the feasibility of developing a single, collaborative solution to MPLS transport requirements.
The JWT provided a report that stated not only that a single solution was possible but also confirmed that it was possible to extend the existing MPLS architecture to meet additional requirements. The JWT report went on to recommend that protocol development for this enhanced MPLS, to be known as MPLS-TP, should be undertaken by the IETF. Both organisations subsequently endorsed these findings and formally accepted the JWT report in December 2008.
Regarding the MPLS OAM, the agreement based on the JWT report also stated that both organizations are able to work in this field; but with the fundamental agreement that each would deliver mutually compatible technologies.
What is likely to happen with two non-interoperable standards are developed?
If both technologies are deployed, it is likely that there will be confusion; if only one is deployed, the existence of the alternative is irrelevant. In this instance, there are believed to be commercial products in development for both proposals, so confusion appears inevitable.
Is there a commercial reason for the ITU to create a separate standard? Was the organization responding to customer demand?
The organization is driven to respond to its membership’s demands, expressed through contributions. Certain members chose to develop this competing technology in the ITU, developing a second solution, instead of just one as recommended by the Joint Working Team (JWT).
What role does the IETF play in Internet standards development?
The Internet Engineering Task Force (IETF) is the world’s premier Internet standards developer. Its mission is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
Why are global standards so important?
The Internet we know today could not have come about without open, interoperable, global standards. The availability of open standards means that anyone, anywhere in the world can design products, applications and technologies that enhance the Internet’s functionality.
What about multi-stakeholder collaboration in standards development?
The Internet Society believes that any interested parties, individuals or organizations should be able to contribute to standards development. In fact the IETF ensures that any interested person can participate in its work, know what is being decided, and make his or her voice heard on the issue. We believe that this collaborative approach leads to the development of an Internet that delivers the maximum value.
Did the IETF participate in the ITU-T SG15? Who made the decision?
The Internet Society is the organizational home for the IETF, and the IETF participates through the Internet Society’s ITU-T sector membership. In that role, the IETF/Internet Society spoke against this action. Ultimately, the decision was made by a vote. Only ITU member states (not Sector Members) were allowed to vote.
How has this sort of disconnect between the IETF and ITU been handled in the past?
This action is without precedent.
What will the IETF do?
The IETF will complete its work on a MPLS OAM specification. In the ongoing pursuit of a globally interoperable solution, the IETF continues to gather transport requirements and work to extend IETF MPLS forwarding, OAM, survivability, network management, and control plane protocols to meet those requirements through the IETF Standards Process.
Is the IETF moving too slowly on MPLS development?
The IETF has been working on the MPLS Transport Profile (MPLS-TP), and has been making steady and consistent progress. The JWT Report was agreed in December 2008, and the first document was published as an RFC in June 2009. This progress is actually quite rapid for any standards process.
Furthermore, there is a huge amount of work being undertaken in the relevant IETF working group: http://tools.ietf.org/wg/mpls/
Why was the Interoperability Design Team disbanded?
A design team is always a short-term mechanism and once it reports back to the WG, it closes down. The MPLS-TP Interoperability Design Team was disbanded because it had finished its work, which was shifted to the MPLS Working Group to take the process further. This is a normal practice in the IETF. Progressing work on the MPLS standard has involved creating many other Design Teams and they have been shut down when their work was complete. It does not mean that work was in any way suspended.
Here is the official IETF description of a Design Team: from BCP 25 (RFC 2418):
6.5. Design teams
It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership
and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole.”
In other words, what counts in the IETF process is the Working Group consensus, not the design team consensus. There are cases where the WG refuses or significantly changes the design team proposal; RFC 3246 and RFC 3248 are good examples.
What interoperability problems are we likely to see with two separate management protocols for MPLS implemented?
If there are two MPLS-TP protocols implemented, the passage of the data packets themselves around the network will remain unaffected. However, problems will arise if something goes wrong. In that case, if the MPLS routers use a different management protocol than the management systems, then the notification of the problem won’t be registered. There will also be serious problems for businesses if two systems are used – for example following a merger. These businesses will find that one management system can manage one set of routers, and the other management system the other routers, but problems on the boundary between the two systems won’t be handled properly.