Software-defined networking (SDN) is the hottest thing going today, but there is considerable confusion surrounding everything from the definition of the term to the different architectures and technologies suppliers are putting forward.
|Where we stand with SDN|
|A Q&A with the Chair of the Open Networking Foundation's Migration Group|
|What to look for in an SDN controller|
Given the confusion, some IT shops are probably taking a wait-and-see attitude. But while that response would be understandable, it isn’t the right approach because, even though no reasonable person would claim to know how SDN and network virtualization will evolve over the next several years, there is no doubt these emerging technologies will have a significant impact.
You need to plan now for how you will evaluate and possibly implement these new approaches to networking. We’ll outline some macro considerations that you’ll need to take into account when you formulate that plan, then outline some micro issues, but let’s start with a definition of SDN.
The Open Networking Foundation (ONF) is the group that is most associated with the development and standardization of SDN. As the ONF points out, SDN is not a technology, but an architecture. According to the ONF, SDN decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services. According to the ONF, the OpenFlow protocol is a foundational element for building SDN solutions.
Part of the confusion that surrounds SDN is that many vendors don’t totally buy in to the ONF definition of SDN. For example, while the vast majority of vendors do include the centralization of control in their definition of SDN, there isn’t agreement as to how much control should be centralized. In addition, while many vendors are viewing OpenFlow as a foundational element of their SDN solutions, other vendors are taking a cautious approach to OpenFlow and in the mean time adopting protocols such as XMPP.
Another source of confusion is the relationship between network virtualization and SDN. It is possible to implement an SDN that resembles the ONF definition of SDN and use the SDN to implement network virtualization. For example, the Open DayLight foundation recently accepted a contribution from NEC referred to as Virtual Tenant Networking (VTN) that enables an SDN to implement network virtualization. It is possible, however, to implement network virtualization without implementing SDN. For example, both Nuage Networks and VMware/Nicira implement network virtualization using an overlay model. To add to the confusion, Nuage Networks refers to its solution as SDN while VMware is adamant that its solution is network virtualization and not SDN.
IT organizations can’t wait for the brouhaha surrounding the definition of SDN and network virtualization to sort itself out. As part of developing an SDN plan, IT organizations need to develop a definition of SDN that is well understood and
agreed to within their organization.
This article will focus on SDN and recommends that IT organizations approach planning for network virtualization the same way they would for any vendor-specific solution that provides additional functionality to an existing network.
An analysis of SDN solution architectures and subtending protocols is totally irrelevant until you identify the problems and/or opportunities you’re hoping to address with SDN. That follows because analyzing architectures and protocols only makes sense in the context of what the IT organization is trying to accomplish.
Some of the primary opportunities that are typically associated with SDN include:
- Support for the dynamic movement, replication and allocation of virtual workloads
- Easing the administrative burden of configuring and provisioning network elements
- Enabling traffic engineering with an end-to-end view of the network
- More easily implementing QoS
- Enabling applications to dynamically request services from the network
If, for example, the goal is to support the dynamic movement, replication and allocation of virtual workloads, then an overlay solution from a vendor such as Nuage Networks or VMware is a viable candidate, as is an SDN solution from a company such as NEC. The overlay solutions, however, don’t make it easier to implement QoS, nor do they enable applications to dynamically request services from the network.
SDN is both embryonic and rapidly evolving. Hence, in order to create and update an SDN plan, IT organizations need to continually educate themselves as to what is happening in the broad SDN ecosystem. This certainly includes analyzing what is being said in the industry about the relevant SDN use cases and the techniques to justify deployment. It also includes reviewing product announcements, the announcement of enabling technologies that are either new or have evolved, the results of plugfests that are intended to test the interoperability of SDN solutions, and the work of organizations such as the Open Daylight consortium.
Much of this education can be accomplished by reading articles and white papers and by attending seminars and workshops. IT organizations should also consider downloading some of the open source products that are readily available and playing with those solutions to gain deeper insight into their capabilities and weaknesses. In addition, in October the author will publish a mock RFI for SDN solutions that will be hosted at the author’s Webtorials web site. IT organizations can use this document to structure the type of SDN solution evaluation that is described later in this article.
As part of your SDN plan, you need to identify a set of vendors whose SDN solutions you will evaluate. Criteria to evaluate SDN solutions are discussed below. As part of the process of evaluating SDN tools, you need to identify whether you will acquire a complete SDN solution from a single vendor or if you will buy components from varying vendors.
It is reasonable to think that acquiring a complete SDN solution from a single vendor will obviate interoperability issues. But you should still request details of the testing that was performed by the vendor, as well as the results of any third-party testing that was performed.
The process of evaluating SDN solutions should be cyclical. You need to start with a cursory evaluation of numerous vendors to see what solutions correspond to your unique challenges, and also to make IT aware of the varying approaches to SDN the vendors offer, each of which have their own twist and value add. This stage should also help you eliminate vendors from consideration and let you perform a more detailed analysis on a small set of suppliers. The result of this detailed analysis may well be the recommendation to go forward with a proof of concept (POC).
When evaluating a SDN solutions, you need to consider the following:
The Solution Architecture - This includes examining topics such as which components of the solution are provided by the vendor and
which are provided by a partner; how much control is centralized in the SDN controller; what protocols are used within the solution; how the solution supports high availability; and the level of abstraction that is provided by the controller’s northbound API.
In addition, you need to evaluate SDN solutions based on their ability to respond to the opportunities IT has identified. For example, if one of the opportunities is to eliminate the administrative burden of configuring and provisioning network elements, you of course need to identify how each solution accomplishes this.
The SDN Controller - You’ll ultimately need to evaluate the architecture of various SDN controllers. For example, does the controller have a modular architecture that will enable the addition of new functionality over time? IT organizations also need to understand how the controller’s architecture enables scalability, high availability and performance.
SDN Switches -- You’ll need to know which of the vendor’s switches support SDN and how that support is implemented. For example, does the vendor support OpenFlow? If so, which versions and what optional features? Are the switches pure SDN switches or are they hybrid switches, and if they are hybrid switches, how does the SDN portion of the switch interact with the traditional portion of the switch?
There are two aspects to SDN management that need to be evaluated. One aspect is the ability of the vendor’s solution to alleviate the management challenges created by SDN. This includes monitoring the performance of the SDN controller; providing end-to-end visualization of the virtual networks; and configuring the SDN switches and monitoring the physical and logical networks between switches. The second aspect is integrating the management of SDN into a broader management solution. With the twin goals of minimizing the need for new, SDN-specific management tools and extending existing FCAPs (the International Organization for Standardization’s standard management framework) processes to the SDN component of the overall network.
There are also two aspects of security that need to be evaluated. One aspect is what functionality is provided to secure the SDN. This is critical because, if a hacker were to gain access to the SDN controller, they would have access to all of the subtending network elements. The other aspect of security that needs to be evaluated is the ability of the solution to enhance the overall securityof the IT infrastructure. For example, Radware recently contributed a toolset to the Open Daylight consortium’s SDN controller that will be used for the detection and mitigation of distributed denial-of-service (DoS) attacks.
There are two approaches that an IT organization can take relative to acquiring network functions that ride on the SDN controller. One approach is to acquire the network functions from a vendor (such as Radware’s distributed DoS application and NEC’s Virtual Tenant Networking functionality). Since most IT groups will acquire network functions from vendors, evaluating vendor-supplied network functions is a key component of the overall process of evaluating SDN solutions.
The second approach is for IT to develop some or all of the required network functionality. The primary advantage of this approach is it enables IT to customize the functions to meet the organization’s specific requirements. The disadvantage, of course, is it requires IT to have the base of skills necessary to both develop and to maintain those functions over their life cycle.
Testing and Certification
As mentioned, even if all of the components of the SDN solution come from a single vendor, you need to understand the testing that was done to ensure smooth sailing. In situations where the SDN components come from multiple vendors, you need to understand if the solution is certified, meaning, will you have a single point of contact to resolve problems that develop.
There may be instances in which IT has to either do testing itself or commission a third party to do testing on its behalf. For example, if you were to develop one or more network functions, you would need to test those functions on the SDN controller(s) you have selected and redo that testing prior to implementing new versions of the controller. If you face a situation like this, then as part of the SDN evaluation process you need to evaluate tools available to enable the organization to do testing as well as evaluate the offerings of external test labs.
Integration with the existing environment
It is certainly possible to evaluate SDN solutions in isolation from your current environment, but if SDN is to reach your production network, then as part of the evaluation process you should examine how SDN will fit in with the existing infrastructure. For example, what mechanisms exist to enable traffic to flow between the SDN and the traditional network? Is it possible to extend SDN so it operates both in a data center and in a branch office? How about across multiple data centers? You should also examine how to integrate the SDN management and security components into the existing management and security frameworks.
Given the lack of experience that virtually all IT organizations have with SDN, some shops will choose to leverage professional services from one or more third parties. You can use these services to help with the assessment of SDN solutions, to help with creating and performing a POC, or to create and maintain one or more network functions. You can also use these services to perform functions such as integrating SDN into the existing infrastructure as well as integrating the SDN management and security components into your existing management and security frameworks.
You’ll need varying levels of management buy-in at the various stages of your SDN plan. Of course little if any buy-in is needed to attend a seminar or workshop or download open source solutions and spend the time necessary to understand the functionality and the limitations of those solutions.
Increasing levels of management buy-in will be needed to engage vendors in detailed discussions of SDN, to conduct a POC or to implement an SDN. But you are more likely to get management buy-in if you anticipate management’s concerns and work to resolve those concerns over the SDN planning cycle. For example, some organizations will be reluctant to implement any technology or new way of delivering technology if the associated security concerns are not thoroughly addressed.
You’ll ultimately need to develop some form of business case to justify implementing SDN. That business case can be based on myriad factors, including everything from cost savings associated with automating administrative tasks to the added agility that comes with SDN. It may also be possible to identify ways in which implementing SDN supports other core IT initiatives, such as moving to cloud
There is no doubt over the next few years that SDN will have a significant impact both on enterprise networks and on the role of network professionals. Because of that, you need to develop a plan to evaluate and potentially implement SDN.
When planning for SDN, you need to be attuned to new developments in the industry, such the announcement of new companies, new products, new standards and the announcement of mergers and acquisitions of SDN providers. However, you also need to avoid some of the noise in the industry, such as the ongoing debate over the precise definition of SDN.
Given the embryonic and rapidly changing nature of SDN, an SDN plan will likely evolve over time. It should, however, begin with the identification of the opportunities that SDN might help address and with the definition of SDN that will be used by your organization throughout the planning process.
And don’t forget the planning process must include ongoing education. We are still in the early stages of software-defined networking and your plan will have to be a living breathing thing.
Metzler heads Ashton, Metzler Associates. He can be reached at email@example.com