The concept of programmable networks and their later software-defined networking (Software-defined networking, SDN) significantly reduce the difficulty of network maintenance, management, and update, enabling network managers to adjust network decisions in a higher-order (software) manner instead of traditional lower-order (hardware). Recently, Google and many academic and business organizations have either invested in developing or updating the system as an SDN architecture, demonstrating its potential to reduce maintenance and operating costs.
Software defines the concept and importance of a network Computer networks are built on many such things as routers, switches, and many intermediate devices between users and users or between users and servers (Figure I), and many complex communication protocols (protocols) are used in these tens of millions of devices to keep the network functioning properly;
Figure 1: Complex Network Architecture
In most current network systems, when the state of the network changes and event response rules have to be adjusted, network stewards often have to manually convert high-level event response rules in the network using expertise and experience to lower-level instructions, which is often a very limited tool to use. So, as most people have experienced, network systems are no longer a problem, and in the event of an unusual situation with a network event (exception condition) or an unprocessed exception to a program,” system maintenance and tuning is often a challenging and error-prone process. This is mainly due to the network management personnel have only hardware suppliers to provide the device and functionality is often not complete enough to deal with all the conditions of the operating interface, so that these devices for network management personnel is just a few string to play a function of the “black box”, as long as one day can not fully understand its operating mechanism, to deal with all network conditions such as flow is an almost impossible task.
Another extremely difficult problem for network management and researchers to overcome is the so-called “Internet ossification”, which refers to the rapid spread of the network and the use of a large number of network devices. Networks have been seen by most as part of public infrastructure such as transportation systems and power systems, whether it is hardware extraction or the evolution of communication protocols, and it is almost impossible to recognize the possibility of disruption to network services. This has forced us to make some fundamental improvements to the network architecture to make it easier to adapt to new evolutions.
This is where the programmable network (programmable network) such as software defined networking (SDN) is the idea. It separates the hardware that transmits the package from the decision unit that controls the packet transfer, and enables the decision unit to program control, greatly simplifying the management of network event response rules and behavior patterns, making it easier to update the hardware and communication protocols. In a software-defined network, the central software controls the mechanism for packet transmission, the components transmitted by the packet are only responsible for data transmission, while the software can be programd by an open interface, the most influential mainstream interfaces are ForCES and OpenFlow.
Software-defined network architecture
The transmission of data in a network consists of a user-to-user or user-to-server-to-network infrastructure link, and the transfer of packets on the link is done by the router and the switch. These routers and switches are usually “closed” systems that are operated only by network stewards with control interfaces provided by hardware vendors, so updating these hardware or communication protocols (e.g., updating IPv4 to IPv6) once they are in service can be a difficult task without compromising the normal use of the user, let alone replacing the hardware or communication protocol completely.
As mentioned earlier, the phenomenon of “network bone” means that the decision to packet transfer or transfer is made on the network component, that is, in such an environment, when any new network application (e.g. firewall, intrusion detection system, etc.) or functionality (e.g. bypass mechanism) changes, the network management personnel must directly change the entire system architecture at the infrastructure (i.e. the lower level), which is a time and human cost. SDN is proposed to try to solve this phenomenon and thus promote the evolution of network systems.
As shown in Figure 2, separating control logic from packet-to-hardware makes new applications or communication protocols easier and more direct, while managing network architectures becomes as intuitive as maintaining common programs, and general network parameter adjustment is easier to follow with a common control interface between network components.
Figure 2: SDN separates the control logic from the packet transfer hardware
SDN simplifies the network architecture to two units of packet forwarding hardware and network decision
controller, where the packet forwarding hardware consists of (1) a flow
table that contains entries and actions that must be taken against an active process;
Figure 3: A general architectural diagram of SDN
- The existing SDN architecture (Figure III) ForCES and OpenFlow are the most influential mainstream SDN interfaces, both of which adhere to the basic spirit of SDN, namely, separating data transmission from the control unit and allowing the two to exchange information through secure channels;
- ForCES, proposed by the IETF ForCES (Forwarding and Control Control Element Element) Working Group, redefines the internal structure of the network components as separate control units and packet transfer units, but the network components are still considered as individuals;
ForCES defines a logical individual called Forwarding Element (FE), which implements the ForCES communication protocol, which handles packets using its lower hardware; a logical individual responsible for executing control signal functions, called Contor Element (CE), tells FE how to handle the packet; and another function block on FE, which is controlled by CE under the ForCES protocol communication protocol, is called Logic Function Block (LFB), allowing CEFE configuration.