IP services are dominating overall network traffic growth and service providers are now truly architecting a transition from legacy Time Division Multiplexing (TDM) networks to packet transport networks. It’s no longer a question of if, but when. The Transport Profile for MPLS or MPLS-TP is the packet transport technology of choice, marrying the efficiency and flexibility of packet with the robust characteristics of a traditional transport network. The telecommunications industry has embraced this emerging standard, mainly because it is subset of and interoperable with widely deployed IP/MPLS technology. To ensure this interoperability, it was collectively decided by both the ITU-T and IETF that the IETF will be responsible to define the protocol and functionality of MPLS-TP. The embeded spreadsheet specifies which RFCs have been completed and which contributions have been accepted and are in progress as Working Group drafts.
This vision is finally coming to fruition. For the first time since its inception, a standards-based interoperability test for MPLS-TP was conducted by Isocore. The results of this interoperability test were announced this week and demonstrate to the market the reality of a true MPLS-TP standard and that the vendor community is following and adopting this standard. The interoperability focused on showing how systems from multiple vendors can work together while enabling transport-like characteristics such as statically provisioned paths, protection switching, in band OAM and OAM verification. All of the capabilities tested have been defined in RFC 5860, RFC 5654, RFC 5586 and RFC 5921 which are currently published standards from the IETF.
Is it all good news? Not completely, as there is something disturbing going on with MPLS-TP. Some vendors within the industry seek to – shall we say – confuse customers into believing that multiple different technology approaches satisfy the definition of the MPLS-TP standard. This hand waving and smoke screen adds no value and clarity on this topic is essential. Specifically, some of these vendors are claiming to have also tested MPLS-TP interoperability. However after further investigation, it can be seen that they actually tested Draft-bhh-mpls-tp-oam-y1731 or other drafts. The openness of the IETF invites innovation but the downside is that any member can submit a draft of anything and claim it as a “standard”. Because of this, close inspection of these marketing claims is required. Draft-bhh-mpls-tp-oam-y1731 uses Y.1731 which is an Ethernet OAM protocol and while Y.1731 is a fine Ethernet feature it cannot and does not interoperate with MPLS and thus has been rejected by the IETF.
Let us come together as an industry and move forward with true standards-based MPLS-TP, instead of confusing it with smoke screens and hand waving. The next chapter of the telecommunications revolution is beginning and we need to get off on the right foot.