In order to understand the software-defined network (SDN), you may encounter many terms related to this technology. Some of these terms are unique to SDN, while others are not, but they are usually used to describe SDN design. It is helpful to understand these terms and their semantic environment. Let's focus on three basic technical categories related to SDN: controller, switching network and overlay network. An important concept of controller SDN is a device called controller, which talks with all network devices in a certain domain, learns the network topology, and programs the network from the omniscient central point. It can be said that SDN controller changes the network programming mode from distributed mode (network devices communicating with each other decide the forwarding path) to centralized mode. Network centralized programming is the great value that controllers bring to enterprises. Conceptually, the controller can be used to fully deploy business policies for the network, regardless of the devices in the network. The behavior of the controller is similar to that of the network middleware layer, which abstracts the underlying physical network components, such as switches, routers, firewalls and load balancing devices. Using SDN controller to program the network, network operators do not have to use traditional methods (such as command line interface) to program a single network device. In addition, you can create a proprietary network forwarding paradigm based on cost or security policy requirements. The controller is programmed by software, so SDN has great flexibility. Controller is not only the running platform of software, but also the communication gateway of software. Most controller architectures are modular, allowing controllers to communicate with various network devices in many different ways. The SDN controller is regarded as a middleware, which means that its communication has two directions. So far, most discussions have focused on southbound communication. In other words, the controller programs network devices and receives data from these devices, which is southbound communication. An example of southbound communication is that the controller uses OpenFlow to program the forwarding table of the network switch. The other direction is northbound communication. The communication between each application that wants to program the network and the controller is called northbound communication. An example of northbound communication is that an application such as VMware's vCloud Director sends a network configuration service request through the controller. Switches When it comes to SDN, many people may talk about switches, especially Ethernet switches. The speed and density of Ethernet switches have been increasing, which can provide uplink for Ethernet storage in hosts, blade centers and data centers. With the advent of server virtualization, hypervisor software switching becomes more and more important. It can detect virtual servers and virtual network cards, collect traffic in and out of the hypervisor, and send it to the physical network. Both hardware and software switches play an important role in SDN. First, the forwarding table of the switch can be programmed and controlled by the controller. Considering that soft switching is usually located at the edge of the network, the concept of "intelligent soft edge" appears. Network designers who support intelligent soft edge feel that this is an ideal place for software switches to run on hypervisor, because rich network functions can be installed here and physical hardware switches can run in a relatively simple configuration environment. In the SDN design of intelligent soft edge, the controller can implement forwarding, QoS and security policies through soft switch. For example, soft switches can have access lists, rate-limited QoS parameters and traffic priorities, and intelligent forwarding applied to virtual ports. When the network data leaves the hypervisor, it has been tested for security compliance, rate shaping and encapsulated. Putting all these functions on the edge of the network can make the core hardware switch only do fast traffic transmission. Not all networks allow intelligent soft edge design, and not all feasible SDN users will use soft switch. For SDN, hardware switches will still play a role in some tasks, such as end-to-end business strategic deployment, traffic control and security implementation. In addition, no matter how smart the edge network is, there are still a certain number of basic configurations to be completed on the hardware switch. OpenFlow is the main southbound protocol used by the controller to program and control the forwarding behavior of hardware and software switches. The Open Network Foundation (ONF) is rapidly promoting the OpenFlow(OF) protocol standard. ONF is an organization mainly composed of network providers and service providers, behind closed doors. The foundation's OpenFlow specification has published PF 1.0, which is often seen in production environment. The next version of 1.3 will be mainly aimed at most switch manufacturers. +0.4 of 65438 is currently being calculated. Remember, although OpenFlow can be completely implemented on a software switch like Open vSwitch, it has proved to be a challenge to translate it into code that can be executed by the network chip (ASIC) of a hardware switch. Although it is reported that a new chip that can better handle OF will come out soon, users will definitely test it with their existing network when evaluating the usefulness OF OF of, so as to ensure that the required functions of of of can be expanded as much as possible to support its application. For northbound communication, the controller usually provides API. REST API is probably the most commonly used. REST API is very similar to HTTP server, which uses some familiar methods such as GET and POST to exchange data and instructions. The API provides a method applied to the controller to tell the controller what will happen on the network. It is worth noting that in addition to OF, some vendors have launched some specialized southbound APIs. This is partly because of the limited instruction set and sometimes it is difficult to implement on traditional chips.