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:
The data/forwarding plane is essentially the same as the MPLS forwarding operation, with OAM signalling being achieved by a reserved MPLS label called the GAL – Generic Alert Label (value 13) and subsequent associated OAM message embedded within the Associated Channel header (G-ACH) within the payload. This label is exposed at the MPLS-TP Path end-points (MEPs) when the outer label is popped, or at intermediate nodes (MIPs) by appropriate setting of the TTL fields in the outer label. This OAM signalling (based on the principles of PW signalling)is needed to replace standard MPLS OAM functions such as LSP Ping and BFD since there may be no control plane or IP layer in operation.
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.