Requirements for a Successful SD-WAN Deployment Part 1: Business Critical Applications

There are four pillars of a successful SD-WAN deployment that need to be clearly understood at the beginning of a project:

1. Business critical applications, their requirements and dependencies
2. Security requirements
3. Site connectivity and the relative priority of each location
4. Circuit cost and availability

To fully understand each of these, we’ll break them them down into a four-part series, starting with applications.

Business Critical Applications: 
Traditionally, routing has always been based on destination. A router looks at a packet’s destination, consults a route database for the interface that shows the best match for that destination and then sends the packet on its merry way. The router never considers what application that packet belongs to, what its requirement are, or the current condition of the network attached to the “best-match” interface.

Enter SD-WAN.

The SDN controller can now see end-to-end performance metrics for a given path across the network and understand network flows at an application level. Not only can it route based on destination, but also by source, application or by other preferences. In addition to routing, it can also perform fancy types of traffic manipulation like service insertion or service chaining.

Unfortunately, if business critical applications are not well-defined and understood, these capabilities bring very little value to a business. The controller itself doesn’t know how to improve the availability or performance of your applications. It has the ability to identify them as they traverse your network, but unless a policy is defined, it will continue to indiscriminately route them based on destination like any other router. It’s up to us to figure out what metrics are acceptable for an application, which type of transport it prefers and how it should behave during a black-out or brown-out scenario.

To give you an even better understanding, let’s look at two very common applications with completely different requirements:

Application 1 – Voice: 
Voice traffic isn’t typically a large percentage of a network’s total traffic, but it is often the most important. While bandwidth intensive, it can be sensitive to loss and delay. Dropped packets will result in stutter and poor call quality, which users have very little tolerance for. In the past, quality of service (QoS) has been used to guarantee voice packets “first dibs” on network bandwidth and priority queuing to ensure they are moved to the front of the line for network egress. While SD-WAN strategies can also leverage QoS, they often use transports (internet-based circuits and broadband) that don’t honor QoS markings; this greatly reduces QoS effectiveness.

So how would we typically define voice as an application on an SD-WAN network?

For starters, we know it doesn’t like latency, or the length of time it takes for a network transaction to take place. We define a maximum latency of 150ms for the application so that anything higher than 150ms is considered “out of policy” which will result in the controller taking corrective action. We also know that voice doesn’t like to be dropped, so we ask the controller to consider packet drops and to natively prefer the most reliable transport. For most sites, this could be an MPLS connection where QoS markings are also taken into account.

Finally, voice is sensitive to jitter, the variation or “lumpiness” of delay for a given network flow which makes calls hard to buffer. In summary, we would write a policy for voice that looks similar to the following:

Voice:
Maximum Latency: 150ms
Maximum Jitter: 50ms
Preferred Transport: MPLS
Back up Transport: Broadband
Application Priority: Highest

Application 2 – Desktop Backup:
In contrast to voice, desktop backup is a common application in most enterprises, but has little in the way of requirements outside of needing to complete on time. Desktop backup applications are transmission control protocol, or TCP-based, so network delays are easily handled, and resending dropped packets is no problem. Backups, however, can require large amounts of bandwidth and can easily become bullies on the network, degrading the performance of more important applications unless controlled. These characteristics make them ideal for less expensive transports like internet, Metro-E or fiber point-to-point connections. By assigning backup to higher bandwidth, higher latency and less expensive transports, we effectively utilize our bulk bandwidth and conserve our premium lower latency transports such as MPLS. This is good news for sensitive applications that prefer them, and our budgets.

Desktop Backup:
Maximum Latency: N/A
Maximum Jitter: N/A
Preferred Transport: Broadband/Internet
Back up Transport : None
Application Priority : Low

Now that we’ve reviewed part one of our SD-WAN deployment series, you should have a better understanding of the importance of business critical applications. In part two of this installment, we will look at SD-WAN security requirements. Until then, keep the packets coming!