In my last blog I introduced challenges Enterprises are facing in their WAN deployments and the definition of ONF SDN. While the broad definition of ONF's SDN architecture implies many theoretical answers to these challenges, we need to be pragmatic. Let's take a look at the practical differences in LAN and WAN networks that affect how you'd deploy SDN on each. 

The first practical differencebetween LANs and WANs you must take into account when considering the applicability of SDN is their effect on user experience, one of the WAN challenges I outlined earlier. Branch networks are evolving with the IT consolidation in the data-center. With applications being served from a centralized (and virtualized) data-center over the WAN to end-users and customers in the branches, the WAN becomes a critical resource and is usually a bottle-neck. User application experience suffers due to high latency and low bandwidth of typical WAN MPLS (T1/E1) connections. Any SDN controller solution that implies it has a centralized routing control plane that can program routes, QoS, firewall and other services in real-time across the WAN, as it would within a single data-center across the LAN, is not a solution. Real-time programming of WAN network devices is simply not possible with the turn-around times that would be involved in the end-to-end provisioning. Further, the network devices, mainly L3-L7 routers, are distributed geographically and run distributed routing protocols and any centralized routing network state is not scalable.

Imagine how a centralized controller would respond to a link failure and any route flaps that ensue. Such an experiment was done earlier in the networking industry with ATM networks and a centralized control plane with NNI and PNNI signaling that set up end-to-end connections (with QoS and bandwidth allocation/traffic shaping), which did not scale. MPLS evolved from these ashes to extend the fixed length (53 byte) ATM cell-switching to packets of variable length but relied on BGP/IGP (distributed routing protocols) to distribute MPLS labels rather than a centralized control layer. Similarly, a centralized control plane proposed by the SDN architecture does not work for distributed WAN networks connecting branches to data-centers. I have worked in developing and implementing all those technologies before and know well enough we don't want to reinvent that broken wheel.

The second practical differencebetween LANs and WANs when considering the applicability of SDN is the amount of programmability needed for individual network elements in each place in the network. SDN architecture implies that all intelligence is decoupled from the data-plane. The "network device" in Figure 1 is a simple programmable device that only needs to be programmed. No distributed control plane on the network device, all control plane functions are centralized in the controller and the network device is programmed with everything: routes, flows, QoS, services etc. This centralized control plane architecture might work for a single data-center L2 network, or an overlay network (VXLAN, STT), where the L2 switches can be fully programmed without any L2 control plane embedded in each switch. However, the latency and convergence times of dynamic reconfiguring upon link failures might still be prohibitive to the centralization of control functions in an SDN controller. Commodity device hardware for L2 switching might meet performance expectations in the multi-gbps range. As this is deep within the data-center, there is almost no need for services such as L3-L7 firewalls, IPS etc, which are handled on the edge router that feeds the L2 switched network. Commodity hardware, a promise of SDN, has a much simpler task of pure L2 switching, unlike L3-L7 routing where ASICs are usually needed to perform additional services beyond just L3 routing at multi-gbps throughputs. Therefore, for WAN networks, network devices cannot just be "dumb" programmed devices. The geographic distributed nature and high throughput L3-L7 services that need high performance hardware needs a systems architecture that can effectively couple a distributed control plane and an ASIC based data plane to meet the needs of a WAN network.

Lastly, the distributed nature of WAN networks requires a distributed control plane(running distributed routing protocols) that ensures network robustness as opposed to the single point of failure of a centralized SDN controller. Intelligent network devices are therefore necessary to recover effectively and quickly from topological changes in the WAN networks

Given these three big differences we can conclude that  WAN challenges that Enterprises are facing are not solved by the tightly coupled SDN programming model. Solving these WAN challenges requires that the WAN networks be aware of applications. This is already proven through network features such as QoS, PfR, traffic shaping, WAAS, AVC etc. that identify and enhance application delivery over WAN networks. Extending this further, if applications were network aware it would enable the deployment of applications in networks that can enhance the value of the overall network. Therefore, what WAN networks need is the mutual awareness of applications and networks which is possible through open APIs that allow applications to query network state and for network devices to convey network conditions to applications. At the same time network services, such as firewalls, analytics etc., can be provisioned as needed by applications and networks throughout the network to enhance business productivity. Such mutual awareness between networks and applications can overcome the enterprise WAN challenges by:

• improving application agility through enhanced visibility and control, for BYOD (wireless) and wired traffic, over the WAN
• enhancing user experience of applications through provisioning of WAAS and other network services
• enforcing pervasive and consistent security across the entire enterprise network

Well, so how is Cisco opening up the enterprise networks to create the mutual awareness of networks and applications? I will cover this in the next blog.

Thanks for reading and please comment on any and all aspects. I look forward to your comments. Stay tuned for the next blog post.