Editorial StaffReally, when we talk about SDN in the WAN, all we’re talking about is separating the control plane (which tells data where to go) from the data plane (which forwards traffic to the next node). We’ll still have physical routers and other infrastructure, but they’ll become “commodity forwarding devices” with the control plan intelligence residing in a server – the SDN controller. This enables us to create virtual network overlays and functions.
Where this can be a challenge is not so much in figuring out how to integrate it into your network but the lack of widely accepted standards for SDN. Certainly, the Open Networking Foundation is developing one, but it’s yet to see full adoption. And without standards for SDN, it will be difficult to build systems. Now the ONF and other consortia and standards bodies such as the IETF are making progress on this issue – and Packet Design will be part of the process by which progress is made – but until standards are fully established, SDN may be limited only to those companies willing to spend the massive amount of time and energy to develop in-house SDN solutions, such as Google.
Another problem that SDN presents is that existing monitoring and management tools will need major updates to capture and correctly interpret network routing and traffic data. With SDN, networks will be much more dynamic; SNMP tools will be inadequate when networks are constantly changing automatically or programmatically. In order to adapt, network monitoring and management tools will need to be part of the SDN infrastructure to collect, analyze and present in real time the data that administrators and engineers need to understand the dynamics and make solid decisions about the network.
Looking even further into the future, “softwarifying” wide area networking presents interesting conundrums. SDN doesn’t only change the network but also the job descriptions of network engineers and administrators. With SDN, entire networks will be reconfigured on the fly (reconfiguring routers, adding paths, etc.) based on traffic conditions, redundancy requirements, and even iterative development to find the most efficient way of ensuring end-to-end performance.
As a result, network engineers and administrators will spend less time planning for network changes to accommodate new or changed workloads, which is a big part of network administration today. In theory, the network will handle that itself. However, anyone who thinks there will be no need for human oversight and management is naive. The question is, how will a network engineer troubleshoot problems in a software defined network effectively when they weren’t involved in its configuration?
We will be writing a lot more on this topic over the coming weeks and months.
Add comment