A lot has changed in how people work during the past twenty years. Co-working spaces, mobility, and the cloud now are common. Businesses are spread out and branch offices are empowered.
This new functionality is a good thing, of course. But, at the same time, it raises a big challenge: Multiprotocol Label Switching (MPLS), the way in which most branch offices network today, is a poor match for this new environment. It is an expensive and rigid one-size-fits-all approach to an environment that prizes fluidity and flexibility.
The answer is Software Defined-Wide Area Networking (SD-WAN). It matches the network to branch offices’ needs and provides a superior user experience. It also the potential to reduce costs.
Our Complete Guide to SD-WAN Technology article provides an in-depth coverage on SD-WAN Security, Management, Mobility, VPNs, Architecture and more.
SD-WAN is still a work in progress, no doubt, but the technology is positioned to be the next wave in branch office connectivity -- here's why.
- Welcome to the New Branch
- MPLS Problems Hurt the New Branch
- No Support for Mobile Users
- SD-WAN is the Answer
- The Different Worlds of MPLS and SD-WAN
- Is SD-WAN Totally Mature? No…
- SD-WAN 3.0: How SD-WAN Services Help
- At the Branch, Think SDWaaS. Not MPLS
Enterprises generally conﬁgure WANs in a classic hub-and-spoke manner. Branches are the ends of the spokes and resources are in the hub, typically the headquarters or datacenters. Internet trafﬁc is backhauled across the MPLS-based WAN to the hub for delivery through a secured, Internet access connection.
That’s a solid, bulletproof approach. However, branch operations have changed radically since MPLS was introduced in the early 1990s. Back then, branch offices were comfortable with a T1 or two. Today's offices need 5x that amount. Back then, most applications and services terminated at MPLS-attached datacenters, not the Internet. Today, most traffic goes out to the Internet. Back then most work was done in offices. Today, work is done, well, everywhere.
MPLS-based architectures are a poor fit for the new branch. Bandwidth is far more costly than Internet access (exact amounts will vary between regions and packages). Installation can take months, especially if the provider doesn’t have any available circuits; bandwidth upgrades weeks. This, needless to say, is too slow for today’s environment. International deployments only add to the problems.
The cost and inflexibility of MPLS leads many organizations to skimp on branch office bandwidth and, often, skip on redundancy. Instead, the sites instead are linked by non-redundant cable, DSL or wireless services and therefore are vulnerable to circuit failures and downtime. The use of separate networks makes creating a fully meshed architecture, where every office has a direct connection to every other office, far more difficult, impacting Active Directory and VoIP design. Those connected to MPLS face delays when more bandwidth is needed, such as for branch expansions and seasonal traffic spikes.
The same antiquated approach extends to contracts. Branch offices often are temporary. One may start in somebody’s home. That worker may quickly be grouped with other workers at a larger branch across town. The three-year contracts offered by MPLS providers is simply inappropriate for such small- or transient-branch offices.
And none of this says anything about two shifts in enterprise networking -- the cloud and mobility. Backhauling Internet traffic adds too much latency, disrupting with the user experience. Often traffic is backhauled only to be sent back across the Internet to a site near the edge. This back and forth -- aptly called the “trombone effect” -- causes significant latency problems and consumes expensive MPLS bandwidth, particularly when the central portal and branch office are far from each other.
WANs are all about physical locations. Mobile users, who were not that big a deal “back in the day,” are not supported by MPLS-based WANs.
Typically, mobile employees connect through VPNs to on-premises firewalls or concentrators. Data is sent either to a local access point or a centralized and secure access point on the WAN. In such scenarios, applications and other resources generally are located in different places. This leads to split tunnels and management complexity, which is the enemy of efficient, low latency and inexpensive operations.
One option is site-to-site connectivity via firewall-based VPNs. It’s a bad option, however, it necessitates convoluted Internet routing. The resulting jitter, latency and packet loss impacts voice, video and other sensitive applications. It is a workaround that causes as many problems as it solves.
SD-WANs answer these challenges -- and more. As the name implies, SD-WANs are a subset of the software-defined networking concept, which separates the data being transported from the routing and provisioning information directing the journey, increasing flexibility by orders of magnitude.
The initial versions of SD-WAN focused on bandwidth provisioning and last mile link bonding. That was a great advance. The arrival of SD-WAN 2.0 was even more exciting envisioning the entire network -- the branches, the headquarters, the datacenter and so forth -- as a single unified entity. It adds four elements that enable the selection of the path with the desired attributes through this network to be found:
- Controllers create traffic policies and send them to virtual and/or physical appliances at each location.
- Virtualized data services normalize Internet services, such as xDSL, cable, and 4G/LTE, as well as MPLS into a single network.
- Virtual overlays are secure tunnels that enable underlying data services to be temporarily and fluidly cobbled together -- virtualized -- to create an optimal path and its service characteristics.
- Application-aware routing is the process of choosing the path with the desired end-to-end performance characteristics. The variables include application requirements, business policies, and real-time network conditions.
Branches become part of this holistic network through an SD-WAN node, which usually is an appliance connected to the LAN on the branch side and MPLS and an Internet service such as cable or DSL on the network side.
When they are installed, the SD-WAN nodes, using zero-touch provisioning, point to a predetermined IP address that links it to the controller. Policies are uploaded to the device. These generally include port configuration, business policies (such as priority and thresholds for failover) and application requirements. This information is combined with real time data to determine the best network path. Latency-intolerant VoIP sessions, for instance, may be provisioned with MPLS and bandwidth-intensive FTP transfers via broadband.
Once SD-WANs are accepted as a possible alternative to MPLS-based WANs for branch offices, the focus turns to cost comparisons. The answer is complex. Bandwidth costs go down in an SD-WAN environment because cheaper broadband is a viable alternative for much traffic. On the other hand, security costs rise because branches with direct Internet access (DIA) require next-generation ﬁrewalls (NGFWs), IDS/IPS, sandboxing and other security elements. These systems also must be patched and upgraded as necessary, which adds to opex.
Another change is in vendor relationships. MPLS implementations generally are by a single vendor (the famous “one throat to choke”). SD-WAN deployments usually rely on multiple suppliers. This adds complexity to elements such as inventory and payment management. This complexity impacts costs. On a deeper level, the SD-WAN enables changes to be implemented much faster than MPLS. The cost ramifications of adding bandwidth to meet an unexpected sales spike immediately (in the case of SD-WAN) compared to next month (MPLS) is fluid. There is no doubt, however, that adding the bandwidth quickly is a benefit.
Our article MPLS vs SD-WAN provides addition considerations between the two for organizations around the world.
SD-WAN is a young technology that still is evolving in fundamental ways. Organizations considering the technology should be aware of the shortcomings of SD-WAN 2.0.
A key obstacle is related to the need for hardware. In SD-WAN 2.0, DIA is hardware-based. Placing an appliance at each branch office is expensive, as noted above, and requires capacity planning, configuration and maintenance including updates, patches and, perhaps, upgrades that can require hardware changeouts. Security is handled as it is at more substantial corporate locations.
A second shortcoming is that an SD-WAN doesn’t eliminate MPLS (or an equivalent SLA-backed service). Broadband still is an iffy proposition for latency- and loss-sensitive applications. Thus, an SLA-based service remains part of the picture. That makes sense, but it’s odd to go to great trouble to wean the organization off a particular technology -- and retain it.
A third challenge is that today’s SD-WANs don’t do a good job of supporting mobile users and the cloud. Mobile support requires additional hardware and software. SD-WANs only support clouds in a one-off proprietary manner. These approaches add complexity and aren’t a long term solution.
The next version of SD-WAN confronts these challenges. SD-WAN 3.0 -- which also is known as SD-WAN as a Service (SDWaaS) -- is fully inclusive. It provides branch office and mobile users with secure end-to-end connectivity to the cloud and data centers.
This brings the cloud “as-a-service” vision to the SD-WAN sector. Servers, storage, network infrastructure, software and security no longer are the enterprises’ problem. Software is distributed across geographically dispersed points-of-presence, each of which is fully-redundant and connected by multiple paths to every other PoP. The organization instantiates, conﬁgures and manages their SD-WANs as if they are running on their own dedicated equipment -- but they aren’t.
SDWaaS uses a “thin-edge” architecture to do this. This is a zero-touch appliance at the branch that simply moves packets across secure tunnels into the SD-WAN cloud, MPLS or other transport. The thin-edge performs only the tasks that must be done locally. These include optimal PoP selection, bandwidth management, packet loss elimination and dual transport management. This means that the edge can run in many different devices and services, such as a software client for mobile devices or an IPsec tunnel from third-party ﬁrewalls or cloud services.
But beyond the SD-WAN, most edge functions needed to support the branch perimeter are built into SDWaaS. A complete, converged security stack includes NGFW, IPS, and SGW. SD-WAN and network optimization also run in the cloud including routing, optimal path selection and execute throughput maximization algorithms. And by moving these functions into the cloud, they're available to secure and improve the experience of users in all SD-WAN nodes -- headquarters, remote branch offices, homeworkers, and, yes, mobile users.
Simplifying infrastructure is a key to thriving in our data-intensive, cloud-based and highly mobile world. A single network with a single framework for all users and applications makes IT leaner, more agile. It will include all branch offices, large and small, a big change from their traditional second-class status.
Converging networking and security is essential to the story of WAN transformation. And while SD-WAN is a valuable evolution of today’s WAN, SDWaaS goes further and brings a new vision for networking and security to today’s branch offices.