SDN is clearly the top networking priority as we enter the middle of the decade. Initially, most activity will center on converting data center infrastructure, meaning the LAN, to a software defined footing. But at some point, probably sooner rather than later, organizations will want to push SDN functionality over the wide area, particularly as the use of public and hybrid cloud architectures ramps up.
But is running SDN over the WAN a simple matter of establishing edge functionality and tying it to a bandwidth optimization platform? Not exactly. Today’s SDN requires a fair amount of tweaking before it’s ready for the long haul.
For one thing, says Cisco’s Satish Katpally, the kind of real-time programming that makes SDN so effective on the LAN is simply not possible on the WAN, at least if your goal is full end-to-end provisioning. Any centralized routing scheme will have a tough time dealing with the scalability required for broadly distributed L3-L7 routing protocols. SDN over the WAN is possible, but it will require a high degree of openness so that applications and the network can provision firewalls, analytics and the like on the fly. This will enable mutual awareness of network requirements, enhanced visibility and control, an improved user experience through WAAS and other services, and consistent security across the entire infrastructure.
Cisco rarely highlights networking requirements without a plan to address them, so it is likely we will see new WAN-based SDN solutions soon, quite possibly using technology from Glue Networks. In the meantime, carrier networks are working feverishly to develop working environments for newly virtualized networks. As I mentioned last week, Time Warner’s DukeNet is running demos of an SDN orchestration platform for wide area networks, utilizing both the OpenStack API set and the OpenFlow protocol to enable broad compatibility with burgeoning SDN environments. The company has teamed up with Cyan and Accedian to provide service management as well as carrier Ethernet and optical edge functionality.
For many organizations, SDN over the WAN is not merely an option, but a necessity. Investment in highly dynamic network fabric technologies will produce only limited returns if the functionality stops at the data center wall. The main challenge, says Aryaka’s Mouli Radhakrishnan, is that unlike L2 routing, L3 is destination destination-based and lacks flow awareness, which means we’ll need some sort of LAN-to-WAN-to-LAN protocol to handle functions like IPSEC VPN tunneling. Fortunately, L3-L7 functions are already implemented in software, which makes them more than suitable for software defined architectures running on commodity hardware.
Fortunately for enterprises eager to go the software defined route, the industry is farther along on the road to a software defined WAN than it appears. Google, for one, already operates a wide area SDN backbone for its global data center backhaul operations. The “G-Scale WAN” is based on OpenFlow and, while still undergoing field tests, is said to be capable of handling real-world data demands. Note, however, that Google’s backhaul loads, while substantial, are a pittance compared to its customer-facing Internet infrastructure, and it doesn’t appear that Google is even close to putting that load on an SDN footing.
SDN over the WAN is not a question of if, but rather when. It wouldn’t surprise me to see any number of developments over the coming year aimed at bringing the wide area network into the SDN fold, which would be perfect, because it would give the enterprise a chance to work out local networking issues first and then concentrate on the long haul in 2015.
Photo courtesy of Shutterstock.