At the recent MPLS conference in Paris, MPLS-TP was a hot topic, what is the reason behind the success of MPLS-TP and why has PBB-TE proven so far to be unsuccessful? Also in this blog I explore whether there is a place for PBB in the network? PBB-TE offered to give network operators a scalable, statically configured traffic engineered path through the network, and by complimenting this with OAM features such as Connectivity Fault Management (CFM/IEEE 802.1ag) the plan was that a carrier class transport protocol would be unleashed based on Ethernet. PBB-TE was standardised in 2009 as IEEE 802.1Qay.
MPLS-TP (Transport Profile of MPLS) on the other hand is a relative latecomer to the party, but has quickly gained traction with many in the industry. The origins of MPLS-TP can be found by looking at the now mothballed T-MPLS work started by the ITU-T. This Transport MPLS solution aimed to provide a scalable, statically provisioned, traffic engineered path through the network, and hoped to add a new set of OAM features. However, the ITU-T proposals were fiercely argued by the IETF (responsible for the MPLS framework) as a misguided activity partly due to overloaded use of the Ethertype (used to mark the presence of T-MPLS in the Ethernet frame) causing a conflict between MPLS and T-MPLS when running on the same network.
The on-going need for a transport protocol aligned to the MPLS user base caused parties involved in IETF and ITU-T to get together and design a workable solution that satisfied both the needs of the operator and which is based on a proven carrier class technology. MPLS is that carrier class technology, having being deployed in most large networks around the world, and thus the new protocol, MPLS-TP was created.
So what is MPLS-TP?
The message from the chair of the IETF MPLS Working Group, Loa Anderson is that MPLS-TP is part of the MPLS toolbox. MPLS with additions such as:
- Transport like Operation - Static provisioning via NMS as a default - Dynamic provisioning optional via control plane respectively - Traffic Engineering rules
- Transport like OAM using in-band OAM channels - Support performance monitoring for SLA verification - Alarms and AIS
- Transport-like Resilience - Sub 50ms protection - Linear protection - Ring protection
MPLS-TP is said to be 75% standardised, with the ITU-T due to consent on the recommendations in June.
In my view PBB-TE stands still while MPLS-TP moves forward due to the small install base and lack of industry approved tools for operating in loop topologies, whereas MPLS is at an advantage with most operators being already over the learning curve of this technology since MPLS is already extensively deployed in carrier networks.
At the MPLS & Ethernet World Congress, Provider Backbone Bridging (PBB, IEEE 802.1ah aka MACinMAC) received a fair amount of attention. Note that this is different from PBB-TE in that it continues to supports bridging functions normally supported by Ethernet i.e. MAC address learning, flooding of unknown MAC destination addresses, flooding of broadcast etc, and therefore it is complimentary to the Layer 2 aspects of L2VPN technology i.e. VPLS and H-VPLS.
PBB allows VPLS to be scaled by encapsulating many customer MAC addresses into a path transported by one backbone MAC address (MAC scaling) and also reduces the number of pseudowire tunnels required within the MPLS core (PW reduction). PBB+VPLS was mentioned by Verizon as a key technology and by several vendors as a method of scaling multipoint to multipoint Inter Cloud services.
So MPLS-TP is winning the debate for transport, but PBB will surely have a place in the network. Once PBB matures and carriers gain operational experience, one might see PBB-TE rising back up the ‘hype curve’ and causing round 2 of the protocol wars.