SD-WAN – The Networks Scalpel

We are now in full swing of a new era of application communication. Digital communication now formulates our culture and drives organisations to a new world improving productivity around the globe. The dramatic changes in application consumption introduce new paradigms while reforming the way we approach networking. Networking around the Wide Area Network (WAN) must change as the perimeter has now completely dissolved.

Recent applications requirements drive a new type of WAN that more accurately supports today’s environment with an additional layer of policy management. It’s not just about IP addresses and Port numbers anymore; it’s the entire suite of business logic that drives the correct forwarding behaviour.

The WAN must start to make decisions holistically. It is not just a single module in the network design and must touch all elements to capture the correct per application forwarding behaviour. It should be automatable and rope all components together to form a comprehensive end-to-end solution orchestrated from a single pane of glass.  

Drivers For An Application-Orientated WAN

  • Push To The Cloud  

When geographically dispersed users connect back to central locations, their consumption triggers additional latency degrading application’s performance. No one can get away from latency unless we find ways to change the speed of light. One way is to shorten the link by moving to cloud based applications.

The push to the cloud is inevitable. The majority of businesses are now moving away from the on-premise in-house hosting to cloud-based management. It is easier for so many reasons. The ready-made global footprint enables the usage of SaaS-based platforms (example: ServiceNow and Salesforce) that negate the drawbacks of dispersed users tromboning to a central data centre.

Logically positioned cloud platforms are closer to the mobile user. It’s increasingly far more efficient from the technical and business standpoint to cloud hosts these applications that make them available over the public Internet.

  • Bandwidth Intensive Applications

Richer applications, multimedia traffic and growth in the cloud application consumption model drive the need for additional bandwidth. There is only so much we can fit into a single link. The resulting congestion leads to packet drops, ultimately degrading application performance and user experience. The majority of applications ride on TCP, yet TCP was not designed with performance in mind.

  • Organic Growth

Organic business growth is a big driver for additional bandwidth requirements. The challenge is that existing network infrastructures are static, unable to adequately respond to this type of growth in a reasonable period. The last mile of MPLS locks you in and kills agility. Circuit lead times impede the organization’s productivity and create an overall lag.

  • Costs

A WAN solution should be simple and to serve the new era of application we simply need to increase the link capacity by buying more bandwidth? However, nothing is as easy as it may seem.

The WAN is one of the most expensive parts of the network and employing link oversubscription to reduce the congestion is too expensive. Bandwidth comes at a cost and the ability to cater for application demands cannot be met with the existing TDM-based MPLS architectures.  

Traditional MPLS comes with a lot of benefits and is feature rich. No one is doubting this fact. MPLS will never die. However, it comes at a high cost for relatively low bandwidth. Unfortunately, the price and the capabilities of MPLS are not a perfect couple.  

  • Hybrid Connectivity

Since there is not one stamp for the entire world, similarly applications will have different forwarding preferences. Applications flows are dynamic and change depending on user consumption.

More than often the MPLS, LTE and Internet links complement each other since they support different application types. For example, Storage and Big data replication traffic are forwarded through the MPLS links while the cheaper Internet connectivity is used for standard Web-based applications.

  • Limitations Of Protocols

Hybrid connectivity is a challenge for IPsec when left to its defaults. IPSec architecture is point-to-point, not site-to-site. As a result, it doesn’t natively support redundant uplinks. Complex configurations are required when sites have multiple uplinks to multiple providers.

By default, IPsec is not abstracted; one session cannot be used over multiple uplinks, causing additional issues with transport failover and path selection. It’s a Swiss Army knife of features and much of IPSec complexities should be abstracted. Secure tunnels should be torn up and down in a moment’s notice and new sites incorporated into a secure overlay without much delay or manual intervention.

  • Internet of Things (IoT)

Security and bandwidth consumption are key issues concerning the introduction of IP-enabled objects. IoT is all about Data and it’s going to bring a shed load of additional overheads for networks to consume.

As millions of IoT devices come online, how efficiently do we segment traffic without complicating the network design even further? Complex networks are hard to troubleshoot and simplicity is the mother of all architectural success.

Much IoT processing requires communication to remote IoT platform. How do we account for the increased signalling traffic over the WAN? The introduction of billions of IoT devices leaves many unanswered questions.

  • Branch NFV

There has been strong interest in infrastructure consolidation deploying Network Function Virtualization (NFV) at the branch. Enabling on-demand service and chaining application flows is a key driver for NFV. However traditional service chaining is static since it is bounded to a particular network topology. It is typically built through manual configuration prone to human error.

Challenges To Existing WAN

Traditional WAN architectures consist of private MPLS links complemented with Internet link as backup. There are standard templates in most Service Provider environments usually broken down into Bronze, Silver and Gold SLA’s.

However, these types of SLA do not fit all geographies and more than often should be fine tuned per location. Capacity, reliability, analytics and security are all central parts of the WAN that should be available on demand.

Traditional infrastructure is very static, and for new sites, bandwidth upgrades and other service changes require considerable time processing, locking agility. It’s not agile enough, and nothing can be performed on the fly to meet the growing business needs. The cost per bit for the private connection is high, which is problematic for bandwidth intensive applications, especially when the upgrades are too costly and can’t be afforded.

Perimeters are dissolving, and the world is becoming distributed. Applications require a WAN to support distributed environments along with flexible network points. Centralized only designs result in suboptimal traffic engineering and increased latency. Increased latency disrupts the application performance and only a particular type of content can be put into a Content Delivery Network (CDN). CDN cannot be used for everything.

Traditional WAN are operationally complex and more than likely different people perform different network and security functions. For example, you may have a DMVPN, Security and Networking specialist. There are some that wear all hats but they are few and far between. Different hats will have different ideas and it could take an age to agree on the smallest of network change.

The World of SDN-WAN

SD-WAN is a replacement for traditional WAN routers, agnostic to the underlying transport technology. What this means is that you can have a mixture of different link types, MPLS, LTE and broadband. All combined together.

Based on policies generated by the business, SD-WAN enables load sharing across different WAN connections that more efficiently support today’s application environment. It pulls policy and intelligence out of the network and places them into an end-to-end solution, orchestrated by a single pane of glass.

SDN-WAN is not just about tunnels. It consists of components that are made to work together and supports in simplifying network operations while meeting all bandwidth and resilience requirements.

A New Style of WAN  

Centralized points in the network are no longer adequate; we need network points positioned where it makes the most sense for the application and user. It is illogical to backhaul traffic to a central data centre and is far more efficient to connect remote sites to a SaaS or IaaS model over public Internet. The majority of enterprises prefer to connect remote sites directly to cloud services. So why not let them do this in the best possible way?

We require a new style of WAN and shift from a network-based approach to an application-based approach. The new WAN no longer looks solely at the network to forward packets. It looks at the business application and then decides how to optimize the application with the correct forwarding behaviour.

This new style of forwarding is problematic with traditional WAN architecture. It’s hard to make business logic decisions with IP and port number information. Standard routing is packet by packet and can only set part of the picture. They have routing tables and perform forwarding but essentially operate on their own little island losing out on a holistic view required for accurate end-to-end decision making. An additional layer of information is needed.

A controller-based approach offers the necessary holistic view. We can now make decisions based on global information, not solely on a path-by-path basis. Getting all the routing information and compiling it into a dashboard to make a decision is much more efficient than making local decisions that only see parts of the network.

From a customer’s viewpoint, if you could roll back the clock and start again what would the perfect WAN look like?

  • App-Aware Routing Capabilities

Not only do we need application visibility to forward efficiently over either transport but we also need the ability to examine deep inside the application and look at the sub-applications. For example, to determine Facebook chat over regular Facebook. This takes the mystery out of the application and allows you to balance loads based on sub-applications. It’s like using a scalpel to configure the network opposed to a sledgehammer.

  • Ease Of Integration With Existing Infrastructure

The risk of introducing new technologies may come with a disruptive implementation strategy. Loss of service damages more than the engineer’s reputation. It hits all areas of the business. The ability to insert seamlessly into existing designs and incorporate new sites is a vital criterion.

With any network change, a critical evaluation is to know how to balance risk with innovation while still meeting objectives. How aligned is marketing content to what’s happening in reality? It’s easy for marketing materials to simply say implement their solution at Layer 2 or Layer 3! It’s an entirely different ball game actually doing this.

SDN-WAN carries a certain amount of due diligence. One way to read between the noise is to examine who has real life deployments with proven Proof of concept (POC) and validated designs. Proven POC will help you guide your transition in a step by step manner.

  • Regional Specific Routing Topologies

Every company has different requirements for hub and spoke, full mesh and Internet PoP topologies. For example, Voice should follow a full mesh design while Data requires a hub and spoke connecting to a central data centre. Nearest service availability is the key to improved performance as there is little we can do about the latency Gods except by moving services closer together.

  • Centralized Device Management & Policy Administration

The manual box-by-box approach to policy enforcement is not the way forward. It’s similar to stepping back into the Stone Age to ask for a catered flight. The ability to tie everything to a template and automate enables rapid branch deployments, security updates and other configuration changes. The optimal solutions have everything in one place with the ability to dynamically push out upgrades.

  • High Available With Automatic Failovers

You cannot apply a singular viewpoint to high availability. The device, link and site level’s high availability requirements should be addressed all together in an end-to-end solution. WANs have the ability to failover quickly but this requires additional telemetry information to detect failures and brown out events.

  • Encryption On All Transports

Irrespective of link type whether it is MPLS, LTE or the Internet, we need the capacity to encrypt on all those paths without the excess baggage of IPsec. Encryption should happen automatically, and the complexity of IPsec abstracted.




About Matt Conran

Matt Conran has created 184 entries.

Leave a Reply