Back in 2006, FibreSystems Europe published an early article on packet transport networking: “When networks collide: putting the T into MPLS”. Three years on, and the consequences of that impact are still being worked through by the Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) standards organizations in a ground-breaking joint working team. But has the process created a meeting of minds, or is it more like a slow-motion road-traffic accident?

Packet transport matters more now even more than it did three years ago, as IP-based services like residential IPTV and business Ethernet continue to drive huge amounts of traffic onto the network. Internet traffic growth continues at 50–60% per annum, according to Andrew Odlyzko’s respected and ongoing Minnesota Internet Traffic Study, and mobile packet traffic growth is set to eclipse that, albeit from a much smaller starting point.

In this context, packet networking costs have to reduce by an order of magnitude if carriers’ economics are to make sense; already the market has seen high growth in Carrier Ethernet network deployments. There is wide acceptance that the Optical Transport Network (OTN) protocol will form the high-capacity foundation of nextgeneration optical transport, however, there is no consensus on what will form the “P” in packet-optical architectures (figure 1).

A long and winding road

The market has generated intense debate over the past few years on the new connection- oriented packet transport technologies, whether it is ITU-T’s T-MPLS (Transport-MPLS), IEEE’s PBB-TE (Provider Backbone Bridges-Traffic Engineering) or the new joint IETF/ITU-T MPLS-TP (MPLS-Transport Profile). All are hoping for a slice of the $10 bn that is invested worldwide by carriers in transport networks every year.

Even though it’s a decade since SDH was boldly declared dead by some, SDHbased networking with its associated WDM/OTN optical layer remains the ongoing transport workhorse of the vast majority of operators worldwide. Surely it must be time to change? Handling packet services by adapting them to circuit-based networks is perfectly manageable, but further optimization – in terms of scalability, cost and efficiency – is now required. During 2005, the ITU-T began applying MPLS to transport networks, supported by a number of significant vendors and carriers. This led to the development of a number of early T-MPLS (Transport- MPLS) recommendations in 2006 and later years, and indeed commercial equipment implementations.

As is sometimes the case in standards, a volatile mixture of intellectually proud technologists, “not invented here” syndrome, tribal groupings (netheads and bellheads, if you like), and powerful commercial players seeking market advantage, led to a heated situation. The IP/MPLS protagonists at the IETF became alarmed that the ITU-T was applying MPLS to a new network area, an opportunity that the IETF itself had either not recognized, or had failed to properly address.

Following high-level representation from the IETF and Cassandra-like warnings from others of an MPLS interoperability “train wreck” that would be hazardous to the internet itself, the ITU-T and IETF agreed in 2008 to co-operate on the development of a new Transport Profile for MPLS (MPLS-TP) by setting up a joint working team. In association, the IETF has created the MPLS Interoperability Design (MEAD) team.

The outcome of this standards in-fighting is that MPLS-TP will be a profile of MPLS intended to meet transport network layer requirements defined by the ITU-T. Further development of the ITU-T’s still-current T-MPLS standard has been discontinued. MPLS-TP protocols will be specified in a number of IETF requests for comments and future ITU-T recommendations will be able to reference those, perhaps as early as 2009, although this timescale is now looking optimistic. In the meantime, judging from the mood at IIR’s Packet Transport Networks conference held in Vienna in April, carriers seem largely relaxed about these happenings — perhaps even ambivalent — and would say that they are firmly in evaluation mode, considering what’s on the table from equipment vendors and their various future evolutionary options.

Plotting the course

MPLS was originally developed by IETF to address core IP router performance issues. Over the past 10 years it has found a strong application in carriers’ converged IP/MPLS core networks, and as a platform for data services such as IP-VPN and Carrier Ethernet. However, with the increasing importance of packet networking, the ITU-T became interested in adapting MPLS to make it “carrier class”, by addressing transport attributes such as reliability, simplicity, service-level agreements, deterministic behaviour and operations, administration and maintenance (OAM) features that were considered lacking.

MPLS-TP is based on the same ITU-T architectural principles of layered networking that are used in large-scale, ubiquitous SDH/SONET networks today. Service providers have already developed management processes and high-volume work procedures based on these principles. MPLS-TP promises a solution that provides familiar and reliable packet-based technology (i.e. MPLS) with a look and feel that’s aligned with circuit-based transport networking and organizational processes.

MPLS-TP is specifically a connection-oriented packet transport network based on MPLS that provides managed point-to-point connections to different client layer networks, such as Ethernet. It will add key transport functionality such as quality of service, end-to-end OAM and protection switching to meet deterministic transport needs.

Unlike MPLS, MPLS-TP does not support a connectionless mode. And critics say that it could be simpler in scope, less complex in operation and more easily managed. However, it opens the door to providing a low-cost Layer 2 packet transport platform, because Layer 3 (IP) features have been eliminated. This should lead to equipment implementations that support carriers’ requirements for lowercost, high-volume packet networking in their next-generation architectures.

The ninth draft version of the MPLS-TP requirements is available on the IETF website. At this objective level, they are remarkably similar to the principal requirements originally laid out for T-MPLS – perhaps unsurprisingly. According to the IETF, any new functional or protocol components defined will apply and be usable in MPLS as well as MPLS-TP. Therefore MPLS-TP will be a subset of a new and expanded MPLS toolkit.

MPLS-TP promises key enhancements to MPLS, such as engineered point-topoint bi-directional label switched paths (LSPs) and end-to-end LSP protection facilities. Indeed, there are 116 specific requirements defined in the current draft of the MPLS-TP standard — rather too many to mention here. Instead let me point out some of the key characteristics:

  • meets functional requirements of service provider transport applications;
  • re-uses existing MPLS standards where possible and minimizes new standards development;
  • consistent with MPLS architecture and forwarding paradigm, using a subset of the MPLS data plane and re-uses generic pseudowire (PW) and MPLS LSP constructs;
  • interoperates with existing MPLS and pseudowire emulation edge-to-edge (PWE3) networks;
  • packet forwarding is not required to operate or configure the data plane, or to support OAM, and has no dependency on routing protocols;
  • control plane is not required for network operation: provisioning (automated or manual) can be via network management;
  • ASTN/GMPLS dynamic control plane with extensions is envisaged as a future option to support provisioning and protection;
  • if a control plane is used for configuration of LSPs/PWs then failure and recovery of the control plane must not impact the data plane;
  • OAM is able to trigger path recovery actions without control or management plane interaction;
  • allows bi-directional, congruent (share same path through network), point-to-point LSPs;
  • traffic and OAM must be congruent, achieved by MPLS-TP alert label (TAL) and a Generic Associated Channel to carry OAM packets and enable processing at intermediate nodes when required.

However, key areas are still open for standardization, including OAM facilities. Transport OAM functions include fault alarm signals, connection verification, loss of connectivity and tandem connection monitoring, which enables carriers to manage a multi-carrier connection using segmented/nested OAM.

Currently under active debate at the time of writing, OAM capabilities are yet to be defined for MPLS-TP. It’s perhaps possible that the functionality of Y.1711 (MPLS OAM) and Y.1731 (Ethernet OAM) could be combined into one architecture. Certainly service providers are requesting consistent OAM capabilities for multilayered network and interworking of the different layers/technologies (L2, PW, LSP). Experience suggests that it may be a while before a consensus is reached on many of these topics.

Are we nearly there yet?

In the current economic climate, radical network re-architecting is unlikely to be high on carriers’ minds due to short-term financial pressures. Ironically, if done well, re-architecting will deliver long-term economic benefit. However, with standardization still in progress, and many equipment implementations still taking shape, many carriers are in a “wait and see” mood. They want to understand how MPLS-TP may best be applied, and whether it can really simplify operations and enable packet scaling.

If MPLS-TP standardization is done well, it stands a good chance of widespread adoption. Interviews with active participants reveal an optimistic outlook that the joint working approach will produce something useful in a relatively short time frame, perhaps as early as 2010. But if not, there are plenty of integrated optical and Ethernet platforms ready to take up the further challenges of packet transport, ostensibly with a simpler approach and lower cost base. In as much as Ethernet is seen as being in direct competition with MPLS, it is sure to remain in networks if only to ensure that MPLS/MPLS-TP does indeed deliver on its promise of lower cost and simpler packet networking.

Packet-optical transport doubtless has a bright future. Exactly how packet transport networks will be constructed over the next decade is still unknown. Evolution in architecture, function and integration level will surely continue over the coming years, and MPLS-TP seems sure to be part of that journey.