Q1. What do you, Nokia (Nuage Networks), think the difference between Operator-oriented SD-WAN solutions and enterprise-oriented SD-WAN solutions is?

Gary Kinghorn: This is a great question and a key consideration for enterprises as they think through their SD-WAN strategy and requirements. 

The primary difference from the enterprise perspective is that by running their own SD-WAN infrastructure, they will have more flexibility in defining policies, integrating with other services/applications, and customizing the solution for the use case they need. That requires more planning, but it may be required depending on what the enterprise is really trying to accomplish. 

If the enterprise is primarily looking to manage WAN costs across a hybrid WAN that is provided by one service provider, though, it’s quite likely they will get a completely turn-key managed solution with immediate ROI through their provider. This may be the case for the vast majority of small to medium businesses, or larger companies with fewer remote sites. 

Another issue is that larger multi-national companies likely have to deal with different service providers in different regions, but they want one consistent SD-WAN infrastructure across the entire enterprise. In this case they would have to manage and operate their own SD-WAN controller across providers rather than using a managed service.

As far as I know, Nokia has a lot of operator references (Sonera, Exponential-e, BT, Telefonica, etc).

Q2. What are the key technical requirements that these operators asked for SD-WAN? 

Gary Kinghorn: Operators are looking for a solution that can scale, is designed for multi-tenancy, and integrates easily with both their existing WAN services (VPN and hybrid WAN), as well as other cloud service offerings. They are looking for a solution that will span access technologies, including MPLS, Internet, LTE, etc.

Q3. What made these many operators choose Nokia? What do you think the key reasons are?
Gary Kinghorn: We have had amazing success with telco and cloud service providers and we are seeing extremely rapid growth in this area. SD-WAN has such an immediate and tangible ROI that operators can’t delay deployments if they expect to remain competitive. 

What has separated us out from our competition at companies like BT, Telefonica, Telia, Telus, etc. is that we have a proven our platform that was the foundation for our SD-WAN solution with these companies over many years. 

We have demonstrated that we can scale to meet their needs, and that our solution is a natural evolution to the policies and management platforms that have been running their MPLS VPN network services for years. 

Through the global reach of Nokia, we can offer worldwide follow-the-sun service, with strong technical expertise in every country and region. 

Q4. What makes your SD-WAN solutions different from those from others like Viptela, Versa, Silver Peak, Velocloud, etc?
Gary Kinghorn: It’s no surprise that many of our competitors in the SD-WAN solution space are relatively start-ups by comparison, since SD-WAN solutions can be relatively disruptive to the major network equipment manufacturers who sell expensive branch routers. For example, you see Cisco getting in late to SD-WAN with an acquisition. Most operators appreciate that we are a proven global company, with proven technology in their networks already.

We also have a very unique value proposition in that we provide a common infrastructure for both SDN (in the data center) and SD-WAN. It’s one controller, one policy model, and can provide application-oriented network and security policy automation end-to-end. All the WAN traffic has to get to an application in either a private cloud or public cloud eventually, so being able to set policies consistently across the whole cloud infrastructure can be an enormous advantage. No other solution provider can deliver a combined solution, even if they have both SDN and SD-WAN, they are built on different architectures. For operators this can mean greater integration between their SD-WAN offerings and their hosted cloud service offerings, since they only have one SDN infrastructure to manage across multiple services. This was critical at Telia, Telefonica, AscoTLC in Italy, and others.

SD-WAN Topology Architecture 

We believe there can be many architectures of SD-WAN topologies. 
Let’s think of a simple SD-WAN solution for an enterprise which has branch offices and a HQ or enterprise datacenter. This will give us two options as seen below:

Figure 1. SD-WAN architecture options (source: Netmanias.com)

Q5. When an enterprise wants to build SD-WAN (like case (2) in Q1), which options are usually selected? Maybe option 1?

Gary Kinghorn: Yes, when an enterprise is building out or hosting their own SD-WAN infrastructure, it will look very much like option 1. The enterprise will host the SD-WAN controller and manage the routing of application traffic across the various links based on policies they manage. 

This will be transparent to the MPLS VPN provider for traffic that traverses their network. The enterprise will also have to take a more active role in managing and configuring the CPE devices.

Q6. What about when an ‘operator’ wants to build a Managed SD-WAN service network? Which option is usually used? 
Gary Kinghorn: Yes, for a provider-managed SD-WAN solution, option 2 is very close to what is needed. 

The primary difference is that the operator in managing WAN policies across all links. 

The diagram is an example of the operator offering a hybrid WAN service, with multiple networking technologies, but has visibility and control in managing the routing decisions across all of its links.

Q7. What are the pros and cons of the two architectures presented in Figure 2? 
Gary Kinghorn: The operator can only provide SD-WAN services for links it manages, but reduces the complexity for the enterprise. If the enterprise has multiple service providers, it will probably have to look at a solution like option 1.

Q8. Some think SD-WAN solutions are complementary goods for MPLS, but others believe they are substitutional goods for MPLS. What’s Nokia’s stance on that? 
Gary Kinghorn: SD-WAN can’t replace MPLS, but it can reduce utilization of MPLS (and reduce costs) while assuring an adequate level of service. So, SD-WAN may direct some traffic that usually went through MPLS over more cost-efffective paths, but that doesn’t mean MPLS is going away. It’s still likely the best path for many types of traffic. But at the same time, SD-WAN can minimize MPLS costs.

Figure for [Q9 - Q16]

(source: Nuage/Nokia)

Q9. If Nokia SD-WAN solution monitors the quality of Internet links, how is that done; i.e., how often is the data gathered? Where is it gathered? What network characteristics are measured? What actions are taken based on this data?
Gary Kinghorn: Nuage SD-WAN monitors the performance and health of the network links by measuring round trip times for test packets typically using performance monitors. The system can report on packet loss, latency, jitter, etc. We support an open performance monitoring protocol, One-Way Active Measurement Protocol (OWAMP). This is a multi-vendor protocol for measuring network performance between any two compliant devices. We also support third-party probes and responders, or any available cloud-based responder (e.g., Google) to gather network response data. It’s important not to oversample to the point that you degrade network performance with all the tests, so we balance intelligent levels of monitoring to optimize scale, accuracy and overhead.

Q10. Can you tell us more about "path selection based on continuous probes and/or first packet detection”? What’s "continuous probes" and "first packet detection"? And what’s it like to select paths based on them? Can you give us more details? 

(source: Nuage/Nokia)

Gary Kinghorn: The continuous probes are described above, essentially the ongoing testing of link performance to ensure quality of service. “First packet detection” refers to identification and classification of network traffic on a per-application basis using Signature-based L7 classification (e.g. Skype, Facebook, Google, etc.) using a library of 1400+ signatures, or Custom classification based on source/destination IP address, source/destination L4 ports, L4 Protocol (TCP/UDP). This classification of the application type can be done on the first packet of the flow only, and avoids the overhead of checking each packet. Identifying application traffic types allows us to build WAN policies around applications, like email, voice, video, etc. 

Q11. [Dynamic Path Switching] Let’s think of an example where a single flow (e.g., VoIP flow) is delivered between two NSGs, as seen in the figure below. 
When NSG is sending VoIP packets through Path 1 as seen below, will NSG, dynamically and in real time, switch the path to Path 2 if the quality in Path 1 is degraded? 
If so, what would be the procedure? For instance, how (and by who) quality degradation is detected? Who makes a decision to switch the path? If VSC does, does it send a path switching message to NSG? 

(source: Netmanias.com)

Gary Kinghorn: Yes, if performance degrades on Path 1, the NSG will switch to Path 2 dynamically, until such time as adequate performance returns. The path quality is monitored as described in the last section, with continuous performance monitors. The determination for adequate performance and service quality is set in the SD-WAN controller (VSD/VSC) by the organization on each type of application. Whatever is acceptable quality for video traffic may not be acceptable for VoIP, e.g. 

Q12. Can different flows in a single application (e.g., FTP) be delivered through different multiple paths? If they can, what’s the rule for allocating paths to each flow?

(source: Netmanias.com)

Gary Kinghorn: Yes, multiple paths can be used in parallel. Today we can achieve that by using combination of L4 header and DSCP values. For this example, we can send FTP Flow 1 from particular subnet to a link1 which is primary for that subnet while another FTP Flow 2 from another subnet to a link2 which is primary for that particular subnet. The key is to remember that we apply all our policies for the source subnets based on various L2-L4 (and in future L7) header fields. Our policies are never bound to any uplinks. (It may be helpful to read our blog on this topic at: http://nuagenetworks.net/blog/aar) 

Q13. [Link Aggregation]  To achieve higher throughput of an application like Backup, can we deliver different packets in a single flow through multiple paths, as seen below?

(source: Netmanias.com)
 

Gary Kinghorn: No, we cannot do ECMP on a per packet basis, only per flow, as in Q12.

Q14. Do Nokia SD-WAN solutions support Unidirectional steering? In the example (a) below, Tom at Branch and Alice at HQ can communicate via VoIP using one of the four unidirectional paths possible. Let’s say Path 1 is the lowest cost path from branch to HQ, and Path 4 is the lowest cost path from HQ to branch. Then, can packets moving in one direction travel through different WANs as seen in Figure (b) below? Or each session must travel through the same WAN network as seen in Figure (C)? 

(source: Netmanias.com)

Gary Kinghorn: Yes, the default is to use a symmetric path, but if performance on the return path dictates, or other policy consideration, then we can choose the alternate path back. 

Q15. Do Nokia's SD-WAN solutions support Packet Duplication? For example, let’s say there are two paths available (i.e. MPLS path and Internet path) as follows, and both paths are experiencing performance degradation. Then can SD-WAN CPE, upon detecting this issue, duplicate a VoIP packet from LAN and send it to both paths?

(source: Netmanias.com)

Gary Kinghorn: We don’t do this today, but can integrate this functionality via third party virtual network function (VNF) later this year.

Q16. Does Nokia solution support Forward Error Control (FEC) for user packets as well? If yes, how does it work. I mean, is the support temporary, and so it’s provided only when needed (e.g. when quality in all multiple links is degraded)? Or the support is rather provided to ‘certain flows at all time’?

Gary Kinghorn: We don’t do this today.

Q.17 Please let me know Nuage's SD-WAN architectures and components for enterprise and for operator (architecture diagram, component description, data path, control path).

Gary Kinghorn: The following diagram is an architectural view of our main SD-WAN components as they would be deployed for an enterprise, with a more detailed view for the operator below. The Nuage Networks VSP is our common controller platform, consisting of the policy manager, and the controller, which converts policies to direct device control instructions. In an enterprise scenario, this controller platform would be hosted at a centralized data center or operations center to direct WAN edge devices.

Virtualized Network Services (VNS), our SD-WAN solution, includes the branch CPE device, called our Network Services Gateway (NSG). NSG is a virtualized form factor that can be deployed as our dedicated appliances of various scale and size, or on any commodity x86 platform running KVM hypervisor. NSG has the ability to host various virtualized network functions, such as firewall, load balancing, monitoring, etc. services, including third party virtual NFV solutions. Northbound from the controller we support various cloud management systems like OpenStack, as well as NFV orchestration tools, through REST APIs.

(source: Nuage/Nokia)

This is the view of the operator deployment, showing a single SDN infrastructure for the datacenter and hosted cloud services, as well as various SD-WAN deployment types. The VSD/VSC can control data center virtual switches (VRS), or CPE devices at branch sites (NSG). This includes the ability to connect seamless overlay networks all the way from the branch to the cloud-based applications and SDN overlay networks, whether the applications are running on VM’s, Docker containers or bare metal.

(source: Nuage/Nokia)