In the 90’s as we pondered the future of data networks, we came to the realisation that as most applications were based on IP, it made sense to offer IP-routed data connectivity for Wide Area Networking (WAN) solutions.
The IP die had already been cast by via internet with the value proposition of private IP networks – typically MPLS-based – to provide the flexibility of the Internet via a private network model.
MPLS has been an extraordinarily successful solution in the corporate WAN market – providing a platform for application convergence, supported by performance SLA’s spanning packet level attributes such as delivery ratio, latency/round trip delay, jitter and availability.
As a private IP network, MPLS provides peace of mind around security, but also as a managed network infrastructure, comfort that if there is an issue the matter can be resolved by a single accountable provider.
Interestingly, as MPLS has evolved over a 15+ year lifecycle, the internet has “lurked” in the background as an alternate option for WAN connectivity. I sometimes reminisce that when I launched MPLS-based products in 1999, I thought customers would move to the Internet within 5 or so years.
So, why was I wrong and is now the time for Internet WAN to take over?
Safe to say I underestimated the strength of the MPLS value proposition around security, assured application performance and the relative simplicity of providing a full mesh traffic forwarding topology, as well as how many “bad things” can happen on a public network infrastructure like the internet.
In terms of whether now is the right time for internet WAN, I’m understandably a little gun-shy in making bold statements because I have heard these bells supposedly toll numerous times before – usually when major vendors launch some new fangled Internet tunnelling protocol.
That said, I definitely get the feeling many customers would like to use internet for WAN, mainly to take advantage of lower bandwidth prices – but historically, the complexity of internet tunnelling, combined with uncertainties mentioned earlier, and concerns around exactly what throughput you will get – has meant Internet for WAN has not really taken off.
So what’s different now?
I have seen some pretty interesting justifications to support diverting OPEX from “premium priced WAN services” to more intelligent CPE to make the most of what the Internet as WAN can offer. Graphs of “ping tests” affirming improved reliability of internet packet delivery up from 83.7 per cent in 2000 to 96.6 per cent in 2012, drawing supposed parallels to MPLS WAN performance, as well as somewhat convenient round trip delay scenarios involving the east and west coast of the USA, have all crossed my desk.
However, what has changed in terms of the MPLS vs. internet WAN debate is where applications are hosted. If I want to access a Cloud-based application like Office 365, why would I take this traffic over a MPLS network to get to the internet when I could take a more direct path from the branch? This position is difficult to argue, but there’s some strings attached, particularly around branch CPE complexity and ensuring traffic security and separation.
Of course, not all applications are hosted via the public internet, thus why we have seen the emergence of the Hybrid WAN trend. At face value, a nice networking match to the hybrid way in which customers access applications via both public and private IP infrastructures and for some, a cautious step from MPLS to Internet WAN.
This diagram from ACG Research in 2013, discussing Cisco iWAN, is one of many illustrating the model:
In short, hybrid WAN splits traffic at the branch into different paths based on application destination. In its most simple form, this can be done via policy-based routing in the CPE (eg ISR AX), but vendors including Cisco, Riverbed and a host of emerging SD-WAN players are adding intelligence layers around application identification, combined with path monitoring and optimisation to abstract the networking layer into something more adaptive and malleable to accommodate changing application requirements – all in a model that is also responsive to “hiccups” in the underlying transport.
How is it all done? Tunnels – generally with the flip-side argument that this seems a lot of hassle to avoid MPLS spend. I think for this trend to take hold, policy deployment needs to be automated – a given perhaps, but I am always concerned when a trend emerges based on a commercial misalignment between two transport options. What happens if MPLS tariffs come down?.
My closing views, putting myself out there a little again:
I will become a hybrid WAN believer when customers start talking about application access, experience and optimisation as reasons to deploy hybrid WAN, rather than MPLS cost savings.
I believe there may be better options to deliver hybrid WAN than from the CPE device. As you know, I love taking sexy CPE functions into the core.
The long term future of MPLS and similar technologies may ultimately be “inside the cloud”, rather than as connectivity to them.
Until next time, go to Telstra Exchange for more on networking.