whIte papersd-Wan

Many enterprises ask for SD-WAN, but that still means a change in thinking and planning for them too

The purpose of this white paper is to present SD-WAN services and to assess whether they potentially answer business customers WAN requirements. Further, we compare them to traditional MPLS services to assess whether they could complement and enhance MPLS services – or indeed possibly replace them entirely.

Another major aspect is to look at possible SD-WAN deployment approaches. This document also presents T-Systems Smart SD-WAN service powered by ngena. Finally, a few key recommendations are summarized at the end.

IntroductIon

White paper sd-wan

the structure of thIs whIte paper Is therefore as follows:

Definitions What are SDN, NFV and SD-WAN? Who are the main players?

WAN and SD-WAN requirements What are businesses’ WAN requirements? What are their expectations regarding SD-WAN?

MPLS future Does SD-WAN answer all the business WAN requirements? Can SD-WAN complete and enhance MPLS, or completely replace it?

Deployment models

What are the main deployment models for businesses? Which providers can help them?

T-Systems Smart SD-WAN powered by ngena

Final key recommendations

Over the last few years, terms like SDN, NFV or else SD-WAN have become increasingly common. Before we dive deeper into whether these can help business customers fulfill their requirements, it is necessary to present short, but exact and neutral, definitions.

First of all, it is important for business customers to understand that SDN and NFV are general technological concepts rather than a single precise technology (such as MPLS or UMTS), let alone a specific service category for enterprises. SDN and NFV consequently affect all aspects of IT and telecom infrastructure and production platforms: fixed and mobile networks; data center (DC), LAN and WAN; voice and data etc. In fact, the first SDN/NFV implementations have been mainly within large DCs, but ultimately SDN/NFV will impact all networks and all services for residential as well as business customers.

sdn and nfVSDN (Software-Defined Networking) is a network concept that separates and abstracts two main elements of networks, namely the Control Plane (signaling and control) from the Data Plane (forwarding and routing of the payload packets, i.e. of the actual usable data). With SDN the network design and management reside in central controllers (based on mass-produced high-performing servers) that distribute instructions to many low-cost and “dumb” network nodes (such as mass-produced routers, switches, access points etc.). Compared to traditional network devices

that are proprietary and combine software (“intelligence”) and hardware in one, with SDN the “intelligence” is thus separated from the network nodes and migrates to a higher level. A major advantage is that the network design, its “definition”, and its management become program-mable per software. As a consequence, SDN is also sometimes named “programmable networks”.

For its part, NFV (Network Function Virtualization) is the concept of virtualizing network functions which were until now available only as part of vendor-proprietary and dedicated appliances. The first objective of NFV is to save costs by using low-cost universal hardware appliances and by spreading the workload onto fewer of these actual physical appliances. The second objective is to gain flexibility by being able to change, add or delete functions more quickly, i.e. per software (SDN) that control these resources. SDN and NFV are independent concepts but are best combined to yield the benefits of each.

sd-wanSD-WAN (Software-Defined WAN) is in effect a concrete example of an end-customer service based on SDN and NFV, in this case for enter-prises. However, the SD-WAN definition remains rather fluid, but the fol-lowing definition is widely used, i.e. SD-WAN must have the following four characteristics (see also Figure 1):

defInItIons

White paper sd-wan

Figure 1– SD-WAN graphical description

4. Support 3rd-party services /VNFs

SD-WAN uCPE Business-grade Internet Consumer-grade Internet Mobile, e. g. LTE 4G, connectionMPLS link

SMALL BRANCH SMALL BRANCH

MAIN SITE

PUBLICINTERNET

Public CloudServices

MPLSPublic Cloud

Services

MEDIUM SITE

1. Support multiple access technologiesSD-WAN

customer portal

MOBILE4G

3. Provide a simple manage-ment interface: portal, ZTP

2. Enable dynamic path selection

Support multiple access technologies, i.e. copper, fiber and radio, such as MPLS links, consumer- and business-grade internet access connections such as xDSL, LTE etc. It could be said that SD-WAN is access-agnostic, or else that it provides an overlay on top of the under-lay (the various access technologies). Enable dynamic path selection, i.e. allowing for load balancing in

a dynamic fashion over the various access technologies and the various WANs (MPLS, IPsec, cloud services etc.).

Provide a simple management interface, including customer self-care portal, APIs (Application Programming Interfaces) and ZTP (Zero-Touch Provisioning).

Support of Virtual Network Functions (VNFs), such as security, WAN optimization, cloud connectivity etc.

One to two years ago, VNFs (Virtual Network Function) weren’t really part of the SD-WAN definition, but the recent developments and the need for supporting third-party services now make VNFs part of the SD-WAN offering (especially security and WAN optimization VNFs).

A uCPE (universal Customer Premises Equipment) is basically a white or grey box based typically on Intel’s x86 architecture. These hardware devices are based mainly, or indeed only, on open standards, components and interfaces. The VNFs can then be downloaded and run either directly onto onsite customers’ uCPE, including at local branches, but also in the customer’s own DC or in the providers’ DCs (as cloud VNFs).

Lastly, please note that hybrid WANs have been available for much longer than SD-WAN and typically include at least two WAN connections from each branch office, leveraging two or more different access technol-ogies (MPLS, broadband internet, LTE, etc.). These two connections can then be selected according to traffic type and performance parameters. It could be said SD-WAN is a further development making hybrid WAN more dynamic and resilient. SD-WAN employs centralized, policy-enabled network or service control to leverage a software policy layer that can dynamically set up and manage all branch office WAN connections for business communications services such as VPNs, WAN optimization, VoIP, network-based firewalls and other functions.

maIn sd-wan actorsSD-WAN vendors: a varied landscape of vendors with very different strengthsWith SD-WAN infrastructure vendors are even more at the forefront and visible than with usual L3 IP MPLS VPN services where vendors (e.g. Cisco, Huawei or Juniper etc.) are rather in the background.

The best-known SD-WAN vendors, and those with most identified references, include for instance Cisco / Viptela, VeloCloud, Versa and Nuage. However, there are quite a few other vendors, some of them providing only parts of the SD-WAN scope, e.g. (in alphabetical order): Cradlepoint, Huawei, Infovista, Juniper, Riverbed, Silver Peak, Talari, CloudGenix etc. Some of these vendors focus on software-only (such as Versa) but quite a few provide hardware devices as well. Some are stronger on routing, others on security, others on WAN optimization etc.

Importantly for businesses, some of these vendors do sell their solutions directly to enterprises, but in these cases the customers must realize much of the implementation and management themselves (something referred to as DIY – Do It Yourself –deployments).

SD-WAN service providers: carriers, SD-WAN vendors and system integratorsAs just mentioned, some SD-WAN vendors are also partially SD-WAN service providers, since they do cater directly to enterprises, also providing some pro-fessional services to help customer setting up and running the solutions.

But currently the main group of SD-WAN service providers comprises all the usual global large carriers and MPLS providers. In the coming years many mid-sized carriers, national incumbents and eventually even regional or city-carriers will also introduce SD-WAN services.

System integrators (such as Atos, CSC and HPE – now DXC Technology, IBM, Wipro etc.) are also potential SD-WAN service providers.

There are thus three main groups of SD-WAN service providers: the traditional telecom carriers (and MPLS services providers), the SD-WAN vendors themselves (including some “pure” SD-WAN providers such as Aryaka) and finally system integrators.

White paper sd-wan

Figure 2 – Survey of WAN business requirements

hIstorIcally: securIty, performance, relIabIlIty, scalabIlIty…whIch speak for mplsCurrently, especially in Europe, a vast majority of all large enterprises with multiple, diverse locations use MPLS services from carriers, or else, more rarely, realize IPsec VPNs themselves.

Figure 2, based on an SDxCentral survey, show some of the business customers requirements for WAN. Our own compilation on Figure 3 summarizes these various requirements that enterprises have as regards WAN. Not surprisingly, security and then reliability and performance (backed by SLAs) are the most important requirements. Further, scalability, both in terms of number of sites and bandwidth, is also an important requirement. This group (cost, security, performance, reliability, scalability) could be regarded as stable fundamental requirements that have been mentioned countless times in various surveys in the past years or indeed decades. Without these, businesses basically cannot function correctly, or, if only at high costs, then negatively impacting margin.

sd-wan requIrements: flexIbIlIty and speed In addItIonIf we now look at business expectations for SD-WAN, as illustrated by Figure 4 from an IDC survey, we see that indeed enterprises hope to find answers to their WAN requirements thanks to SD-WAN. According to this survey, “lowering WAN transport costs” tops the most important considerations when choosing an SD-WAN solution. So, there is no surprise here with a usual cost reduction driver. It is even less surprisingwhen considering that several SD-WAN vendors make a strong case about SD-WAN leading to cost savings for enterprises thanks to the use of low-priced internet connections instead of more expensive MPLS

links. However, two aspects strongly influence or indeed limit this price difference. Firstly, while it is true that MPLS links remain in most countries rather expensive, MPLS prices and price difference compared to internet access vary widely depending on countries. Secondly, it is mainly com-paring an MPLS link to a low-cost consumer-grade internet connection that shows a large price difference. On the other hand, if comparing to a business-grade dedicated internet access with similar SLAs, the price difference becomes much smaller, and indeed sometimes fully disappears depending on countries and carriers. Overall, we therefore think cost reductions thanks to SD-WAN will happen mainly in some specific, usually exotic, locations, where MPLS links are indeed extremely expen-sive. On the other hand, especially in Europe, MPLS prices are not that high and often, if at all, only slightly higher than business-grade dedicated internet access.

Otherwise, many of the other wished attributes on Figure 4 relate to flexibility (add/change bandwidths, use different access networks, prioritize by application type etc.), speed and central management and therefore match quite well the general WAN requirements previously identified.

.

customer wan requIrements

White paper sd-wan

Figure 3 – Summary of WAN business requirements

Cloud usage and digitization lead to new network design requirementsThe underlying driver for flexibility and speed (or agility as many would say) is the digital transformation that most businesses undergo. This means first and foremost the increasing usage of cloud services but also the digitization of existing business processes and finally the launch of new digital business services (e.g. depending on companies: e-com-merce, online support, in the future increasingly IoT etc.)

Historically, with MPLS, traffic has very often been routed from the various smaller sites to the main VPN site (usually the headquarters) where the main DC is located. In turn this central DC has been providing various services (SAP or other ERP software, voice and UC, storage, e-mail and, very importantly, security) to the remote sites. Consequently, internet access was often centralized on this main site too (meaning an architecture with a central / regional internet breakout). However, with the increasing popularity of cloud applications this network set up can easily create bottlenecks in the company’s network and basically deteriorates performance. Basically, the evolution of IT technologies has altered traffic flows within distributed organizations. Not only do remote users require significantly more bandwidth (e.g. when using video), but they also need to access directly cloud applications such as Microsoft Azure or Office 365, AWS, Salesforce as well as off‐premise storage (such as Dropbox etc.). For instance, latency, but also packet loss, can be negatively impacted since the traffic from local sites go the central site first before reaching the cloud services DCs (in worst cases going to another continent and back) – something called backhauling or trom-boning. This causes suboptimal performance for end-users as well as improper utilization of MPLS bandwidth for traffic actually not destined for the enterprise DC. Even putting aside cloud services usage, internet

usage and traffic has increased amongst enterprise employees so that an important and growing share of the MPLS traffic between the VPN sites is now internet traffic. For this traffic the high reliability, performance and security of MPLS may be over-dimensioned and too expensive. As a result, many businesses are now increasingly looking at having a more distributed ICT architecture, basically with more local internet breakouts, which however still need to be secure.

SD-WAN definitely a potential answer to these requirementsSD-WAN strengths, as summarized by Figure 5, basically fully play into the hand of these new requirements. For instance, customers can manage load balancing across different access technologies as well as application-aware traffic steering policies via self-care portals – thanks to central SD-WAN orchestrators. Crucially, SD-WAN can equally support internet breakout at local branches but also regional and centralized breakouts, or a mix of the three two. Furthermore, SD-WAN has been developed in the age of cloud services, thus with built-in connectivity to cloud services in mind (nonetheless with important differences both in terms of cloud services partners and technical realizations).

Moreover, with VNFs, extra security or optimization services can also be added quickly and flexibly –either onsite at local branches or centralized. Further, beside the most obvious security (e.g. next generation firewall) and optimization (e.g. compression etc.) services, future services inserted via VNFs could include applications specific to the enterprise core business: video surveillance and payment functions for retail shops, IoT sensors applications etc. Furthermore, thanks to ZTP and remote configuration of uCPE, remote branches can be up and running much faster than with MPLS.

White paper sd-wan

Figure 4 –WAN priorities / expectations of (US) business customers

inserted via VNFs could include applications specific to the enterprise core business: video surveillance and payment functions for retail shops, IoT sensors applications etc. Furthermore, thanks to ZTP and remote configuration of uCPE, remote branches can be up and running much

In effect, the variable and sometimes unpredictable usage of cloud service, with their ability to be rapidly provisioned, resized and shut down, also means that WAN connections must be more agile, able to make changes quickly to both network configuration and physical link topology as workloads shift between onsite systems and one or more cloud providers.

prImary customer groups Interested In sd-wan so farMainly large enterprises with many sitesNearly all SD-WAN service providers see most potential by midsized to large enterprises, in particular multinational companies, especially when these have many sites, and even more so when these sites are rather small and located in various countries. On the other hand, potential by SMBs is seen as more limited. Especially single-site small companies are less interested, although those with high ICT and cloud services usage, especially when they are using different access technologies on their single site, would also clearly benefit from SD-WAN.

All sectors relevant but so far retail, finance and some manufacturing or logisticsMoreover, SD-WAN potential is not strongly related to any specific economy sectors. Some sectors have nonetheless been early adopters more often than others: first the retail industry (especially retail chains with many small shops), parts of the manufacturing sector (e.g. the automotive industry), the financial industry (e.g. banks with many small branches) and finally logistics. On the other hand, for instance the public sector, for security reasons and because quite conservative in general, is not very open towards SD-WAN so far.

Two factors strongly influence interest: cloud usage and digitization as well as ICT skills levelsMore than any specific sector, it is thus in particular companies with a strong digital and cloud focus, as well as those simply with high ICT skills, that have shown most interest. Certainly, there is a high correlation between cloud services usage and interest for SD-WAN. Companies with strong ICT expertise and that tend to manage many ICT aspects themselves, e.g. managing IP routers and routing, managing IPsec VPNs etc., are also particularly open to SD-WAN. There can be on overlap between companies with high ICT skills and those with a focus on the digital economy and cloud services, but there are also cases where the two aspects can be quite distinct.

We could summarize by saying that two main groups have been inter-ested in SD-WAN so far. Firstly, some large enterprises with many small sites (retail, banks etc.) for whom the main attraction was to reduce MPLS traffic and costs (e.g. by avoiding backhauling), reduce complexity and achieve faster deployments, especially at the branch. The second group would rather include highly digital companies, especially those that both have IT staff and a high cloud usage.

Figure 5 – Are WAN business requirements met by MPLS or SD-WAN services?

The limits of SD-WAN based only on best effort internet accessNearly everyone agrees that MPLS-only services (i.e. L3 IP MPLS VPNs) as we have known them in the last 20 years will eventually disappear. Over which time frame (5 or 10 years?) is of course much harder to say. However, there is also a near-consensus that MPLS itself will not disappear any time soon, but will still play an important part as a carrier technology and underlay for SD-WAN. Indeed, if only using best effort consumer-grade internet access, there is no way to achieve really high business SLAs. Some actors argue that, thanks to SD-WAN, combining two best effort consumer-grade connections leads to higher bandwidth and availability. Yet, this may mean an improvement only from very poor to still quite low and not good enough. Besides, reality may make such a scenario difficult to achieve because in many sites, especially in emerging markets, there may not be two different consumer internet connections to choose from: no LTE (possibly even no UMTS), no coaxial cable, and for instance only one xDSL provider. Furthermore, even if there are two different xDSL providers, both are extremely likely to rely on the same copper local loop and also possibly on parts of the same equipment in the same local exchanges etc. So that if one service is unavailable, so is the other one. Moreover, laws and regulation can be a limiting factor: tunneling through some countries is difficult and slow or indeed forbidden (Egypt, China, Russia etc.). These aspects limit SD-WAN potential in some emerging markets or at least at some sites.

MPLS still very good to achieve high SLAs, especially for large sites and key applicationsOn the other hand, MPLS remains very good in terms of traffic separation and prioritization, and thus in order to achieve high SLAs. So, MPLS has definitely still a role to play for larger sites in general as well as for certain critical, especially real-time, applications. Moreover, some customer types, in particular the public sector in general, or also some manufacturers, who are conservative and for whom high security is very important, still want MPLS for the foreseeable future.

But MPLS will declineHowever, even as underlay the number of MPLS links will surely decline whereas various forms of internet connections will grow. Yet, the speed and level of the MPLS decline is difficult to foresee. Furthermore, whether directly related to SDN or to other forms of automation, it is fair to expect some improvements as regards MPLS links provisioning time. So, in the coming years we expect MPLS may become both cheaper (much so in emerging markets) and faster to deploy: thus probably slowing down its own decline or even keep it necessary for scores of use cases – or regions.

Conclusion: combining MPLS and SD-WAN so far the best wayOverall, although MPLS has many strengths, not least performance and availability backed by SLAs, as well as good security and traffic separa-tion (e.g. between various customers), it also has some drawbacks, most particularly flexibility, especially as regards cloud services usage and digitization. It can therefore indeed be said that SD-WAN actually complements and enhances MPLS quite well, as seen on Figure 5.

so, Is mpls dIsappearIng?

White paper sd-wan

Figure 6 – SD-WAN graphical description highlighting the unmanaged variants

Unmanaged 2): customer-managed local access

(BYOA) very likely to grow

Unmanaged 1): customer-managed uCPE

overall, especially over next 2 years, unlikely to grow

Unmanaged 3): customer-managed features,

policies, VNFs on customer portal very likely to grow

SD-WAN

customer portalMOBILE

4G

SD-WAN uCPE Business-grade Internet Consumer-grade Internet Mobile, e. g. LTE 4G, connectionMPLS link

SMALL BRANCH SMALL BRANCH

MAIN SITE

PUBLICINTERNET

Public CloudServices

MPLSPublic Cloud

Services

MEDIUM SITE

Public Cloud

Businesses can choose far more different deployment models for SD-WAN than what was possible with MPLS. It reflects the fact that SD-WAN is a still evolving technology and that there are many different SD-WAN providers that favor, or simply imply, some deployment models over others. This may also be down to more various company strategies. The point of this section is not to analyze the pros and cons of the various deployment models, as these would anyway vary strongly from one customer to the next. Rather we simply want to highlight the different deployment options, stressing the various management level. As regards deployments there are three main issues, which we will tackle in turn: managed versus unmanaged, MPLS versus internet access and finally where the main functions should reside, so local versus central topology issues.

sd-wan forms of unmanagedIn effect possible deployments go from DIY (Do-It-Yourself: customer does nearly everything, so buying unmanaged service from provider) to fully managed services (customer does little apart from some monitoring and requesting changes etc.) with various forms of co-managed in-between.

With SD-WAN we anticipate three main forms of unmanaged services (see also Figure 6), in the sense of customers managing themselves: The SD-WAN uCPE: so similar to unmanaged MPLS or for instance

Ethernet services where the customers manage the IP routers themselves.

The local access connections (BYOA: Bring Your Own Access; especially internet access): this was usually not the case with MPLS, except sometimes for backup links, e.g. mobile or xDSL backup, but only very rarely for the main MPLS link.

Some features and policies of SD-WAN and also some of the other VNFs (we could here speak of “co-managed”): this was very limited with MPLS services.

SD-WAN customer-managed uCPE: unlikely to grow muchOnly those risk-ready customers that have high and relevant ICT skills will go for a DIY SD-WAN approach, and thus buy hardware and software from SD-WAN vendors, and manage the SD-WAN uCPE themselves. However, over the coming two years, we think only very few companies will do this (more in the US than in Europe). For one thing, managing uCPE in a VNFs environment is complex for enterprises and it is not like managing usual IP routers. Besides, via self-care portals a minimum of uCPE management may be possible (e.g. some configuration settings, bootstrapping etc.) but without owning the uCPE and looking after maintenance and troubleshooting. Further, for the vast majority of businesses asking carriers or system integrators about SD-WAN, managing themselves the SD-WAN uCPE is not a key motivation – but rather cost reductions, flexibility in terms of self-management, speed

and agility in general (see discussion above). Actually, many companies are trying to reduce their own DCs and the number of devices they man-age, and this is also why many applications are going to the cloud, so in this light it is unlikely they should want to manage the SD-WAN uCPE.

Overall, we clearly think that SD-WAN will lead only to slightly more customer-managed uCPE. Indeed, carriers as well as system integrators are very clearly pushing managed SD-WAN uCPE at this stage.

SD-WAN customer-managed local access: very likely to grow, but only for some sitesBYOA, so customer- procured and -managed local access is always possible by all the SD-WAN providers (be they new SD-WAN providers, system integrators or usual carriers). Indeed, the very nature of SD-WAN is access-agnostic and thus stimulates BYOA: support for any type of local access technology (copper, fiber, cable-coaxial, radio and even satellite). There is consequently hardly any possibility, especially for SD-WAN projects covering many different worldwide countries, for an SD-WAN provider to supply all these. Besides, using existing connections already in place makes sense, especially when the customer is satisfied and doesn’t want to change. Finally, requirements for, in particular, security or other technical characteristics may result in a preference for a local procurement by the customer.

Nonetheless, especially for carriers, carrier-provided access is nearly always a clear priority. The main reason why network operators push for their own local access is the impact on service quality and SLAs in general: if too many sites are based on just any type of customer-provided access, resulting quality may be too low and carriers may struggle to keep up their SLAs, and the “blame-game” around every troubleshoot-ing issue may become frequent. In effect providing the local access helps in order to better combine the underlay (the various access tech-nologies) and the overlay (the SD-WAN orchestrating the underlay).

Finally, the largest international carriers know the various local access partners (indeed have established partnerships, frame contracts etc.) and thus the various access technologies, the performance, price etc. from various partners. So, they should be better placed to find local access that is adapted to the customers’ need. In effect, providing local access, even if through partners in international markets, is more or less part of their daily business.

Overall BYOA is very likely to grow in the next two years. Nevertheless, as a share of all sites, BYOA is likely to remain moderate, with large dif-ferences between customers and countries. Customers are more likely to procure their own local access in smaller emerging countries where the SD-WAN providers have hardly any access networks (their own or via partners) and are thus much more open for BYOA anyway.

there are many dIfferent deployment models

White paper sd-wan

SD-WAN customer-managed features and policies on customer portal: very likely to growA self-management customer portal is a central defining part of SD-WAN. Therefore, there is little doubt that customers’ management of SD-WAN features and policies as well as of other (security, acceleration etc.) VNFs will increase. Nevertheless, especially over the next two years or so, this development is likely to be quite moderate.

For one thing, actually managing features on the portal may require for some customers internal changes to their own processes, skills and indeed culture. So, only gradually will some customers come to self- or co-management while other businesses may decide they haven’t got the competence or else that it has no benefits for them.

However, if anything, this type of discussion and showing the portal may make customers realize the amount of work that providers usually do in the background, as part of managed services, e.g. also with traditional MPLS services.All in all, many customers may be initially open to the idea of self-man-agement, but in the end quite happy to leave the providers to manage most aspects. Nevertheless, visibility is sure to gain importance and is a must for most customers, while some forms of self- or co-management will also eventually grow. Finally, in the longer term, the user experience, especially on the portal, will be crucial if providers want, beside SD-WAN, also the various VNFs to be a success.

Conclusion: unmanaged to grow only slightly, focus still on managedOverall, we think that while forms of co-management are sure to grow, managed and indeed fully managed services will remain the best option for most businesses. Indeed since it is complex to acquire and manage a hybrid computing and application infrastructure, including SD-WAN, companies adoption of managed network services is likely to grow.

sd-wan deployments wIth Internet access or mplsOnly internet accessSince SD-WAN is access-agnostic but also a potential, at least partial, replacement of MPLS services, the choices regarding existing MPLS networks have an important impact on deployment models. At one extreme some businesses may decide to replace their MPLS network completely with SD-WAN based only on various forms of internet con-nections. However, as discussed above, we think that using only internet connections, especially low-quality consumer ones, may not be suited for companies’ DCs, larger sites and critical applications in general.

Leaving MPLS as it is, but expansions probably mainly via internet accessAt the other extreme, some customers may want to pursue what can be called an over-the-top deployment, so leaving MPLS at first exactly as it is, but integrating internet connections where already available or for instance for expansions. For instance, when new sites need to be added or bandwidth increased, the enterprise can choose mainly internet connections, as these are faster and lower-cost than MPLS links, and would use SD-WAN to combine them with the rest of the SD-WAN MPLS-based solution. This approach is basically a brownfield deployment (i.e. over an existing MPLS service). Especially if achieving easily a very good integration between SD-WAN and existing MPLS is important, customers are probably well advised to choose as SD-WAN provider

the carrier already providing them the MPLS service. Finally, there could be many in-between deployments, i.e. between replacing MPLS by internet completely or integrating MPLS as it is.

IPsec VPNs will migrate to SD-WANFor companies having currently an IPsec VPN, then SD-WAN would indeed be a complete replacement. Since IPsec VPNs are based on internet access and use encrypted tunnels, then keeping or even integrated an IPsec VPN within SD-WAN doesn’t really make any sense (SD-WAN also uses internet access and encrypted tunnels). In that case the IPsec VPN would be replaced by an SD-WAN based for instance exclusively on internet access. Enterprises realizing currently their own IPsec VPNs are indeed some of the early adopters for SD-WAN.

Vnfs deploymentsAs regards deployments another aspect to consider is where the main functions, so VNFs (SD-WAN core routing, security or otherwise), should reside, i.e. mainly on the onsite uCPE, on the company’s DCs, or on the providers DCs (cloud SD-WAN). In effect the question concerns not just additional functions, such as security and optimization, but also the core SD-WAN functions (meaning in particular the dynamic path selection and application-aware steering policies). In reality, in most cases, there will be intermediate scenarios with some functions in DCs, some in uCPE, some in both (depending on versions or backup).

deployments and proVIdersEspecially SD-WAN vendors support DIY deployments. For their part, carriers have been logically so far pushing managed services. Typically system integrators would support deployments that are intermediate: with more management than vendors but less than carriers. Obviously, when enterprises buy directly hardware and software from an SD-WAN vendor and go for DIY, they need to do everything themselves: choose uCPE and local access, integrate everything etc. – or get help through various partners. Therefore, companies’ choice will be mainly guided by whether they have the staff and expertise for DIY in the first place, and secondly whether it fits their overall strategy (outsourcing non-core activities).

T-Systems Smart SD-WAN is powered by ngena -- the next-generation enterprise network alliance. This currently comprises 17 members who collaborate via a disruptive shared economy model. Alliance partners are both suppliers and customers – meaning they make their telecommunication infrastructure available to ngena on the one hand, and purchase global wholesale SD-WAN services from ngena on the other. Smart SD-WAN is a pure SD-WAN approach, delivering the four key design characteristics without being constrained by legacy infrastructure or tools.

Smart SD-WAN offers a choice of standard access designs. It also supports hybrid access, combining Layer 2 Ethernet and Layer 3Internet. It can therefore provide enterprise-scale MPLS-equivalent reliability and security plus cost-effective Internet-based access with dynamic and application-aware routing.

The highly standardized, “clean slate” approach enables a high degree of automation. This includes zero -touch provisioning and rapid network changes via a central portal. The result is a single, harmonious corporate-equivalent platform with a global backbone, regional hubs and local access. The hubs allow secure regional Internet breakouts and connectivity to all major cloud providers within the region.

Where the customer requires local Internet breakouts, these can be created by NFV for CPE, firewalls and WAN optimization. Real-time network reporting is available via a dedicated customer portal.

Even though the control plane and the data plane are separate, Smart SD-WAN ensures a truly seamless, end-to-end solution worldwide, including local loops – all from a single provider. In addition, T-Systems offers a combined approach, with operation of customers’ existing MPLS infrastructure in conjunction with Smart SD-WAN powered by ngena.

t-systems smart sd-wan

White paper sd-wan

Figure 8 - Service Design of the ngena platform

Figure 7- ngena Partner Model

SD-WAN is coming and indeed wanted by businessesData from Cato Networks, from April 2017, found that 10% of survey respondents have already started deploying SD-WAN, 19% are planning to within the next year and another 30% are considering the technology. Survey results from IHS Markit are even more positive for SD-WAN with 80% of respondents planning a deployment over the next four years and 42% already pilot testing the technology (see Figure 9). So, SD-WAN is coming and this not just driven by the vendors and providers, unlike for some other technologies in the past. Rather, businesses themselves are clearly asking for SD-WAN or at least some specific aspects clearly related to SD-WAN, such as load-balancing over different links, application-aware routing policies, centralized visibility and management via portal etc.

Main purchase criteria / considerationsOf course each customer has different priorities, but we would consider the following aspects as important considerations when choosing an SD-WAN solution and partner: Quality of the SD-WAN routing (see below) Coverage, including backbone- and local access-services Portal for visibility and management Support and integration with existing MPLS and other access

technologies Business-grade approach and capabilities, i.e. to offer and

meet business SLAs Breadth of complementary services (see below)

Quality of the SD-WAN routing relates to aspects such as dynamic path selection, load-balancing etc. after packet inspection or only per flows, over two active uplinks or more, with flexibility for customers to set and change policies etc. There are fairly important differences in how ven-dors implement these features. Some monitor traffic at the packet level while others focus on network flows. Packet-level prioritization is more granular and provides a faster response to changing network conditions but requires a more advanced controller and thus may affect overall performance. Buyers should therefore understand the tradeoffs and their WAN traffic characteristics before deciding. In relation companies should avoid SD-WAN services that are only marketing tricks, i.e. adding a few static load-balancing possibilities to ordinary MPLS. SD-WAN is more than just hybrid WAN!

As regards complementary services, we mean first consultancy, profes-sional services and system integration in general. But we also mean first and foremost cloud services and security (and further also voice, UC etc.). The relationship with cloud services providers and support for connectivity to these is of primary importance (and here again there are technical differences) since SD-WAN and cloud strategy should go hand in hand.

fInal key recommendatIons

White paper sd-wan

Figure 9 – Businesses’ SD-WAN deployments plans

White paper sd-wan

SD-WAN - complex to deploy so managed services a key role to playInstalling a preconfigured SD-WAN uCPE via remote centralized manage-ment may indeed be “plug and play” but deploying an SD-WAN solution over many different sites and integrating it with existing MPLS as well as various access connections can be very complex indeed. Customers should not underestimate this and only those with very strong ICT skills may indeed go the DIY route. Most other companies should look for com-petent partners that can take over much in terms of deployment and man-agement. With regard to deployments there are three main aspects to consider.

How much of the existing MPLS to keep (or indeed grow?) versus internet access.

Where to implement the functions, the VNFs, so local versus central topology.

The level and type of management wished, especially with regard to local access, uCPE and features / policies management.

But overall, even with SD-WAN, one-stop-shop managed services including local access, uCPE and the management of most features, are likely to stay the most important option at least over the next years, and most certainly in Europe.

last word: sd-wan Is a major change for customers as well as for proVIders Overall, although many companies are themselves proactively asking for at least some typical SD-WAN features, they should not underestimate that changes in their way of planning and managing WAN will be needed. Via self-service portals customers will be able to manage, or “orchestrate”, themselves more VNFs, features and policies than before, but that implies a different way of monitoring and planning their own WAN requirements. In effect, businesses themselves, and that is part of the digital transformation, need to become more agile, not just their WAN.

APIs: Application Programming InterfacesBoD: Bandwidth on DemandBYOA: Bring Your Own AccessDC: Data CenterDIY: Do It YourselfICT: Information and Communication TechnologyIoT: Internet of ThingsIP: Internet ProtocolIPsec: IP securityLAN: Local Area NetworkLTE: Long Term EvolutionSDN: Software-Defined NetworksSD-WAN: Software-Defined WANMPLS: Multi-Protocol Label SwitchingNFV: Network Function VirtualizationOTT: Over-The-TopSLAs: Service-Level AgreementsSMBs: Small and Medium BusinessesuCPE: universal Customer Premises EquipmentUC: Unified CommunicationsUMTS: Universal Mobile Telephone SystemVNF: Virtual Network FunctionVoIP: Voice over IPVPN: Virtual Private NetworksWAN: Wide Area NetworkxDSL: (various types of) Digital Subscriber LineZTP: Zero-Touch Provisioning

glossary

White paper sd-wan

FURTHER INFORMATIONwww.t-systems.com/smart-sd-wan

contactPeter Harthpeter.harth@t-systems.com

Annett Claaßenannett.claassen@t-systems.com

PUBLISHED BYT-Systems International GmbHHahnstr. 43d60528 Frankfurt am MainGermany

www.t-systems.com

Publ

ishe

d 02

/ 2

018

| s

ubje

ct to

err

ors,

om

issi

ons

and

chan

ge