Bandwidth SD WAN

Demystifying the Value of SD-WAN Orchestration

In a digital world, technology is at the center of what we do and network performance has become inextricably linked with organizational productivity. On the surface the idea of SD-WAN Orchestration is pretty simple; use a centralized cloud portal to improve network visibility and management.  The benefit is much bigger than lower IT support costs, it’s a more agile and responsive network that accelerates innovation and drives higher productivity across the board.

The challenge is that every SD-WAN solution makes sweeping claims about orchestration, and the marketing jargon can be quite confusing.  Once you cut through the SEO catch phrases like “extensible networks” and “policy abstraction”, what are the tangible benefits of SD-WAN orchestration?

What’s different about SD-WAN Orchestration?

We must adapt in order to survive. In a technology-driven world, the ability to adapt is limited by how fast network updates can be deployed.  Legacy networks are slow to adapt because hardware installations and router re-configurations take time.  Skilled IT workers typically roll-out network changes on a site-by-site basis, a costly endeavor which is done on a timetable that takes weeks or even months.

SD-WAN Orchestration provides greater network agility, where centralized software updates can be deployed across all SD-WAN sites at the same time.  A recent Gartner report comparison on TCO for Cisco ISR routers shows that SD-WAN solutions cuts labor and management time by and estimated 90%.  This efficiency gain on router maintenance enables your skilled IT workers to focus on more important tasks like serving customers or pursuing strategic technology initiatives.

What applications are Orchestrated?

All SD-WANs are not created equal, and the architecture of your SD-WAN will dictate what type of network traffic can actually be orchestrated. Premise-based SD-WAN solutions are deployed through branch CPEs and data centers, which limits their scope to only orchestrate WAN applications in private clouds and WAN traffic moving between SD-WAN sites. The challenge is cloud adoption is shifting traffic patterns to the point where about 70% of your branch traffic is likely moving beyond the WAN toward the internet and public cloud applications.

When your mission-critical applications run in the cloud, network access becomes a prerequisite for knowledge worker productivity. This means orchestrating WAN traffic alone is not enough, organizations need a solution that orchestrates both private and public cloud applications.  Optimizing cloud applications requires more than just SD-WAN branch appliance, it requires an SDN overlay network architecture with cloud gateway controllers that bring your network to the cloud. Third party hosted applications like Microsoft Office 365 and Skype for Business are often considered mission-critical, SD-WAN orchestration should provide visibility and control across all these types of applications which are deliver through public clouds.

What network functions are Orchestrated?

Centralized network configuration is not a new phenomenon, but SD-WAN orchestration expands this concept through Network Functions Virtualization (NFV).  Depending on your SD-WAN solution, various Virtual Network Functions (VNFs) can all be managed through a single SD-WAN orchestration platform. Common functions include cloud provisioning for branch CPEs, multi-link WAN routing and WAN encryption, but some vendors offer a whole lot more.  SD-WAN orchestration should enable custom configurations for application QoS priority, link failover sensitivity, and even traffic compression to optimize your SD-WAN experience.

SD-WAN overlay networks with SDN gateway controllers provide work like cloud on-ramps with additional VNFs that manage inbound traffic moving toward the branch and long-haul transport moving between distant sites. At the branch, SD-WAN CPEs can include VNFs for NAT policies, branch firewalls, VLAN configurations, and even WiFi or VoIP provisioning. In rare cases, soluton like VINO SD-WAN even extend orchestration to remote workers, mobile users and IoT devices.

Who does the Orchestration?

Selecting the right SD-WAN solution can be a challenge, but the list of potential vendors gets much shorter once you choose between the Do-it-Yourself (DIY) and Network-as-a-Service (NaaS) options. DIY solutions are geared toward larger enterprise IT teams with the depth of resources to deploy and manage their own SD-WAN.  In this model, the internal IT team will need to install and manage the orchestration platform, in addition to the ongoing monitoring and management of the SD-WAN.  There are other hidden DIY costs to consider, such as SD-WAN certification training, installation and management of the SD-WAN cloud infrastructure, and WAN transport between distant sites is usually sold separately.

The NaaS option is on the other end of the spectrum, offering a comprehensive managed SD-WAN solution in a pure OPEX model.  The service provider takes accountability for the SD-WAN orchestration, which frees up additional IT resources.  VINO SD-WAN is NaaS solution that simplifies and accelerates SD-WAN deployments by leveraging service provider expertise to professionally design and install a customized SD-WAN solution.  NaaS also includes the SDN cloud infrastructure and backbone WAN transport, and some even offer network SLAs to ensure customer success.  In the NaaS model, CIOs will still rely on SD-WAN orchestration to provide network analytics and reporting for site availability, application usage, security threats and user quality-of-experience.

Key Takeaways

Underneath the catchy marketing jargon you can uncover plenty of value in SD-WAN Orchestration, but it does vary based on your implementation. Choosing between DIY and NaaS will dictate whether you’ll need to deploy the SD-WAN orchestration platform yourself, and how much IT time will be spent using it.

Operational efficiency can be increased by a wide range of VNFs that enable orchestration of branch networks and even cloud gateway controllers. Don’t underestimate the importance of SD-WAN remote access solutions for home office, mobile workers and IoT devices since these are all trending upward. While all SD-WAN solutions address WAN traffic, organizations running mission-critical applications in public clouds will require a solution that orchestrates both WAN traffic and SaaS applications delivered from public clouds.



In this review of MPLS VPN basics, discover the differences between MPLS VPNs and traditional virtual private networks, as well as the advantages and disadvantages of the latest in service provider offerings. While an MPLS VPN can simplify the design of your wide area network (WAN), some compromises and changes to your WAN strategy are required.

MPLS VPN basics: What is an MPLS VPN?

An MPLS VPN is a virtual private network built on top of a service provider’s MPLS network to deliver connectivity between enterprise locations. Available in layer 2 or layer 3 options, the VPN leverages the multiprotocol and labeling capabilities of MPLS to deliver a flat, peer-to-peer network to link all of an organization’s remote sites into a common network. In most cases, MPLS VPN services are sold without encryption, typically relying on the fact that each customer is isolated from the others on his own private network. But for those customers that require it, encryption schemes such as IPsec can be added on top of the VPN configuration.

MPLS VPN basics: Comparing MPLS VPNs with other types of VPNs

What is the difference between MPLS and MPLS VPN? The distinction between MPLS and MPLS VPN is actually straightforward, but marketing of the services, as well as customers themselves, blur the differences. When referring to MPLS services, many customers are often actually referring to an MPLS VPN service. Multiprotocol Label Switching (MPLS) is the underlining technology that enables service providers to offer customers high-speed private networks. The service provider provisions virtual circuits for each customer, insulating one customer’s data from another’s, even though both customers are on the same physical telecom gear. To the customer, an MPLS network appears similar to a leased line service, delivering a private network to link multiple corporate sites. Depending on the customer requirements, MPLS can deliver connectivity to an enterprise at either a layer 2 Ethernet level or layer 3 IP level.

What is the difference between traditional VPN and MPLS VPN services? Most VPN services create a one-to-one link between two network endpoints (referred to as a point-to-point solution). While the VPN appliance at the head end may support multiple inbound links, each link is unique, with an encrypted tunnel created between each enterprise remote site and headquarters, for example. In the point-to-point model, dedicated hardware or software is used to encrypt the traffic between the two points. For data traffic travelling between two remote sites, this scenario creates an extra hop. In order to reach another remote site, traffic from one site has to traverse the VPN tunnel to the headquarters, then route through another tunnel to its final destination. This additional stop at the hub not only adds latency in routing these packets but also requires that the hub in this configuration be equipped with enough bandwidth to handle the load from multiple remote locations. This type of VPN service is designed to create secure, encrypted links over public networks, including Internet broadband links.

MPLS VPN services, on the other hand, are designed as a multipoint technology by design, making specific VPN tunneling unnecessary. When data moves from one site to another, it looks up the site in the routing table, adds a tag for that site, and sends the packet to the next router. This approach not only reduces the latency of inter-site transfers, it also flattens the wide area network design, simplifying the approach WAN engineers can take when delivering services between sites. This approach does, however, require all remote sites to be connected to the MPLS network.

What is the difference between L2 and L3 MPLS VPNs? As the names suggest, MPLS VPNs can be provisioned as a layer 2 connection, such as Ethernet, ATM or frame relay, or at layer 3 as an IP-based network. While the majority of customers opt for the IP-based option, customers with particular security or infrastructure needs may choose the layer 2 option, handling the network layer themselves. MPLS enables service providers to offer a range of options to meet their customers’ specific requirements.

This posting originally appeared on the Coeo Solutions Blog.