Imagine how “happy” your eyeballs would become when you realize that your Internet connection failover time was drastically reduced from a full minute to less than half a second, Dan Wing and Andrew Yourtchenko of Cisco developed a methodology to do just that.
The Internet is changing. Network operators and content providers are beginning the widespread global deployment of IPv6, while keeping IPv4 up and running until IPv6 is ready to take over. Dan and Andrew have contributed to the cause of easing the adoption of IPv6 by documenting a methodology that will enable client applications to react more responsively in dual-stack failure scenarios by aggressively rectifying intermittent access issues and therefore preserve the end user experience for dual-stack IPv4 and IPv6 devices. This solution is documented in their IETF draft, cleverly named Happy Eyeballs. It is designed to keep the eyeballs of a computer end user “happy” in the face of problems that may exist when a host is attempting to establish IPv4 or IPv6 connectivity. The IETF draft document describes how client applications should behave when establishing IPv6 and IPv4 connectivity simultaneously, preferring IPv6 if the connectivity is successful, and disconnecting any remaining redundant (IPv4 / TCP) connections. By failing over quickly from IPv6 to IPv4, or from IPv4 to IPv6, the user is not affected by problems that occur in only one of the two IP versions in a dual-stack deployment. This can greatly reduce the connection times in problematic situations -- from minutes to milliseconds, compared to the typical behavior in many implementations today.
In anticipation of World Ipv6 Day, Google Chrome has adopted a similar approach to what Dan and Andrew have documented, under the somewhat less light-hearted name “IPv4-Fallback”. This modification promises to ease potential trouble spots on World IPv6 Day, as well as future browser interactions with dual-stack network configurations. Google’s Internet browser, Chrome 11, uses a “hybrid” variation of Happy Eyeballs that is responsible for establishing, monitoring, and management of simultaneous parallel IP connections. This software enhancement produces significant results by reducing the fallback latency of a problematic IPv6 connection from between 20 and 75 seconds as is often seen today, to as little as 300 milliseconds.
Widely deployed from the core to the edge, IP/MPLS has achieved huge success as a mature, standards-based technology now deployed by virtually every service provider worldwide. As a result, the industry has chosen to extend IP/MPLS and develop a transport profile called MPLS-TP (MPLS Transport Profile). MPLS-TP is the packet transport technology of choice being developed by the IETF to allow service providers to cost effectively migrate existing transport networks to packet based solutions.
Recently EANTC conducted an MPLS-TP Interoperability Event which focused on testing and demonstrating interoperability of key IP/MPLS and Carrier Ethernet features between multiple vendor platforms. This represented a critical technology demonstration for service providers as they begin their migration to packet transport networks.
There has been a lot of buzz recently about a second OAM (Operations, Administration, and Maintenance) solution for MPLS-TP that will cause interoperability problems between MPLS-TP and MPLS. It is accurate that there is an alternative OAM based on ITU-T Y.1731 (Ethernet OAM) proposed by a number of vendors and countries and indeed, it will cause interoperability issues. As a strong believer in standards, I certainly hope that a second approach does not occur because vendors and customers do not need the additional cost burden that a lack of interoperability causes. The fact is that only the draft recommendation for MPLS-TP OAM based on Y.1731 has begun the first step in a very long approval ITU process -- but nothing more – and in my estimates will take well over a year and could easily take up to two years to standardize. IETF MPLS OAM is widely deployed in MPLS networks today and will simply be extended as MPLS-TP is deployed as a next generation transport solution. In fact, recent interoperability testing of MPLS-TP took place at the MPLS World Congress earlier this month in Paris.
I believe that after careful consideration most operators will see the benefit of having a single end-to-end methodology to operate and manage converged packet optical transport networks, which MPLS-TP using MPLS OAM provides. Operators who select another method that is perceived to meet their short term needs now my ultimately learn that it fails to provide everything they had expected, and that having multiple OAM methods (one for Ethernet and another for MPLS) is not cost effective. It will be interesting to see what happens moving forward. At the very least, operators should make an informed decision on which approach is right for them.
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.
