One of the key requirements of Unified Communications-as-a-Service (UCaaS) is the ability to connect to service providers via the Internet. As I discussed in my previous blog, few companies, especially global organizations, have Internet access at every branch. UCaaS traffic must be backhauled across the WAN to Internet access point resulting in inefficient traffic routing for voice and video calls, and potential quality issues related to excessive delay and jitter.
To remedy this situation, network architects have two primary options: “Meet Me” direct connect services that establish a dedicated link (or links) between the enterprise’s network, and the UCaaS provider’s network, or SD-WAN.
Direct connect options extend the enterprise WAN so that the UCaaS provider appears as just another node on the network. Once the direct connection is established, typically via Ethernet or MPLS, all sites are able to reach the UCaaS provider’s datacenter without having to traverse enterprise Internet connection points. An architectural example is shown below.
Approximately 16% of the more than 300 end-user organizations participating in Nemertes recent “WAN Economics 2018-19” research study currently use these types of services to connect to their cloud provider.
UCaaS providers typically offer direct connect services to their data centers for an additional fee (on top of the cost of the circuit or circuits). Examples include AWS Direct Connect (for AWS Chime), Cisco Webex Edge (for Cisco Webex), Google Cloud Interconnect (for G Suite), Microsoft ExpressRoute (for Office 365), and RingCentral CloudConnect (for RingCentral Office). Another downside to this approach is that not all UCaaS providers support this connectivity model.
Another option is the use of WAN-Cloud exchanges. Like the direct connect model, a WAN-Cloud exchange allows an organization to directly connect its existing data network to a UCaaS provider, but only if both have a presence in a co-location facility. A WAN-Cloud exchange may allow an enterprise to easily connect to multiple cloud providers who have a presence within a co-location facility. An architectural model for this approach is shown below:
Here, the customer purchases an interconnect service provided and managed by the co-location provider (e.g. Equinix, Megaport, etc.), and like the earlier direct connect example, the customer must pay an additional fee for this service, and their UCaaS provider must support this connectivity option. Approximately 13% of organizations use carrier exchange services today to connect to their provider(s).
In both of these direct connect models the customer is responsible for ensuring security of the connection between their network, and the UCaaS provider’s network, potentially creating additional cost by adding the need for firewalls and/or application layer gateways at connection points. And, customers must establish separate direct connect services for all of their cloud providers.
The second approach entails leveraging SD-WAN services as the means of connectivity to the UCaaS provider. Unlike simply extending your existing data network to your UCaaS provider, SD-WAN services offer the option to reduce WAN spend by off-loading UCaaS (and other SaaS) traffic onto lower-cost Internet connection links, improve resiliency, and guarantee performance for latency sensitive traffic like VOIP. SD-WAN virtualizes available access circuits, routing traffic over the ideal path for a given application type. Some SD-WAN service providers offer direct connect connectivity from their own networks to UCaaS providers.
In the case of UCaaS, SD-WAN will pick paths that meet UCaaS requirements for delay and jitter. Some SD-WAN services will provide detailed voice and video quality performance information, and provide managed security between your network and the UCaaS provider, preventing against potential SIP attacks including data exfiltration and denial of service. Twenty-three percent of our research participants are using SD-WAN today, reporting on average 20% reduction in WAN management resource requirements, 33% reduction in troubleshooting time, fewer site outages, and faster recovery time.
An architectural model for in-net SD-WAN is shown below:
Here, branch offices connect to SD-WAN provider points of presence over the Internet. The enterprise’s logical, virtual WAN is created by the service provider; the provider’s service cloud delivers SD-WAN functionality like routing traffic on the ideal path to support the performance and resilience needs of UCaaS traffic while minimizing cost. One way an SD-WAN service provider can optimize delivery to a UCaaS provider is by selecting an optimal Internet egress point, close to the UCaaS provider, so the last hop across the Internet is a short hop. Another way is to place a POP in the same facility as the UCaaS provider and deliver traffic to its network within the facility, or engineer a dedicated link to a nearby location, the net result being that the Internet is out of the picture for the last hop.
If you are adopting or considering adopting UCaaS make sure to evaluate how you will connect to your UCaaS provider. Consider SD-WAN services for their ability to reduce WAN spend while meeting UCaaS performance, management, and security requirements.