Introduction to SD-WANThe main driving forces behind SD-WAN are cost-saving and improved WAN connectivity. Broadband circuits are cheaper than private MPLS WANs. Even though Internet circuits come with a risk of security and congestion issues, that are absent in private WANs, according to some analyzers the cost difference is so big that sometimes it’s cheaper to buy a big Internet pipe and a firewall at every single site, than rely on MPLS circuit at each site. Furthermore difference is even bigger when you consider that, for most networks, most of your branch traffic is destined for the Internet - no need of WAN anyway.
Existing WAN Optimization suites and SD-WANThe larger question is whether you even need WAN optimization alongside an SD-WAN architecture. In recent years, many protocols, such as Microsoft Server Message Block, have evolved to function adequately without WAN optimization. Specific application optimizations that overcome an inefficient protocol's sluggishness in the presence of WAN latency are decreasingly useful.
In today's WAN, the primary advantage to optimization is compression and deduplication. That said, as encrypted data streams - which are not easily compressed or deduplicated - become more common, the benefit of WAN optimization shrinks.
Since internet circuits tend to be cheap, businesses can afford to increase WAN bandwidth compared to private Multiprotocol Label Switching (MPLS) circuits. In addition, SD-WAN can send traffic across more than one circuit at a time, increasing the available WAN pipeline even more. That begs the question: is WAN optimization actually required to achieve an acceptable user experience? This is a nuanced issue that can only be fully answered by analyzing your specific WAN traffic mix.
Customer benefits from SD-WAN
The new trend in the enterprise network is the ability to deliver part of the company's proprietary traffic through broadband connection and thus avoiding as much as possible the expensive leased lines (such as MPLS). Also performing load balancing between different up-links will increase significantly the throughput.
• Being a separate device in already existing infrastructure
In this case the SD WAN device just separates the traffic toward existing devices which are used to provide MPLS service, L3VPN service and access to the internet
• As a replacement of existing infrastructure
This is the best case from customer perspective since it provides all functionality in single device (PC for example) which could have three VM instances connected in service chain by virtual interfaces. Each VM provides specific functionality - SD-WAN, MPLS, L3VPN (including encryption) or plain internet access. For that functionality user could use third party MPLS and L3VPN provisioning.
• Using separate device for MPLS only
There will be a case when user want to continue using existing MPLS service but with low bandwidth just for most critical traffic. The solution is to combine SD-WAN and L3 router (L3 VPN and Internet access) in single box (as described above each will be VM instance connected in service chain). The aim is to extend existing MPLS infrastructure at the user side.
In all use cases the Configuration Module should be deployed either in enterprise network or in provider network. In most common case in should be in provider network and once SD-WAN box is configured with basic IP address stuff (static or DHCP) it must get all its configuration from Configuration Module automatically.
Key customer features
|Forwarding and VPN
|Appliance must forward enterprise traffic in secured and encrypted VPN tunnels.
|Centralized control system
|Unified management interface to configure and monitor the entire enterprise network. It shall Provide ability for network admin to configure all parameters of the appliances and monitor their status and performance;
|Management should provide visibility for the entire enterprise network behaviour, throughput, problems ,etc.
|Prioritization of flows
|Ability to define flows , and their prioritization in entire enterprise traffic (i.e. business traffic vs Internet traffic)
|Single point of control of the entire Enterprise Network
|Ability to monitor the network performance, status, abnormalities.
|Access to system logs
|Interoperability Interop with existing firewalls and other security technologies Must be able to establish VPN tunnels to other locations, running third party applications. (i.e. Fortigate firewall)
|SLAs over WAN, SLAs per flow
|Reliable throughput up to 1 Gbit per WAN uplink , and latency up to 500 usec
|High availability and failover
|It must monitor paths, and provide failover and optimisation in case of network troubles.
|GUI on management system
|Modern, fully responsive UI;
Templates with most common configuration for new user.
|CLI on SD-WAN appliance
SD-WAN software appliance
SD-WAN appliance is a software suite, consisting of two packages:
- Orchestrator - Network Management software package, that can be installed on a server or the SD-WAN machine itself, or run in public or private cloud. The network administrators use the Orchestrator to define traffic classes, security parameters, QoS characteristics, and other settings that are applied to the forwarding entity(ies), and later on to monitor the operation of the software.
- SD-WAN appliance - SW package, that is installed on a dedicated device (or just any Intel based PC) with few NIC network cards, that provides forwarding capability, which is able to separate between different flows and forward them according to the pre-configured traffic engineering policy. There can be more than one SD-WAN appliance instance running in various geographic locations.
- This SD-WAN appliance will be managed remotely by the Orchestrator. In typical scenario , Orchestrator is used to manage the entire network of SD-WAN appliances, forming the Enterprise network topology and behaviour.
High level description of SD-WAN appliance solution
SD-WAN appliance software, consisting of following components:
- Local controller/Control module. The controller software acts as a unified network control plane. In SD-WAN, the controller tells the forwarders how to forward traffic. The controller must be independent from different packet forwarder types.
- Forwarders - forwarder does the work of a router, sending traffic across the WAN. It requires HAL northbound interface to provide access to itself.
- Analysis engine - SD-WAN reacts upon network topology changes, link load, and circuit performance in real time. In addition, forwarders are aware of the applications flowing through them. The controller and an analysis engine use this data for preparing dynamic patterns and to make real-time changes (if needed) in SD-WAN fabric forwarding. The final target is to achieve self-driver SD-WAN solution capable to optimise the traffic flows based on predefined and dynamically learned patterns.
A basic diagram of the feature is shown on next picture. The Central controller and analytic engine are combined in single control entity.
Here we have a configuration system which could be any web based application able to
interpret the interface provided by the control module.
Design guideline for software components
Orchestrator must use standard protocol interface for communication with control modules - currently suggested is NETCONF. Of course any protocol could be used. For better compatibility we should have a plugin for some of the most used management systems/orchestrators It shall provide initial configuration for a single control module (ZTP); Orchestrator will receive status signals/traps for from control modules and in this way will have complete view over the network - e.g. at least to know logical relation between all involved modules providing SD WAN for single customer network (enterprise). Based on link characteristics and traffic parameters to take decision for best flow paths etc.
Provide zero touch configuration means to get all its configuration externally (from Orchestrator. Upon configured it must program forwarding plane via HAL API. All this depends on which forwarding plane we will choose. Control module will get information from HAL for status of the flows - configured and unknown. Deliver this information to the configuration module. Control module will also get information for uplinks’ status - up/down, current bandwidth, etc. and based on this re-program HAL, according to the configuration policy. For example configuration policy states that MPLS link must be utilized with specific flows with given priorities - if this link is overloaded only low priority flows will be redirected via broadband link. Notify configuration(orchestrator) module. Control module must be able to take dynamic decision upon changes of the uplinks and flows characteristics by using previously known/configured patterns.
Data forwarder is the module that performs actual data forwarding, but it also virtualize the various types of uplinks, and makes them transparent for all modules above. It must be able to perform per flow based load-balancing. Optional features can be PBF - Forwarding packets by ACLs/QoS and LPM. The standard L3 functionality such as IP tunneling, GRE, IPSec, L3VPN and NAT must be supported as well. Very big advantage will be MPLS tunneling capability. However this is targeted to customer with already existing MPLS infrastructure which tend to be enhanced.
Overall system requirements (environment and software capabilities)
- MPLS signaling (optional). If we decide not to have it then in order to provide complete solution we should have out of band MPLS signaling by external software
- Dynamic IP routing control plane (optional) - basic routing protocols working toward the provider or in overlay network.
- Static IP routing (basic) configuration.
- IP VPN support - signaled by BGP (optional) or statically configured.
- Configuring all tunneling techniques supported by the forwarding plane
- Configuring NAT
- Firewall on the uplink input flows (optional)
- IPSec, IPSec over GRE…
- IKEv2 or some other open source key exchange suit
- QoS per flow - shaping, rate limiting, prioritizing, etc.
- Path assessment and dynamic path optimization
- BFD for connectivity check
- TWAMP for RT Time and packet loss measurement
- ICMP ping to trace uplink
- Insert timestamp and sequence number in each packet per flow (only those packets destined to our SD-WAN box)- thus we will recognize the stream latency and packet loss so we can measure throughput.
On top of all this infrastructure we can run any software that can give better forwarding performance or security - such as firewalls, protocol accelerators, etc.