Most SDN deployments have focused on traffic management within data centers. Some deployments have been ground-up rethinks of network architecture, such as Facebook’s Data Center Fabric and Google’s Andromeda. Others focus on the use of white-box hardware, such as SDN projects at Goldman Sachs. A third type support more agile processes, like Fidelity’s Click2Compute private cloud initiative. Major vendor initiatives such as Cisco ACI have looked to this market and not found much traction yet. In each of these cases, the goals of SDN in the data center have been aligned to lower hardware costs, greater efficiency through automation, and faster network service delivery.

Life at the Edge

But what about using SDN for optimizing WAN, internetworking and the network edge? External network connectivity and performance are huge drivers for cost, utilization, resiliency, and overall service delivery. Much of the network cost is connecting data centers, call centers, and branch offices together.

According to Gartner, nearly half of the network services budget in an enterprise goes to telecom services vendors. That means that telecom services – including WAN, ISP, and telephony – is 6 to 7 percent of the IT infrastructure and operations budget, more than three times that of network hardware and software combined. When it comes time to lower costs, WAN and data peering and telephony are the biggest levers. These costs are primarily determined by architectures and policy set at the network edge. Ashton Metzler & Associates finds that WAN budgets were three times more likely to increase than decrease in 2014.

In addition, SaaS, IaaS, sensor data from the IoT, and mobile and home traffic from remote employees will further drive the importance of the network edge as the key determinant of cost and performance for most organizations. Intra- and inter-data center SDN has delivered on some of the above goals, but has yet to be compelling to a broader set of the market.

The most ambitious SDN projects to date have often included deployments between data centers, such as Google’s WAN project, and focused on cost and utilization optimization for Web-scale networks. But enterprise deployments in production have been much rarer. So if SDN at the network edge has a reasonable business logic, what is holding back broader implementation?

The Case for SDN at the Edge: SD-WAN

Consider some scenarios:

• How do you detect and respond to an outage in a primary ISP?
• What is your response to a major cable cut in your WAN?
• How do you determine changes to a route with persistently higher latencies?
• How do you dynamically split traffic between providers that charge different rates?

These sorts of situations can benefit from automation and coordinated policies that SDN delivers. SDN at the edge is well placed to improve:

• Cost economics of bandwidth (with better control over traffic sent to diverse ISPs)
• Use of lower-cost connections (avoiding MPLS circuits or better utilizing backup links)
• More flexible overlay networks (such as a new virtual circuit between branch offices)
• Performance of inter-network traffic (with optimized routing)
• Fault-tolerance (with an ability to reroute traffic when an upstream is degraded).

The market is beginning to move in this direction, with some declaring 2015 as the year of the SD-WAN. A crop of vendors has sprouted to make the WAN more programmable: Viptela, CloudGenix, VeloCloud, Silver Peak, Talari and Glue Networks. The vision is to program WAN traffic based on cost, performance, time of day, application, data volumes, etc. But for this vision to come together, you need high-quality, real-time data sources to feed the SD-WAN.

Performance Data From Beyond Your Network Edge

Many organizations, particularly those considering or deploying SD-WAN, already have their own networks well instrumented for performance data. Technologies such as packet capture, SNMP and NetFlow give insight into device diagnostics and network flows. But these tend to focus on data center and campus networks, rather than performance near or beyond the network edge.

So what sort of performance data do you need to make SDN decisions at the network edge?

1. Real-time, or near real-time, performance data available as an API
2. Routing preferences, as well as reachability and path changes over time, provide information about how traffic flows will be treated upstream
3. Segment-by-segment performance of upstream networks, including measurements of loss, latency, and bandwidth, gives the SDN controller the performance variables necessary to choose the optimal route for specific traffic flows
4. Application-specific availability, response time, and QoS to understand how SLAs are affected by routing decisions and traffic engineering

While much of the SDN action up to now has been within the data center, a huge opportunity exists for SDN at the network edge and across the WAN. From saving money to delivering better SLAs to better handling of faults in external networks, SDN can deliver real advantages to mainstream enterprises. Getting there requires a strategy for collecting and analyzing external network performance data, in addition to existing instrumentation, to drive SDN decisions.