What elements of the SDN controller should be paid attention to?

A key challenge for software to define network potential users is to judge the specific value of a particular SDN controller, which, after all, plays a key role as a bridge between network applications and network infrastructures. However, there is no model to standardize SDN, and there is no standard that a SDN controller must comply with.

Although the advent of the Linux Foundation's Multi-vendor Opendaylight Project offers hope for the SDN stack required for a unified modular controller architecture, there are still many different opinions among vendors about what specific services the controller needs to provide. The pressure on the user is to determine what capabilities the SDN controller has, and whether these capabilities can help achieve the desired goals. Even so, it is hard for consumers to buy a separate SDN controller. The reality is that vendors often bundle controllers into the entire SDN suite, which typically includes applications, controllers, and network hardware.

Even if you consider purchasing a whole solution from a vendor, the controller's functionality may be in trouble. After all, the software definition network is developing rapidly, and the initial overall solution will look stale. So we have a number of factors to consider, as detailed below.

　　Raw Performance

When it comes to raw performance, we first need to be clear about the role of the SDN controller. Generally, the function of the SDN controller is to separate the control of the network environment from the data plane. In other words, the controller tells the network device how to forward traffic (the control plane), but they do not actually forward the traffic (the data plane). This situation is very common in the OpenFlow (of) network. In a OpenFlow network, the SDN controller is primarily used to program a form in a network device.

In a OpenFlow network, the of switch receives packets and processes them based on the flow table. But what happens if the packets in the flow table do not have matching entries? In this case, the of switch will send the packet to the controller, which actually amounts to asking "What should I do with these packets?". The controller to determine what the switch should do when the packet matches the stream and program the switch. This program is called "Streaming setup."

Due to the requirements of expansion, the SDN controller is highly valued for its stream installation per second. Typically, there is a performance bottleneck in streaming installation in Sdn. But don't take it for granted that with a large number of switches and the amount of micro-flow you want to control, they will quickly exceed the power of the controller flow installation. It must be borne in mind that not every stream needs to be contacted with the controller. This step is required only for streams that are not yet recognized or programmed, and this is usually an exception.

For vendors, they are well aware of the challenges posed by the flow-mount performance of OpenFlow networks. Manufacturers have developed a number of strategies to mitigate controller bottlenecks. Therefore, do not simply exclude a controller selection because of poor raw performance data. The manufacturer may have the means to optimize your network environment, minimizing the need for streaming installation. Among these mitigation methods, there is a technique called the flow-wildcard. This technique allows for the processing of numerous micro-streams through a single stream entry.

　Topology

Another factor to consider when evaluating the SDN controller is your network topology. Let's consider the difference between LAN and WAN first. Which part of the network do you want to use software to define? Although the LAN is a typical SDN use case, what if you want to deploy network virtualization across the WAN? How will the controller work in this mode? This is, to a large extent, a question about functionality. When your SDN environment is too large for a single controller to manage effectively, what options does the provider offer to help you extend to the WAN?

SDN Solutions with a central controller can be scaled horizontally. In other words, you can increase the controller to cope with the extra switches. But there is a very tricky question of how these switches will communicate with each other.

To this, the manufacturer has given many kinds of answers. Although the industry has long begun to standardize the way controllers talk to each other, in most cases the current solution is limited to specific controllers. A common technical combination is to implement the information exchange between controllers through the BGP protocol. In this way, the controller knows how to find different software definition sections in the network and forwards traffic between the two zones. If this feature is important to you, then you need to ask the alternative vendor for this critical question.

Although many SDN solutions can support a central controller, the concept of a centralized controller still has a potential problem. The first is how the traffic from the control plane, such as instructions from the controller to the network switch, is transmitted. In-band communication means that the traffic in the control plane will use the path used by all normal network traffic, and Out-of-band (OOB) communication means that the traffic in the Transport control plane requires a separate physical network.

In-band communication is supported by vendors who want to adjust their network topology through "accessibility". The idea is that if the network device can no longer be controlled by the controller, then the topology will adjust, and the controller will be able to detect these changes and make adjustments accordingly. Out-of-band communication has also been supported by some vendors. This part of the manufacturer wants to ensure that the controller and the switch between the low latency, improve security, eliminate the control plane flow loss caused by the risk of data flow.

The second concern about central controllers is the way in which these controllers will be centrally controlled. Intelligent centralized control does not necessarily mean that there is only one physical device or a group of redundant devices to serve as SDN controllers. Many vendors scatter control plane functions into distributed virtual machines that can communicate with each other and share databases. These components may give feedback to the core part of the controller's software, but it may also be feedback to the virtual machine. A physical controller or controller cluster, and a distributed virtual machine that fulfills the responsibilities of the control platform, these patterns are present in the SDN products.

　　Ability

It is noteworthy that not all SDN controllers have the same capabilities. The capability here does not refer to the original performance of the controller flow installation, but to the actual control ability of the controller to the network. Most network operators don't just look for a openflow controller, but want it to automate as many network element configurations as possible. At this point, you need to ask the manufacturer some of the following questions, including:

• What devices will this controller be talking to? You need to know whether this controller can talk to firewalls, load-balancing devices, virtual switches, cloud orchestration tools, and other devices in addition to conversations with network switches.

• What partnerships does the supplier have? Many SDN controller manufacturers have established strategic alliances with major network vendors. These collaborations make it easier to communicate between the SDN controller and the tools of the partner vendor. However, not all SDN manufacturers have the same cooperative relationship. Therefore, when evaluating the SDN controller, it is important to understand what partnerships the vendor has and what cooperation results these partnerships contribute to.

• What are the existing applications? Some SDN controllers are more like a blank palette--able to show anything, but first you need someone to paint on it. Another part of the SDN Controller has established its application ecosystem--someone has already painted a very beautiful picture for you. Figuring out what it's all about is going to help you decide how much you want the SDN controller to play in the network.

• Has the Controller's API been identified? APIs are a mechanism for getting and sending information to a controller from a controller, and the network application tells the controller what they need by North-to-API. APIs are the key to automation and orchestration. For example, how efficiently can your organization use the Controller APIs? They may not care for users who are looking for a holistic solution. But this is critical for users who want to write their own web applications.

　　Open vs. Vendor lock-in

The traditional network protocol has a great degree of interoperability among vendors. For example, a manufacturer's device that uses the BGP protocol can also be understood by other vendors using the BGP protocol. Although the vendor may add some private features to the protocol, the general network device vendor will follow a line.

This is not the case with regard to Sdn. There is no uniform way to create a SDN controller, nor is there a set of requirements for what SDN must have. The more controllers and architectures you touch, the more you will find that there are significant differences between them. These are the things that are expected. Because SDN is still a new technology, manufacturers are releasing controllers that represent their SDN concepts, in order to be as prominent in the market as possible, and strive to become market leaders.

For users, because of the lack of standards, resulting in the controller procurement, they encountered a lot of embarrassing problems. First of all, does this controller hold you in a particular solution? This is an important question to answer. Although many SDN solutions are powerful, they may only be targeted at specific types of users to help them solve a single problem. While this solution may give you an edge, in the future they may be a burden to you. For example, you may have to replace your load-balancing equipment vendor in a few years to reduce operating expenses, but SDN controllers and their associated applications may not work with load-balancing devices developed by other vendors. The risk of vendor lock-in is worth our careful consideration when making decisions.

• Can users switch to other controllers? If so, how should the transition be carried out? On the face of it, this is not much different from other concerns. For example, changing from router vendor A to Vendor B requires consideration of the functionality and operability of the product--b does the supplier's product meet your requirements? Can your network team manage the router for supplier B? But in terms of SDN controllers, the challenge of changing vendors is more complex. This needs to come back to the idea of what the controller is doing for you. Standard compliance can significantly reduce the risk of replacing router vendors, but there are no similar standards in the Sdn field. Can your network applications work with different controllers? If you do not make the appropriate changes, the application written for one of the controllers may not work on the other controllers. Perhaps opendaylight organizations can change that, but at the moment web users must take the time to understand the SDN controller to see if they are locked in somewhere.

In short, buying a SDN controller is not a trivial matter. Such investments need to understand not only the capabilities and performance of the controller, but also how the controller solves specific network problems. You must be familiar with your network features before you add a SDN controller. It helps to prevent big investment mistakes by taking some effort to do research.