SDN is certainly beginning to garner serious attention – in a study last year, 55% of Gartner customers were thinking about deploying SDN1. However, the same research found 23% are still unfamiliar with it. With a lack of common standards and a variety of approaches, implementing SDN can seem daunting despite the benefits. So why should businesses be thinking about SDN and how should they approach it?
Why is SDN important now?
Big data, the proliferation of devices and the rise in cloud services have all contributed to the complexity of today’s business network. Many of the applications and services that run over the network are both mission-critical and sensitive to poor performance.
A traditional network architecture can’t be dynamically managed, since each network device needs to be individually configured. With SDN, organisations can configure all of the equipment on the network from one controller, dramatically simplifying the network.
This makes it possible to respond to the needs of different applications or areas of the business with a speed and flexibility that wasn’t possible before – think minutes, rather than days or weeks. It improves application performance and optimises network utilisation without sacrificing service quality.
SDN makes it less time-consuming to manage the network and reduces expense by making use of policy-enabled workflow automation. It also allows for greater agility, since it’s far easier to customise network behaviour as the needs of the organisation evolve.
The limitations of OpenFlow
SDN originally focused on separating the control and data planes of the network. Instead of rules on the switch’s firmware dictating where packets on the network should be routed, a central controller (deployed on a server) sends packet-handling rules out to the switch using the OpenFlow standard.
OpenFlow supports policy-based flow management and works well where predefined policies need to be pushed out to handle network segmentation. It can also be used to implement simple Quality of Service (QoS) and flow metering.
So the OpenFlow model is clearly highly valuable, but it has limitations, and SDN can have wider applications if we consider more than one model for network programmability.
Greater flexibility with a hybrid model
OpenFlow’s centralised model can create scalability issues and limits the options for application deployment. With OpenFlow, applications use APIs on the controller to implement network policy.
However, being able to directly access decentralised device APIs gives a new range of possibilities.
Cisco promotes a hybrid approach, combining both direct API access and API access through a controller. This provides much more flexibility for the deployment of applications running in different locations, such as software containers on routers or switches. It also allows for different scenarios, such as applications being deployed on a node without direct reachability between the node and the central controller.
This approach underpins Cisco’s vision where applications can extract intelligence from the network. The application applies analytics to this information to determine and flexibly modify the appropriate policy, which is then pushed out to network nodes.
This is the ultimate in network programmability, and has huge implications for the efficiency, cost-effectiveness and performance of modern business networks.
By registering to Ingram Micro’s flyHigher Partner Program, you opt in and agree to receive email communications from Ingram Micro flyHigher. Please note that the flyHigher database with your email address and other contact details is located in the EU and separate from Ingram Micro’s databases, but subject to Ingram Micro’s general privacy statement. If you wish to manage your preferences with Ingram Micro please do so at www.ingrammicro.com. If you wish to opt out from receiving emails from flyHigher or be removed from the flyHigher database, please email us here.