In the past few years, enterprise computing has experienced major upheavals brought about by cloud apps, Wi-Fi, mobility, and BYOD. The enterprise WAN, meanwhile, has not evolved much since it was transformed into an MPLS Layer 3 VPN infrastructure more than a decade ago. Things are about change.
Based on my experience with customer deployments, more than 50% of enterprise traffic from branches is currently Internet-bound. This is due to outsourcing of utility applications, including email, search, voice, video and collaboration, not to mention cloud application use.
Despite this trend, enterprises have resisted using the public Internet to provide remote offices with direct access to cloud applications. This is primarily due to compliance issues, especially in the financial and healthcare industries. Doing so would require extensive security policies at each location and would introduce a management nightmare. The alternative, backhauling traffic to the corporate DMZ, is not feasible.
As a result, enterprise WANs continue to rely on MPLS since it provides a secure connection into the carrier's private network and a single control plane to manage – as long as all sites are within the same carrier network. Based on industry estimates and my own experience with customers, average bandwidth requirements are increasing 30% per year. Meanwhile, MPLS costs, which have not dropped much compared to high-speed consumer services, are becoming a roadblock.
For example, a typical MPLS T1 circuit costs between $250 and 350$/month, while a 100Mbps/25Mbps broadband connection costs between $150 and $185/month. Put another way, that translates to 100 times the bandwidth at 50% of the cost.
There's a general consensus in the industry that the WAN needs to support alternate transport methods. In addition to cost, MPLS is falling behind in its ability to support enterprise networking requirements for the following reasons:
- Agility: Provisioning a MPLS circuit can take anywhere from 3 weeks to 2 months depending on whether the carrier has a footprint at the location, or if they must lease from a local exchange carrier.
- Capacity: According to industry estimates and my experience with customer deployments, Bandwidth demands on the WAN have increased on average from 25% to 30% per year, while the budgets have remained flat.
- Cloud User experience: Currently, Internet-bound traffic is backhauled to the corporate DMZ, which might not be located close to the user and/or cloud application provider. This architecture introduces latency that impacts the cloud user experience.
Instead, enterprises want transport independence. Namely, they want to be able to mix and match whatever type of transport meets their business needs. This could be MPLS, Internet, LTE, Metro Ethernet, etc. However, transport independence implies that corporate traffic must traverse the Internet, which is an untrusted public network.
To create a secure transport mechanism that can span the Internet, we need to transition from L2 transport circuits to IP transport circuits. This can be achieved by virtualizing the PE at multiple layers. In existing networks, the PE is the common aggregation element for Control, Data, Services, and Policy. Virtualizing the Provider Edge function into distinct control and data elements also allows for a completely virtualized service layer with policies applied where required. This model also helps with capacity planning since growth of the enterprise network is not dependent on the control plane capacity of every PE router. Also, carriers can establish virtual routing and forwarding (VRF) instances in the cloud per customer.
Viptela, Inc. To make this new model work, customer edge (CE) devices must perform two critical functions. First, they must secure their control plane connection with the virtual PE control-plane in the cloud; subsequently, they must establish a secure data plane connection with all their peers.
Viptela, Inc. The WAN must able to integrate and accommodate multiple kinds of transport to support new cloud and mobile traffic streams. Employing IP as a transport can remove the dependencies on physical L2 transport subnet based peering and connectivity that are preventing enterprises (and carriers) from supplementing MPLS with public broadband connections.