- Jim Metzler
- Distinguished Research Fellow and Co-Founder
- Webtorials Analyst Division
Over the last six months there has been significant growth in the interest that IT organizations have shown in Software-Defined Networking (SDN), as well as in the number of SDN related announcements that vendors have made. While a lot has been written about technologies such as the OpenFlow protocol that enable SDN, much less has been written about SDN controllers and what distinguishes one controller from another. Given that SDN controllers are a new class of product, many IT organizations will struggle when it comes to evaluating them. In order to assist IT organizations in choosing the most appropriate product, this white paper discusses the key criteria that IT organizations should use when evaluating an SDN controller.
The majority of the characteristics that are discussed in this white paper are technical. Some of these technical characteristics will be familiar to the reader, as they apply to most, if not all network elements. This includes scalability, performance, security, centralized monitoring, visualization and reliability. However, some of the technical characteristics are SDN-centric and hence will be new to most readers. This includes OpenFlow support, network virtualization and network programmability. In addition to the technical characteristics, this white paper also discusses the importance of IT organizations evaluating the vendors that provide SDN controllers, and the white paper suggests how IT organizations can perform this evaluation.
At the end of this document is a checklist of the key criteria that IT organizations can use when evaluating an SDN controller.
- Download Paper
- More resources from Webtorials Analyst Division
I find it quite interesting that SDN is pitched to address so many of the challenges facing network designers / operators and administrators - I fail to see how a controller based solution will address any network performance or reliability issues not already addressable by current techniques.
You talk about the controller needing the intelligence and capabilities for understanding topologies and traffic paths which are not available in traditional networks - my experience (as a CCIE for the last 13 years - please don't read as Cisco bigot )is that many protocols exist to address almost any specific requirement - but all come at the expense of complexity and need clever people to maintain and tweak unforeseen knock on effects of trying to steer traffic in non standard ways (how many times will we need to track down IP fragmented packets - which do not carry all the 12 Tuple headers in order to maintain the flow )I see the need to standardise and exercise some innovation in the networking space - I see first hand the lack of innovation by the entrenched vendors - resting on their laurels - but I think the way to drive the SDN agenda should be to drive down the operational overheads of a distributed configuration/management capability - the rest will come in time.
While I certainly agree with you that SDN is being pitched to address many of the challenges facing network professionals, improving network performance and/or reliability is not one that bubbles to the top. The application you mention, driving down the operational complexity of distributed management tasks is one that does bubble to the top.
I strongly encourage networking professionals to define what problem they are trying to solve and then look at SDN and network virtualization as possible solutions vs. the other way around. For example, if the problem is supporting the dynamic movement of VMs. that can be supported by an SDN, but it can be supported by other techniques, including implementing network virtualization based on overlays. Another example is the centralization of configuration management that you mentioned. If that is the problem, then SDN is a good solution, however, the OpenFlow protocol is not required. Other protocols, such as XMPP, will do the job.