Virtualization in the WAN: Where It's Headed, and Why
The contrast between virtualization in the data center, discussed in my previous No Jitter post, and virtualization in the WAN is interesting.
We've had WAN virtualization, in the form of VLANs and VPNs, for decades, but virtualization in the data center has emerged only in the last several years. Now data center virtualization is accelerating, and predicting what will happen (if anything) in the WAN space is much harder. Perhaps the virtual WAN will depend on the virtual data center... or not.
SDN as Starting Point
Software-defined networking (SDN) is a growing factor in data center switching, and as SDN's role in the data center expands, the technology will begin to percolate out into the WAN. We can first expect this to happen with data center interconnect (DCI) applications, and eventually that could make SDN the dominant strategy for intra-cloud connectivity. This is particularly true for service providers, as well as for enterprises that use private fiber, wavelength services, or TDM connections for their core networks. The result would be one giant virtual switch linking all the servers in all the data centers.
The limiting factor here is that SDN doesn't do as much if you have to run it across an existing IP infrastructure, like an enterprise VPN. There's still a lot of WAN that isn't impacted by virtualization beyond the current VLANs and VPNs, even for larger enterprises that have DCI applications. To get to the rest of the WAN, we have to look at another dimension of SDN expansion from within, and to another virtualization model emerging -- SD-WAN.
SDN, in its pure OpenFlow form, is great for creating tunnels or virtual wires. If network operators deploying SDN for their data center and DCI networks also offer public cloud services or want to share transport services between their own data center/cloud networks and enterprise services, they could end up extending the scope of their SDN virtual wires. Carrier cloud deployment to the edge, or "edge computing," is the eventual result. Given availability of SDN virtual wires in central office/switching centers, network operators could sell these SDN virtual wires to customers or use them to build other services.
One way to do this is to use some of the edge computing resources to host virtual router instances (this is particularly well suited to exploiting edge computing deployed by a network operator). If the software routers that have been available for years are combined with advances in server and middleware technology, they'd be more than enough to use in a corporate virtual network.
A traditional VPN creates the private network by partitioning core routers shared by other users and, oftentimes, by the Internet. SDN virtual wires could be much more independent, essentially living below the IP layer and having their own traffic management and QoS. Combine virtual wires and virtual, hosted routers and you have an alternative way to build a VPN, one that really gives the customer a completely isolated virtual network, sharing nothing with others.
Enter the SD-WAN
This still isn't exactly populist virtual WAN material. Most businesses, and even some smaller sites in big businesses, would neither be able to afford to build their own network from virtual wires nor have the skills to do so. These private networks would look a lot like a frame-relay or leased-line network, after all. This is where the SD-WAN option comes in.
SD-WAN is a "higher-layer" service model, one that effectively creates a "level three-and-a-half" service that rides on top of whatever is available -- including IP VPNs based on MPLS, the Internet, and SDN virtual wires. The user doesn't see the services underneath except as paths, same as they view the lower layers of the OSI model. The SD-WAN devices or software can manage both the service at the user level and the transport connections below. If a wide range of transports are supported, then you can build an SD-WAN over diverse infrastructure, even across operator boundaries, and you can change the transport service without impacting the user's service.
One potential challenge with SD-WAN arises from the edge-centric model of deployment. You would normally have to create forwarding rules at each site to route traffic to the right interface (MPLS VPN, Internet) and the right tunnel. That could make the forwarding table very large if there are a lot of sites to connect. One solution is to designate some sites as "transit routers" to allow nearby smaller sites to home in on them and be connected.
SD-WANs can be combined with hosted virtual routers to create an alternative strategy. A hosted virtual router could be placed within the transport network at places where aggregating and distributing traffic would make sense -- in regional locations, for example. The SD-WAN endpoints in each region would then link to the region's virtual router instance to reach other regions, or even each other. This approach wouldn't be as expensive or complex as managing a VPN created entirely from virtual wires and routers, and it would control the forwarding table size.
We have, in the end, two distinct drivers for virtualization in the WAN. One is to extend the principles of data center virtualization all the way to the edge, and the other is to take advantage of the Internet to extend, or even eliminate, traditional MPLS VPNs. The two will inevitably combine in some way, and that's going to give us a true virtual network. It's just a matter of time.
Learn more about SD-WANs at Enterprise Connect 2018, March 12 to 15, in Orlando, Fla. Check out our Systems Management & Network Design track, and register now using the code NOJITTER to save an additional $200 off the Advance Rate or get a free Expo Plus pass.