HR Presents New MPLS-TP White Paper

11:00 AM -- In mid June, Heavy Reading hosted a webinar on the emerging MPLS-Transport Profile technology and it had one of the highest numbers of audience registrants in the history of Light Reading webinars. We had registrations from more than 90 countries, including large numbers from the United States, Canada, India, the U.K., Germany, Brazil, Italy, Israel and Mexico, as well as significant numbers from multiple other countries.

Given what appears to be widespread interest in the topic, I am pleased to announce that Heavy Reading has just released a new white paper, "MPLS-TP in Next-Generation Transport Networks," that can be downloaded from Light Reading's MPLS-TP Briefing Center. You can also find other material on the briefing site from network solutions companies that participated in the webinar and shared their perspectives on MPLS-TP in the paper. The companies include Cisco, ECI, Ericsson, Ixia and Metaswitch. Experts from these suppliers have been at the forefront in working with operators like Verizon, BT, AT&T, Comcast, NTT, Bharti Airtel and others to develop and deploy a transport profile for MPLS that allows the technology to be operated in a similar manner to existing transport technologies and gives it the capability to support packet transport services with a degree of predictability that is similar to that found in existing Sonet/SDH networks.

After much effort and debate among members of the IETF and ITU-T, key MPLS-TP standard pillars are largely complete, and the MPLS-TP ecosystem is beginning to take shape. Multiple vendors are in the process of testing, trialing and beginning early service provider deployments of MPLS-TP solutions that make use of new MPLS-based operations, administration and maintenance (OAM) tools. Sophisticated test and measurement solutions designed to demonstrate that MPLS-TP is a viable and compelling technology are now available and have been used in public interoperability tests and demonstrations.

While a few hurdles remain to be overcome, we can say with increasing confidence that the era of standardized MPLS-TP technology is beginning to emerge and is poised to affect the way converged networks are built in coming years.

If you are a service provider, now is the time to get your team up to speed on MPLS-TP. If you are a financial analyst or investor, you will want to start paying closer attention to the trial and deployment activity because the ability of network solutions providers to support standards-based MPLS-TP technology on packet optical transport systems, Carrier Ethernet switch/routers and other equipment could begin to shape carrier purchasing decisions in coming quarters.

Heavy Reading plans to track MPLS-TP developments closely and canvass operators opinions on the emerging technology in the coming months. Among other things, I will be joining representatives from Cisco, ECI and Juniper on an MPLS-TP session at Light Reading’s Ethernet Expo Americas, which will be held in New York City during Nov. 8 and 9.

— Stan "EtherMan" Hubbard, Senior Analyst, Heavy Reading

tmmarvel 12/5/2012 | 4:57:13 PM
re: HR Presents New MPLS-TP White Paper

The report on p. 8, under MPLS-TP Drivers states that packet traffic is “currently being carried on inefficiently over legacy SONET/SDH networks that run at constant bit rates even there is no traffic” and that with MPLS-TP “operators seek to .. take advantage of more flexible data rates and statistical multiplexing efficiencies enabled by packet technology”.


1) How does MPLS-TP improve this inefficiency arising from constant bit rate physical layer transmission?

Note that MPLS-TP is L2 protocol, and it will need some L1 protocol for physical connectivity. The report as quoted above attributes the non packet traffic load adaptive physical connection bit rates to the use of legacy SONET/SDH as the L1 protocol. So the next question:

2) Is there any L1 protocol (standard or pre-standard) that provides connections with variable, ideally packet traffic load adaptive, bit rate?

Note that the key here, as a distinction to “legacy SONET/SDH” while considering equals of physical layer connections such as eg VC-4-64c (STS-192c), is the question of what packet layer transparent physical layer techniques there are that provide variable bit rate?

Moreover, such equals, while setting themselves apart from legacy constant bit rate physical layer connections, would still need to support the essential 'legacy' L1 functionality of physical layer channelization, ala TDM, eg muxing 4 STS-192c:s in OC-768, or something achieving same performance in terms of near zero jitter, minimized latency, zero packet loss and isolation based security between the unrelated traffic streams.

What seems to be apparent here is that:
- MPLS-TP, or any other packet layer (L2 or higher layer) protocol, cannot do anything by itself for the inefficiency caused by constant bit rate L1 connections.
- Instead, the solution has to be implemented at L1/0 - - which brings the third question:

3) What is this (implied) companion physical layer protocol of MPLS-TP that makes the bandwidth of also the network physical layer connections to adjust to client layer packet traffic loads?

And in case that the intent of MPLS-TP is to replace L1 TDM based physical layer (eg Packet-over-SDH) channelization with (supposedly) performance wise close-to-equal, L2 packet-switched abstraction of such channelization, and run these L2 LSP “channels” on un-channelized fat pipes eg 10/100GE, the following questions arise:

4) Isn't the above quoted idea with MPLS-TP  “packet transport” here then same as with ATM, just without the segmentation and reassembly (SAR) an cell overhead (but with Eth overhead)?

5) Is the benefit of avoidance of the SAR enough to make MPLS-TP a successful protocol where ATM massively failed?

6) And while MPLS-TP avoids the SAR problems, it has to implement a solution to deal with the jitter etc. performance problems caused by variable packet length switching at each node along the LSPs -- but what is the solution?

Note that this problem is a major one in packet layer shared networks, eg MPLS-TP and Ethernet switched backbones with un-channelized inter-node physical layer connections; long packets, even if low priority, once their transmission on an un-channelized inter-switch physical interface has started, will unavoidably block for their entire transmission duration any and all higher priority packets that would need to be sent on the given shared un-channelized L1 interface.

Note further that real L1 TDM channelization avoids all of the problems of SAR, Eth overhead, jitter caused by variable length packet switching, and undesired cross-contract dependencies and interferences and security concerns of packet layer shared service provider networks.

In practice, when not using L1 TDM channelization to isolate the different customer contract networks at SP backbone, the only workable solution is to over-provision the network ie keep its average network bandwidth utilization low - - which is the antithesis of the purpose of moving from TDM channelized packet transport to purely packet-switched packet transport.

And hence the closing questions:

7) Isn't the more achievable objective for MPLS-TP the ability for the SPs to connect L3/2.5 IP/MPLS routers with simpler and more cost-efficient L2 MPLS-TP switches, which the SPs can acquire from a number of price-competitive equipment vendors (unlike is the case with IP-MPLS LERs/LSRs whose operation is dependent of their support for the dominant IP router vendor compliant  implementation of the L3 IP based signaling protocols just for the L2 LSP setup)?

8) And regarding the issue with constant bit rate physical layer connections -- aren't we learning that this issue is a L1/0 issue that has to be solved through innovation at these layers, and to not unnecessarily complicate MPLS-TP (ala ATM style QoS, OAM etc.)? Is there any L1/0 solution in sight for accommodating bursty packet traffic loads, and allowing to actually simplify the L2 switching?

Caketin 12/5/2012 | 4:56:20 PM
re: HR Presents New MPLS-TP White Paper

If MPLS is something you're interested in, Ina Minei and Julian Lucek from Juniper have written an authoritative guide. You can find out more about it here: http://www.wiley.com/remtitle.... including endorsements from industry professionals.

Sign In